This article describes some of the timing and event handling systems in Iris.
There are quite a few methods to get events into Iris to get an understanding of the difference between and Alarm and an Event please see this video.
These are some of the way events are inserted into Iris and the timing around them.
SYSLOG / SNMP Traps
Syslogs are processed immediately and logged to the event dispatcher. Through the configuration, you can determine which syslogs are logged and which should be alarms.
SNMP Interface monitoring (ifstatusmon)
SNMP interface monitoring is a method we use in Iris to determine the status of an interface on a router, switch or device. This happens every poll cycle default is 5 minutes.
If the state of the interface is down at the time poll cycle an alarm is generated immediately.
Thresholds values are checked continuously based on the configuration. The threshold systems run through all the specified criteria and check that against the live polled data. If that data falls outside of the configured setting, it raises an alarm immediately. The timing of the threshold is configurable from 1 minute to 6 hours.
ICMP Active Monitoring
Iris sends 8 packets every 90-second cycle to a device or to an interface.
If we get more than 3 packets back, we increment the clear event counter on the existing Clear event.
If we get less than 3 packets back, we create a Warning event.
If on the next cycle, we get less than 2 packets back, we create a Critical event. If on the next cycle, we get less than 1 packet back, we create a Down event and an Iris Alarm is created.
It takes 3 cycles before an alarm is sent.
Alarm Notification and Notification group
Once an alarm is raised in the system, the notification system continuously checks against the configured rules to determine what and when and to whom the alarm needs to notify.
This video indicates how that happens
What happens when a device is added to Iris?
When you add a device to Iris these are the steps in the backend.
1. Configuration manager runs every 7 minutes to determine if a new device is added and informs its connected pollers; which start polling the device immediately.
2. As the poller is polling the device it collects all the polling routing data.
3. At this point, the backend systems know about the new device.
4. The Data Collection Engine (DCE) then takes that data and creates the time series database for the device and attached interfaces. This data is updated every polling cycle.
5. There is a process that then runs every 20 mins (or determined by the load of the server) that tells the front-end there is a new device and attached interfaces.
6. At this point, the data is now available in the front-end.