ASG320: Disk Space Full and 100% CPU Load

Perfectly, the charts will be updated within the next minutes - every 15 minutes.
Reporting starts from scratch now, so don't be confused while you receive your daily, weekly and monthly reports in June.

@ Scott - To be honest I'm a support engineer with Astaro [;)]

Have a nice day guys!

Cheers

Well,

1.) Greetings from Germany as well! :-)

2.) I just reinitalized the reporting database. On the webadmin interface i still can see the trend chart statistics but the log disk has been reduced to only 5% being used (from 100% !). 

All is running smooth at the moment.

I have to wait to see whether that was the root cause for all the network trouble in the past.

THANK YOU for your help BuddyBond & all the others! :-D

You rock!

It covers the charting data, but also anything that you see in the Reporting area of WebAdmin, the big ones for detailed data are probably web and packet filter usage.

If you couldn't tell from the detailed info, Buddy007 looks to be a dev with Astaro in Germany.  If he says that the data wouldn't be usable (due to corruption), then your best bet is just to implement his fix.  Given the nature of the problem, there's a good chance that the reporting data as it currently exists is possibly not complete or 100% factual anyway.  You should still have the raw log data if needed after the fix, just the reporting data will start fresh from the time that you implement the fix.

edit:  Since I see that you already copy over log data to an SMB share, you won't be losing anything, other than the usage of Astaro's built-in charting and structured lookup capability for the old data.  Nothing that you couldn't parse yourself with some scripting and the raw logs if needed.

Is there any possibility to backup the data that it can be used somewhere else?

>> Cause this is a postgreSQL database you might get it work by import it somewhere else...

Is there any other data that is used by the reporting engine? What else does it cover? Executive reports?

>> Excecutive Reporting and all statistics of the NETWORK / NETWORK SECURITY / WEB SECURITY / MAIL SECURITY area...you know the Top10 things.

Wow, this information could be useful I guess :-D

Well, reporting is interesting for future evaluations because we are in a network infrastructure migration process. In short: Is there any possibility to backup the data that it can be used somewhere else?

I think of capturing screenshots of the trend charts (daily, monthly, yearly, network, harddisk usage...).

Is there any other data that is used by the reporting engine? What else does it cover? Executive reports?

Thank you for your great support!

You're welcome.

How to mount a USB flash drive:

1) Plugin the USB flash drive
2) Enter the command: dmesg
    
check the last loglines here, you should see such like this:

usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
  Vendor: SanDisk   Model: U3 Cruzer Micro   Rev: 2.18
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 4013713 512-byte hdwr sectors (2055 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 4013713 512-byte hdwr sectors (2055 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
 sda: sda1

sda1 = USB flash drive

3) Create a directory which you want mount: e.g. mkdir /var/storage/usb
4) Mount the USB flash drive: e.g. mount /dev/sda1 /var/storage/usb

Finally you can copy all data to /var/storage/usb

But as I told you, this database is crashed - there is no way to get the data back. Is the reporting very important for you?

Hi Buddy,

probably you are my saviour!

Before I do that I want to backup this data. How can I copy these files to a Windows SMB share? I tried mounting a USB disk but when connecting it to the Astaro there is no /dev/... in the folder structure.

Can I connect to a net share directly? or via SFTP?

The reporting database has crashed - that's the problem. Remember: There is no way to regain the reportings - but no problem.

Please rebuild the database with following commands - line by line:

/etc/init.d/postgresql stop
rm -fr /var/log/reporting/pgsql
/etc/init.d/postgresql start
mkdir /var/log/reporting/pgsql
chown postgres[:P]ostgres /var/log/reporting/pgsql
/var/storage/pgsql/init/reporting_db_init.sh -v

After that everything is fine again and also your reporting will work again.

Details:


disgwac:/var/log # du -h -a --max-depth=1
384K    ./kernel
16K     ./openvpn.log
3.3M    ./smtp
388K    ./service_monitor
384K    ./user_prefetch
944M    ./http
0       ./device-agent.log
104K    ./selfmon.log
1.1M    ./mdw
34G     ./reporting
384K    ./acm
392K    ./logging
384K    ./u2dcache
384K    ./qa-logging
388K    ./pppoe
11M     ./confd
4.0K    ./sshd.log
0       ./xinetd.log
412K    ./ips.log
760K    ./selfmon
4.0K    ./logging.log
384K    ./sockd
384K    ./pop3
0       ./wireless.log
0       ./squid.log
0       ./identd.log
0       ./ospf.log
1.6M    ./ips
4.0K    ./login.log
384K    ./sshd
384K    ./afc
12K     ./service_monitor.log
384K    ./wireless
384K    ./exim
0       ./pop3.log
4.0K    ./pppoe.log
0       ./pppoa.log
0       ./high-availability.log
0       ./acm.log
384K    ./accd
384K    ./ftp
0       ./accd.log
0       ./ufod.log
392K    ./notifier
23M     ./packetfilter.log
468K    ./fallback
600K    ./named.log
0       ./u2dcache.log
1.5M    ./up2date
108K    ./mdw.log
24K     ./fallback.log
0       ./ftp.log
13M     ./httpd.log
384K    ./ospf
8.0K    ./kernel.log
384K    ./xinetd
384K    ./ufod
2.9M    ./dhcpd
1.2M    ./httpd
13M     ./system.log
384K    ./red
66M     ./system
20K     ./notifier.log
384K    ./pppoa
384K    ./xorp
0       ./spamd.log
820K    ./named
4.0K    ./pptpd.log
0       ./qa-logging.log
384K    ./high-availability
396K    ./openvpn
0       ./afc.log
384K    ./pppd
384K    ./spamd
60K     ./ipsec.log
384K    ./boot
384K    ./device-agent
0       ./xorp.log
0       ./exim.log
0       ./user_prefetch.log
384K    ./pptpd
436K    ./dhcpd.log
0       ./red.log
240K    ./smtp.log
384K    ./identd
66M     ./packetfilter
0       ./sockd.log
384K    ./aua
16K     ./lost+found
4.0K    ./aua.log
64M     ./confd.log
764K    ./ipsec
136K    ./up2date.log
101M    ./http.log
384K    ./login
0       ./pppd.log
24K     ./boot.log
384K    ./squid
35G     .


disgwac:/var/log/reporting # du -h -a --max-depth=1
384K    ./meta
34G     ./pgsql
4.0K    ./adbs
4.0K    ./exec
1.2M    ./images
136K    ./inline
28K     ./accu
3.0M    ./rrd
34G     .


disgwac:/var/log/reporting # cd pgsql
disgwac:/var/log/reporting/pgsql # du -h -a --max-depth=1
34G     ./16519
34G     .


disgwac:/var/log/reporting/pgsql # cd 16519
disgwac:/var/log/reporting/pgsql/16519 # du -h -a --max-depth=1
953M    ./43397.4
1.1G    ./16525.20
14M     ./16655
276K    ./16733
23M     ./16644
6.1M    ./16723
1.1G    ./16525.15
140K    ./16632
16K     ./16543
1.1G    ./43398
1.1G    ./16525.2
1.1G    ./16525.17
1.1G    ./16525.22
8.0K    ./43399
1.1G    ./16525.9
1.1G    ./16525.11
6.4M    ./16696
100K    ./16736
4.1M    ./16722
49M     ./16525.23
8.2M    ./16683
1.1G    ./43397.3
1.1G    ./43398.2
85M     ./16670
1.1G    ./43397.1
1.1G    ./43398.1
8.9M    ./16684
1.1G    ./16525.12
260K    ./16735
20M     ./16713
1.1G    ./16525.5
16K     ./16550
1.1G    ./16525.10
164K    ./16710
1.1G    ./16525.6
7.7M    ./16648
9.4M    ./16697
32K     ./16709
1.1G    ./16525.4
9.1M    ./16611
276M    ./43398.4
0       ./16534
0       ./16623
1.4M    ./16618
16K     ./16552
1.1G    ./16525.3
12M     ./16657
1.4M    ./16620
15M     ./16658
4.0M    ./16720
1.1G    ./43398.3
1.1G    ./16525.18
8.0K    ./43400
28M     ./16645
48K     ./16707
1.1G    ./43397.2
1.1G    ./43397
24M     ./16687
3.0M    ./16630
1.1G    ./16525.7
1.1G    ./16525.1
1.1G    ./16525.14
22M     ./16642
1.1G    ./16525.19
452K    ./16635
10M     ./16681
1.1G    ./16525
1.1G    ./16525.13
6.2M    ./16694
378M    ./16661
1.1G    ./16525.16
1.1G    ./16525.21
118M    ./16671
81M     ./16668
1.1G    ./16525.8
34G     .

Update: Astaro Support only helps resellers or partners. We as an end user would have to pay.

My reseller is not available today.

BUT I have found out that 34 GB is being used in the 
/var/log/reporting/pgsql/16519  directory on the log disk.

Thse are the monitoring trend charts?

Does it rotate? What happens if I delete the folder's content? But I do not want to lose any reporting data over the former long period.

OR: Is IT the actual problem? But at least reporting and daily (web filter, packet filter...) logs are being saved on the same disk, aren't they?