Last updated: September 11. 2012
The Event Console offers four interesting features that deal with counting and aggregation of events and also with timing. You'll be able to:
2. Count messages in defined interval
Activating the option Count messages in defined interval enables message aggregation. The idea is, that a certain number of messages is needed before an event is being opened. You have the following settings:
2.1. Count until triggered
2.2. Time period for counting, Algorithm
Here you select the time period for counting. With Algorithm you can choose between two ways how the interval is being interpreted:
So when should you use which algorithm?
2.3. Continue counting when event is acknowledged
One important reason for using the counting feature is to avoid excessive events in case of a series of multiple similar errors. However, per default the Event Console assumes that after an event has been acknowledged further messages from the same rule will again create a new event. This can be disabled here, so that further messages will simply increase the counter of the existing event (until that is finally being deleted).
2.4. Force separate events for different ...
Let's assume you have a hundred servers and want to create an event if on one of these servers more then ten invalid login attempts per hour are seen. You can configure this by creating one general rule for all servers. When it comes to counting, the Event Console makes sure that for each different server a separate counter is being kept and a separate event opened, if the level is reached.
By unchecking Force separate events for different hosts you change this behaviour. That way you will count the total messages on all servers together and at most one event will be created.
3. Expect regular messages
Rules that expect messages introduce a powerful feature. They can raise events in case certain messages do not arrive on a regular basis (for example a summary from a backup job). You activate this feature by checking the box as seen in the screenshot:
Similar to the counting you again need to specify an interval and an expected count. In order to generate precise results - however - a different algorithm is implemented.
The interval is always aligned in a defined way. For example for the interval "hour" the intervals are aligned at exactly 0 minutes and 0 seconds of each hour. You have the following options:
Why is this so complicated? In order to avoid false alarms. Consider you expect one backup message per day. What does that mean? If you would expect one message "every 24 hours", then very slight differences in the timing of the backup job would result in triggering alarms. The way the Event Console does this is more robust: you can configure that in each interval from 5:00 am UTC to the next day 5:00 am one message is being expected. Set the interval type to day and the timezone to UTC+5 in that case.
3.1. Merge with open event
Just like counting, merging avoids redundant events. It deals with situations where already one event has been created due to missing expected messages. There are three possible settings:
4. Delay event creation
This feature helps you to reduce the noisiness of your Event Console. It only makes sense for rules that use cancelling. Whenever the rule would open an event it rather puts the event into the phase delayed for the configured period of time. If a cancelling message is seen within this time, then the event will never be opened but silently deleted. If the delay time elapses without such a message, the event will be opened and any attached actions will be exected.
5. Limit event lifetime
Events generated from a rule that uses this setting are automatically deleted after the configured time period. This reduces the workload of the operator. Usually this feature is being used for events that are less critical.
New in 1.2.1i2: You can now configure separately if events in the phase open or in the phase acknowledged should be expired. The lifespan does always start when the event is openended.