Log disk suddenly filling up

First step is to find out exactly which log(s) are getting out of control.  Switch to delete after 3 or 7 days in order to establish a pattern over a couple of days if possible.  Then look at Logging & Reporting > View Log Files > Archived Log Files and Logging & Reporting > View Log Files > Today's Log Files.  It's a shame that you knee-jerk reacted by deleting daily without gathering the baseline normal log file sizes in your environment first.  Once you establish which log is out of control, you can either monitor the live version of that log or download the full version for opening with a text viewer that supports large files.  If it's big, do not attempt to view in your browser, you'll just crash it.  There are most likely recurring events that are being logged over and over again.  Knowing what, is the clue that could lead to resolution.

Brian, at the command line, could do ls -l /var/log/*.log to see what file is gigantic.  If it's the badguy.log file, try tail /var/log/badguy.log and that might tell you.  If not, open the badguy Live Log for a bit.  Otherwise, you'll need to follow Scott's prescription.  NotePad++ can handle giant files, and it's a free download.

Cheers - Bob

First step is to find out exactly which log(s) are getting out of control.  Switch to delete after 3 or 7 days in order to establish a pattern over a couple of days if possible.  Then look at Logging & Reporting > View Log Files > Archived Log Files and Logging & Reporting > View Log Files > Today's Log Files.  It's a shame that you knee-jerk reacted by deleting daily without gathering the baseline normal log file sizes in your environment first.  Once you establish which log is out of control, you can either monitor the live version of that log or download the full version for opening with a text viewer that supports large files.  If it's big, do not attempt to view in your browser, you'll just crash it.  There are most likely recurring events that are being logged over and over again.  Knowing what, is the clue that could lead to resolution.

For brevity's sake I had omitted a few events.  When the errors started, I had a notification threshold of 80%, but my notifications started suddenly with 95% usage and just went up.  When I looked at the dashboard, the 150Gb log partition showed as full, but when I looked at the main "Logging and Reporting" section, the partition randomly showed as 0 MB in size, or 151367 MB in size.  Setting the "Delete after 1 day" parameter did nothing at all.  Under "View log files" most log files showed as 0 bytes in size.  The slave unit would never sync, so I wound up rebooting the master unit, and the slave unit would not take over, so I let the Master get booted all the way back up and then reinstalled the OS on the slave unit, let it sync to the Master, then I reinstalled the Master.  It was very weird, and the Master was acting just strangely enough that I did not have a lot of time to look for a cause.

Here are the log file sizes.  It was at 6% full Monday, and it's up to 14% full today.  Looking at it, the http log is big.  My policy is to log accessed and blocked pages, under Web Filtering, but if that's causing my problem, why suddenly now?
-rw-r--r-- 1 root log           0 Jul  8 00:00 /var/log/afc.log
-rw-r--r-- 1 root log         382 Jul  8 09:04 /var/log/aua.log
-rw-r--r-- 1 root log           0 Jul  8 00:00 /var/log/boot.log
-rw-r--r-- 1 root log    20560903 Jul  8 09:04 /var/log/confd-debug.log
-rw-r--r-- 1 root log      523526 Jul  8 09:04 /var/log/confd.log
-rw-r--r-- 1 root log      167441 Jul  8 09:04 /var/log/device-agent.log
-rw-r--r-- 1 root log        3912 Jul  8 07:37 /var/log/epsecd.log
-rw-r--r-- 1 root log      943487 Jul  8 09:04 /var/log/fallback.log
-rw-r--r-- 1 root log      127109 Jul  8 09:03 /var/log/ftp.log
-rw-r--r-- 1 root log       13778 Jul  8 08:45 /var/log/high-availability.log
-rw-r--r-- 1 root log       26138 Jul  8 09:03 /var/log/httpd.log
-rw-r--r-- 1 root log 11661792868 Jul  8 09:04 /var/log/http.log
-rw-r--r-- 1 root log      274942 Jul  8 09:04 /var/log/ipsec.log
-rw-r--r-- 1 root log         422 Jul  8 05:36 /var/log/ips.log
-rw-r--r-- 1 root log           0 Jul  8 00:00 /var/log/kernel.log
-rw-r--r-- 1 root log        1787 Jul  8 00:48 /var/log/logging.log
-rw-r--r-- 1 root log         169 Jul  8 09:04 /var/log/login.log
-rw-r--r-- 1 root log      344467 Jul  8 09:04 /var/log/mdw-debug.log
-rw-r--r-- 1 root log      179128 Jul  8 09:04 /var/log/mdw.log
-rw-r--r-- 1 root log           0 Jul  8 00:00 /var/log/named.log
-rw-r--r-- 1 root log       19627 Jul  8 09:04 /var/log/notifier.log
-rw-r--r-- 1 root log    81787009 Jul  8 09:04 /var/log/packetfilter.log
-rw-r--r-- 1 root log      191797 Jul  8 09:01 /var/log/rsyncd.log
-rw-r--r-- 1 root log           0 Jul  8 00:00 /var/log/selfmon.log
-rw-r--r-- 1 root log      194432 Jul  8 09:04 /var/log/smtp.log
-rw-r--r-- 1 root log         104 Jul  8 09:04 /var/log/sshd.log
-rw-r--r-- 1 root log      200931 Jul  8 09:04 /var/log/system.log
-rw-r--r-- 1 root log       19030 Jul  8 08:58 /var/log/up2date.log
-rw-r--r-- 1 root log       64238 Jul  8 09:03 /var/log/webadmin.log

Update: Notepad++ won't open a 25Gb log file.[:)]
I'm trying UltraEdit, and it's kind of working.  I'll see if there is anything that jumps out at me.

Ok.  Here is an entry I keep seeing.  I redacted the IP address of the source: it is the IP address of the Internal Interface of the firewall.  The other address, 10.20.10.15, I'm okay with posting, because it's not in my routing tables at all.  It doesn't exist on my network.  The URL it's trying to hit, DCDGateway/DCDGatewayEx.aspx, is not one I recognize.

2015:07:08-11:05:17 psfw-1 httpproxy[6242]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="POST" srcip="FW_INTERNAL_INT_IP" dstip="10.20.10.15" user="" ad_domain="" statuscode="502" cached="0" profile="REF_DefaultHTTPProfile (Default Web Filter Profile)" filteraction="REF_DefaultHTTPCFFAction (Default content filter action)" size="2608" request="0x24410000" url="10.20.10.15/.../html"

Is the 10.20.10 network known to you, either a network connected to the UTM directly or something connected via VPN?  The originating source showing as the firewall interface indicates that the connection is being proxied.  Are you using WAF or Server Load Balancing?  As a temporary quick fix for the symptom, if you are using the proxy in transparent mode, you may want to add the 10.20.10.15 IP to the skiplist or in standard mode, you can create an exception for logging.  You still want to track down the originating client to stop the software making the requests though.