engines
Canopsis process system events thanks to a set of engines.
There are two types of engines, asynchronous and synchronous.
A synchronous engine belongs to a chain of engines which consume events from queues.
An asynchronous engine is independent from an execution chain of engines and process only events stored in a database.
Here is an architecture view of engines (designed with CACOO).
In this view, two chain of engines and flow of events, perfdatas and Canopsis configuration data are represented.
The event chain is the entry point for all poller/Canopsis events. Its goal is to consume events and transform them into perfdata.
The alert chain manages all Canopsis alerts at the end of event processing from the event chain.
Let's see roles for all engines (hyperlinks denote engines which are configurable by the user).
The Cleaner aims to clean events sent to Canopsis.
The filter aims to check if an event has to be destroyed or processed.
The derogation aims to transform event fields from a poller to Canopsis fields.
The tag aims to fill the tag fields of events.
The perfstore2 aims to save perfdata in the random access database.
The event store saves consumed events in the persistent database or send an alert corresponding to an inconsistent event.
The alerts cleaner aims to clean alerts.
The alert counter count number of alerts by alert type.
The topology check rules with input alerts.
The selector calculates a worst state about input alerts.
Calculate SLA of system services.
Do consolidation/aggregation on perfdata.
Switch perfdata from the random access database to the persistent database.