Thanks for that explanation. But it seems like a critical flaw for any security software to have such an easily exploited limit. Let the log file increase to the capacity of the drive because the only reason for it to grow to that ridiculous size is when someone is trying to obfuscate the log.
Right. Like I said, often the size is configurable. In many systems I work with, when we set them up, we create a separate drive to be used for log files only, and will make it 200 or even 500MB. And then you have to configure logging behavior. I work with some sharp guys, and have learned a lot about this aspect.
But one thing that sucks is that there are many systems, when they cannot write to a file, the system either stops working, or begins working erratically.
The first few times I ran into this, I was flummoxed, but as I gained experience, it became one of the first things I looked at. Only took a second to peek...
Let the log file increase to the capacity of the drive.
Usually you have a log on the device itself to allow convenient first-step troubleshooting. As noted in a previous post, for Cisco devices that is (an inadequate) only 4kB as a default. The log files sizes are also large enough that if communications to the server are cut off for a time that enough records to troubleshoot are kept within the device itself. Major storage is sent to another server - which is why they want the Splunk data. https://en.wikipedia.org/wiki/Splunk
Splunk is an off-device application which collects these alerts and logs, and allows for long term storage (I’m told often a years worth of logs but can be longer if retention requires), and the ability to readily search, display, and graph/chart the data.