Events and Incidents Comparison Summary
Incidents and events have separate but related roles in managing your network:
- an event is raised to indicate a happening on the network or in ENA.
- an incident indicates the persistence of an event, and can be called, amended and closed by more than one type of event.
The key differences between incidents and events are important in understanding how to best manage the information coming into Entuity:
Incident and Event Life Cycles
Event: An event indicates a particular state of an object at the time the event was raised. An event describes a concern or anomaly at a specific moment in time (at the time the event was raised), along with the type of concern/anomaly, identity of the component, severity and further details. It does not tell you if the concern/anomaly is still present or not.
Incident: An incident indicates an ongoing condition on your network with its associated events providing the state updates. Incidents contain the same information as an event but also indicate the current state of the concern. Incidents are opened, closed and reopened by events. When you view the details of an incident, you can see the sequence of events that caused it to be opened, closed and reopened.
Incidents are usually removed from the system 7 days after they are expired, events are retained by default for 14 days.
Event and Incident Severity Levels
Events have an associated severity level, which is configurable through the Events Administration page and also through actions. Incidents inherit the highest severity level of the currently raised event. For example, if an incident is raised by an event with a severity level of Major it has a severity level of Major, if it is updated by an event with the severity level of Critical the incident also inherits the Critical severity level.
Event and Incident Assignment
Incidents you can assign to users, events you cannot.
Event and Incident Annotation
Incidents you can acknowledge, events you cannot.
Pre and Post Storage Processing
In the set up of the Event Management System you can configure processing of incoming events before they are stored in the database, and also after their storage. Processing of incidents occurs after these two event stages. This indicates that incidents are raised only after the intelligence that is built into the Event Management System has been applied, which is why the Incidents dashboard is the best way to see what is happening on your network.
Opening and closing incidents:
The relationship between events and incidents can be of varying levels of complexity:
- Where one event raises an incident, and a second event closes the incident. For example, the Port Inbound Fault High (Packet Corruption) incident is raised by the Port Inbound Fault High (Packet Corruption) event and closed by the Port Inbound Fault High (Packet Corruption) Cleared event.
- Where more than one type of event can raise an incident, and more than one type of event can close the incident. For example, the AP Host Count Abnormality incident is raised by either the AP Host Count High or AP Host Count Low events and is closed by the AP Host Count High Cleared AP Host Count Low Cleared events.
- Where an incident may be raised and closed by particular event types, and an additional event type updates the state of that incident. For example, the Device Not Responding to SNMP incident is raised by the SNMP Agent Not Responding event, and its state is updated by the Device Cold Reboot, Device Warm Reboot and Device Reboot Detected events. (See Tailored Events and Incidents.)
Tailored events and incidents:
The Port Status Problem incident includes a number of techniques that you can also use to build a tailored event management system (EMS).
The Port Link Down and Port Operationally Down events both report on port failure:
- Port Link Down is generated from trap data. Traps are useful as they are raised when a problem occurs, however a device may not be configured to forward traps and traps are more likely to be lost in transit.
- Port Operationally Down is generated from SNMP polling. SNMP polling is usually easily configurable and reliable, however polling is conducted at a set interval and so involves a delay.
The Unify Ports Down Events rule instructs ENA to change the event type to Port Down when it receives either a Port Link Down or Port Operationally Down event. All other details remain the same, e.g. event name, severity level.
ENA uses the same approach to define the Port Down event.
The Port Up and Port Down events are used to generate the Port Flapping event. The Detect Port Flapping rule identifies when the port alternates between Up and Down 4 times within 2 minutes. When ENA raises a Port Flapping event, it also raises a Port Status Problem incident.