Information about events during the operation of the application and managed devices is saved in the Administration Server database. Each event is attributed to a certain type and level of severity (Critical event, Functional failure, Warning, or Info). Depending on the conditions under which an event occurred, the application can assign different levels of severity to events of the same type.
You can view types and levels of severity assigned to events in the Event configuration section of the Administration Server properties window. In the Event configuration section, you can also configure processing of every event by the Administration Server:
In the Events repository section of the Administration Server properties window, you can edit the settings of events storage in the Administration Server database by limiting the number of event records and record storage term. When you specify the maximum number of events, the application calculates an approximate amount of storage space required for the specified number. You can use this approximate calculation to evaluate whether you have enough free space on the disk to avoid database overflow. The default capacity of the Administration Server database is 400,000 events. The maximum recommended capacity of the database is 45 million events.
The application checks the database every 10 minutes. If the number of events reaches the specified maximum value plus 10,000, the application deletes the oldest events so that only the specified maximum number of events remains.
When the Administration Server deletes old events, it cannot save new events to the database. During this period of time, information about events that were rejected is written to the Kaspersky Event Log. The new events are queued and then saved to the database after the deletion operation is complete.
You can change the settings of any task to save events related to the task progress, or save only task execution results. In doing so, you will reduce the number of events in the database, increase the speed of execution of scenarios associated with analysis of the event table in the database, and lower the risk that critical events will be overwritten by a large number of events.
Page top