No Dashboard statistics

no ideas???????????????????????????????????????

Hi,

I have the same problem.
ASG220  with a fresh installation with up2date 7.302 applied.

Log partition status:
    Log partition size 0Mb 
    Free space:  0 MB  ...?

If you send me the login credentials for SSH/Webadmin access, I'll take a look and see what I can find out. You can use either forum pm or mail to agrosse at astaro dot com.

Cheers,
 andreas

hi guy's

I have a fresh installation of 7.300 with up2date 7.301 and 7.302 applied.

the problem is, i dont have any statics on the dashboard window. all other reporting is working. already tried /var/storage/pgsql/init/reporting_db_init.sh but without success.

do you have any ideas?????

Thanks for sending the login credentials. When I was inspecting your machine, I couldn't see the problem mentioned here: dashboard looks fine, log disk status mentioned by vilius looks fine here, too. After cross-checking with another thread I also took a look on the slave machine and discovered an uninitialized reporting database on the slave machine, which broke the database synchronisation. The blank dashboard report was probably at the time when the current slave node was master, because it lacked all reporting data. The current master is working fine, though.
I re-initialized the database on the slave machine, and restarted the database synchronisation, everything looks OK now.

Cheers,
 Andreas

Hi,

I have the same problem.
ASG220  with a fresh installation with up2date 7.302 applied.

Log partition status:
    Log partition size 0Mb 
    Free space:  0 MB  ...?

OK,
this problem was a totally different one. You initiated a factory reset, and currently (starting with 7.301) the factory reset is broken - it will remove the reporting data, but not re-create the necessary tables. This bug will be fixed in 7.303. 
I re-created the reporting database for you, dashboard & inline reporting should work now.
One additional word of advice: you're running at the limits of the 220, the machine is utilizing 51% of the available swap space, which is detrimental to the performance of the system. I'd suggest either turning off features (ips/imp2p detection comes to mind), or considering upgrading your unit. In any case, please make sure that the reporting database keep times are as short as possible so that database maintenance runs as smooth as possible. Keep an eye on the memory/swap usage during the nightly rotation, too.

Cheers,
 andreas

Hi Andreas,

Thank you for a great asisstance. 

Best reagards,
Vilius

Thanks for sending the login credentials. When I was inspecting your machine, I couldn't see the problem mentioned here: dashboard looks fine, log disk status mentioned by vilius looks fine here, too. After cross-checking with another thread I also took a look on the slave machine and discovered an uninitialized reporting database on the slave machine, which broke the database synchronisation. The blank dashboard report was probably at the time when the current slave node was master, because it lacked all reporting data. The current master is working fine, though.
I re-initialized the database on the slave machine, and restarted the database synchronisation, everything looks OK now.

Cheers,
 Andreas

We had the same issue on our cluster. Thanks Andreas for fixing it !

David

I have the same problem on an ASG220 v7300-v7302 in China. There are entries (locked / allowed) in the packet filter live log under logging > view log files > packet filter live log but ther is no entry under network security > packet filter > live log. And on the dashboard there are only zeros in the statistik.

Where does it come from?
Best regards

Andreas, where is "nightly rotation" documented?  We have only one client where we've tried a cluster.  They have a half-hour of 100% CPU usage every morning at 2:30 - I presume this is the "nightly rotation" phenomenon, or?

Thanks - Bob

They have a half-hour of 100% CPU usage every morning at 2:30 - I presume this is the "nightly rotation" phenomenon, or?
Thanks - Bob

That is correct. During the nightly 'rotation' (which is not really a rotation, we just called it like that because it works similar to the log rotation) data is aggregated and written into archive tables. This keeps the performance from degrading for calls which do run exclusively on today's data (like all the inline reporting stuff & the dashboard).
Since it is run with the lowest possible priority, it will peg the CPU for a while but won't disturb any other process running. 

Cheers,
 andreas