AutoPatrol
191
edits
Difference between revisions of "UM:Event Processing"
→Event Processing Overview
| Line 8: | Line 8: | ||
[[File:Event_flow.png|thumb|500px|none|alt=Event flow|Event flow inside the monitoring system]] | [[File:Event_flow.png|thumb|500px|none|alt=Event flow|Event flow inside the monitoring system]] | ||
As you can see on the flowchart, events can come from various sources: polling processes (status, configuration, discovery, and data collection), SNMP traps, and directly from external applications via client library. All incoming events go to single event queue for processing. A special process, called ''Event Processor'', takes events from the queue one by one and matches them against Event Processing Policy. As a result, alarms may be generated and actions may be executed. If event has ''write | As you can see on the flowchart, events can come from various sources: polling processes (status, configuration, discovery, and data collection), SNMP traps, and directly from external applications via client library. All incoming events go to single event queue for processing. A special process, called ''Event Processor'', takes events from the queue one by one and matches them against Event Processing Policy. As a result, alarms may be generated and actions may be executed. If the event has ''write to log'' attribute set, it is written to NetXMS event log at the end of processing. | ||
Although it may seem that processing all events one by one may become a bottleneck in the system, this should not be the case. Event processor is highly optimized, and all potentially long operations (like action execution) are performed by separate processes. | Although it may seem that processing all events one by one may become a bottleneck in the system, this should not be the case. Event processor is highly optimized, and all potentially long operations (like action execution) are performed by separate processes. | ||