Kaseya Community

Overflow detected. Too many Security event log entries

  • We have the same problem and with nearly 1200 machines monitored it is a burdon, especially when trying to report on backups.

    There are products such as Sophos PureMessage which out of the box will log pretty much everything to the event log (every virus, spam, update etc) and on some heavily used/spammed mail servers a lot of event log entries are created, couple this with Exchange maintenance and then of course the SQL Server management that occurs on an SBS server and the information events stop.

    This causes us real headaches when it comes to reporting the backup status for a week as Veritas logs informational events for the start and finish of each job (when successful).

    At least twice a day, I am having to go into the Agent log window and re-enable all alerts for all servers. The ability to configure this process/protection/feature would be a great help for us in reducing the management overheadof the system. As every system and every customer is different, in an idel world the Kaseya setup may work but we dont live in an ideal world and should be able to configure it to suit our set up.

    Legacy Forum Name: Server,
    Legacy Posted By Username: 1800Zeta
  • connectex wrote:
    I've been on the phone with Kaseya recently on the overflow issue. I have requested they review the handling of this matter. From what I've seen, it's quite common for a system to have a burst of event log entries. This occasional burst is not a sustained event log pounding. However, Kaseya disables logging after this "burst" and requires manual reinstatement of logging. They've explained that the overflow logic is there to assure the Kaseya server does not get over burdened when a one or more systems is getting an event log pounding.

    What I've requested is to make this more self healing. I've asked them to consider implementing an overflow entry limit, a reinstatement timeout, and a reinstatement limit, reinstatement limit reset. These could be implemented at the server o agent level. I'm for the agent level as it would allow for more flexibility. Here's how I see it working...

    That's definitely a start, in terms of progressing this feature. Auto-healing in some formwould really help out.

    This issue is a pain because like 1800Zeta, we are monitoring backups, anti-virus definition dates, and other things through scripts that use event log monitoring, and on some servers cannot avoid bursty informational/warning event log entries (and on some, can't avoid fairly constant/frequent informational entries) that cause an overflow w/Kaseya.

    Legacy Forum Name: Server,
    Legacy Posted By Username: mgengenbach
  • I would like to be able to see a bit more intelligence. If it detects a flood of event entries, there's a pretty good chance it's going to be just one or a handful of events that are causing it.

    Why they can't throttle back and then just blip one of these up every few mins (or what's deemed acceptable/configured) giving the usual event id info and the number of times it's occured.

    We've got one server pending an agent install and I *know* it's going to cause a problem. It's a factory production machine and one bit of software on it makes a call into a module in another package and it generates an error in the log. The app works fine, it's a problem with the module. The module is written by a massive company and they can't/won't fix it. These calls are happening several times a second, 24x7.

    I was hoping I'd be able to either summarise these (so I can report to someone some hard/fast numbers about the rate these are received) and then eventually filter them out. Then I might be able to see all the other errors that are probably getting logged, but we can't see them for the flood.

    Incidentally - does anyone know that when an Ignore flag is set on an Event Set, if this ignore takes place on the agent (fingers crossed) or gets filtered on the KServer (quite possible seeing as I discover more and more this is where all the work seems to get done) and thus still incurs network traffic?


    Legacy Forum Name: Server,
    Legacy Posted By Username: gordonc
  • Force Full Check-in - 15min.txt
    The "ignore" of a particular event type (information, warning, error, success audit, etc) appears to be done at the agent. I was getting many many Overflow detected errors because of Success Audits on several servers (original reason for this thread). I un-checked "Success Audit" from Security log in Log settings, and those errors went away.

    Similarly, I was getting Overflow detected errors on a different server regarding the System log and Information events. The problem was that I had Print spooler information event logging enabled and at this particular client, they print continuously throughout the day. This caused an average of 100 System events to be logged an hour. Through much trial/error and another convo with K support I found a solution that worked for me. This may or may not work for other people...

    I found that this server was not performing full check-ins very often. It appears that only during a full check-in does the Agent send event logs back to Kaseya. So I had two scripts scheduled during the day and as luck would have it, I would always get these Overflow detected errors at the same time as these two scripts. On a hunch, I created a blank script that would schedule itself for 15min in the future, thus forcing a full check-in ever 15min. (there is a sample script called "force full check-in" and it's just a blank script). I ran this script on this server for a week. Lo and behold, the Overflow detected error stopped. My other verification that events were collected only upon a full check-in was that I get a scheduled report sent to me every morning that reports all backup events on all my servers. This same server would not show the backup success even in the report, but when I went to check the log through Kaseya later on in the day it was listed there. But since I implimented this script, the backup event has been listed in the backup report. Apparently event logs were not being collected during the timeframe of the backup completion and my report.

    Since the event logs were not being collected but once every few hours it would error out with an overflow since more than 100 events were coming from the System log during those few hours. By forcing a full check-in every 15min I reduced the number of event logs being collected at one time which brought it below the threshold. I have since implimented this script on every managed server.

    Keep in mind, though, that Kaseya only stores the last 500 event entries for each event log (application, system, security). So even if this resolves the issue of Overflow detected errors, you will still have an issue with a limited event log history in Kaseya. Kaseya has this limit in place to prevent the k_subscribers database from growing too big (as I understand that event logs are stored in the db). After I resolved the Overflow detected problem I also went to that server and disabled Spooler Informational Event logging. This has reduced the number of events being generated and thus giving me a better event history stored in Kaseya (though, to be honest, even on a good, clean server, 500 events does not always go a long way).

    Listed below is my script (quite simple). Please keep in mind you will have to fix the path to the script in Step 2.

    Script Name: Force Full Check-in - 15min
    Script Description: This script is blank. By virtue of running it, it will force the target machine to perform a full check-in. It then re-schedules itself in 15 min.

    IF True
    Get Variable
    Parameter 1 : 6
    Parameter 2 :
    Parameter 3 : machineid
    OS Type : 0
    Schedule Script
    Parameter 1 : 49714030
    Parameter 2 : 15
    Parameter 3 : #machineid#
    OS Type : 0

    I've also attached the script as a file that you can import.

    I hope this helps someone.

    Legacy Forum Name: Server,
    Legacy Posted By Username: byulke