Use the information in this article to determine the number of alerts received by a specific Manager. Sometimes, the Manager fails to receive, and the Real-time Threat Analyzer fails to display all expected alerts.
Events primarily consist of alerts and packet log data, but also ACL logging, host events, and system events (also known as faults).
- Alerts and packet logs work together. A typical configuration calls for a single alert to be raised the first time an attack is seen against the five tuples of the following:
- Source/destination IP address,
- Destination port
- AttackID
- VIPS
Subsequent attacks with the same five tuples are suppressed for 120 seconds, and a throttled event with the suppression count is raised.
For the initial attack, the application data in both directions and the actual attack packet are forwarded to the Manager. This data results in two alerts and three packet logs per attack, for an alert to packet log ratio of 2:3.
- ACL logs are disabled by default. Enabling this logging, depending on the logging configuration, might result in many events being generated. ACL events aren't persisted and typically forwarded to the syslog server configured via the Manager.
IMPORTANT: Handling too many alerts, beyond the Manager host's hardware capabilities, isn't recommended.
For example:
- A rate of 1 alert/s means 60 × 60 × 24 for a total of 86,400 alerts per day
- 100 alerts per second = 8.64 million alerts per day
These alerts generate around 13 million packet logs per day, for a total of 22 million events per day
- Alerts are 400 bytes on average and packet logs are about 500 bytes on average.
So, 86,400 alerts per day generate the following:
- 3.5 GB of alert data
- 6.5 GB of packet log data
- 11 GB of data per day
It's almost impossible to action on 8 million alerts in a day.
Technical Support recommends that you tune your policies to keep event rates at a manageable level. Large numbers of alerts mean large database files. Large databases mean longer backup, database tuning, report generation, and overhead on regular operations.
Technical Support considers that the rates are at a manageable level when there are fewer than 100 alerts/s.
To determine the alert rate on a given Manager:
- Connect to your Manager either locally or via an RDP session.
- To enable debug logging:
- Open the file log4j.xml under <Manager install path>\App\config.
- Search for the following entry and change the priority value from INFO to DEBUG.
----------------
<category name="iv.core.alertqueuecounts" additivity="false">
<priority value="INFO"/>
<appender-ref ref="AQCNT_FILE"/>
</category>
----------------
NOTE: When disabling debug mode, change DEBUG to INFO.
- Under <Manager install path>\App, open the file aqcount.log.
The file contains events as follows:
2012-08-13 14:52:22,698 AltQ:EPR-RCD: 6928500 0 3098
2012-08-13 14:52:24,336 AltQ:PCR-DBL: 6928565
2012-08-13 14:52:26,161 AltQ:EPR-RCD: 6928800 82 3577
2012-08-13 14:52:27,217 AltQ:PCR-DBL: 6928878
- AltQ:EPR-RCD represents the alerts received from sensors. In the sample, 6928500 or 6928800 represents the number of alerts received so far since restart of the Manager.
- AltQ:PCR-DBL represents the alerts written in the database. 6928565 or 6928878 represents the number of alerts written in the database so far since restart of the Manager.
- Evaluate the rate of alerts received by the Manager or written to the database.
Divide the number of alerts between two consecutive events of the same kind by the time difference between the two events.
Example for AltQ:EPR-RCD: (6928800–6928500) / (2012-08-13 14:52:26,161 - 2012-08-13 14:52:22,698) = 88 alerts/s.