The platform offers advanced event management tools that all together allow implementing complex strategies involving real-time monitoring, filtering, aggregation, masking, acknowledgment, enrichment, correlation, and root cause analysis.
Highly loaded AggreGate servers process millions of events per hour. To mark out essential events from the incoming event stream, AggreGate users can create and manage event filters. A filter is owned by whoever created it but may be shared between users due to a flexible permissions setup.
Events can be filtered by source (device, a group of devices, system resource or a group of resources), event type, event severity level, parameters of acknowledgments/enrichments or any custom criteria defined by the expression.
Filtering by an expression makes event filters extremely flexible. Here are just some examples of how it may help:
- Finding events fired within a specific date/time range
- Finding Login events of a particular user (i.e., filtering by username)
- Finding all events that contain a specific substring in any of their data fields
- Finding all temperature readings collected when the temperature was higher than 120 degrees
- Filtering events matching condition X and/or condition Y, or more complex combinations
In addition to the selection criteria, the filters include event list visualization rules:
- Visibility of event's basic parameters, i.e. source, type, level, and acknowledgments
- Visibility of individual event-specific fields
- Custom expression-based and level-based highlighting rules
A filter can be parameterized to prompt an operator to fine-tune event selection criteria every time it is activated.
AggreGate-based vertical market products include sets of built-in filters for viewing industry-specific system events, device events, alerts, etc.
Beside UI-level filters, each server has pre-filtering rules allowing to discard certain events before they are saved in the database or routed to any destination.
Aggregation, also called event deduplication or reduction, allows the system to minimize the overall number of processed events by joining instances that appear to be similar according to the user-selected criteria.
For example, if multiple login attempts from a specific user have failed due to an incorrect password, this can be reflected by a single “authentication failed” event that includes several duplicates.
Correlation engine finds simple relations between similar events, usually one of them marking an outset of a certain process or state, and the second one marking its termination.
Another case is a sequence of correlated events coming from different sources that should trigger a more valuable internal event.
For example, if the “perimeter security sensor activated” event from a telecom tower is followed by the “low fuel level” event, it’s quite clear that the “Fuel Theft” alert should be raised.
Masking means ignoring events that come from sources depending on system elements that are deemed to fail.
An example would be suppressing the “device not available” events coming from devices in case the server’s network connectivity is damaged. This will effectively prevent an event storm.
Root Cause Analysis
This is the most advanced stage of the event management process. It involves analyzing relations between events and their environment followed by finding a cause of each event.
Root cause analysis is enabled by the proper use of all event management tools provided by the platform.
Enrichment process is similar to automatic acknowledgment that assumes pulling external information and attaching it to every event instance.
For example, an alert event may be enriched with a helpdesk trouble ticket number.
Once a new event was staged through the basic processing workflow, it gets to the dispatching phase that may look different:
- Synchronous events are handled by listeners in the same thread that produced them
- Regular sequential events are appended to the main event queue and later processed in the event dispatcher thread
- Concurrent events go through type-specific queues and their processing is parallelized in a dedicated thread pool