From OpenNMS

When OpenNMS detects something significant has occurred, such as a service outage, an interesting SNMP trap being received, or some service level threshold being exceeded, it is entered as an event.

Events

Events can be configured to be stored permanently in the database, tagged to be displayed or not, or ignored if of no interest. All events have a UEI (a Universal Event Indicator), which is simply a URI-like text string used to identify the event. Events also have an associated severity, ranging from Normal for interesting, but non-problematic events, through various levels of importance up to Critical. Also, arbitrary text can be attached to an event for use as operator instructions to deal with the event.

Alarms

Alarms work to provide a current view of exceptional situations. Reduction is used to coalesce multiple raw events into single "alarm", reducing the cognitive load of the sheer number of events that occur in a modern network, while still keeping the raw events available for tracking purposes. Reduction into an alarm is keyed by any of the event parameters, such as the node, service, time etc. Alarms are still at an early but active stage of development.

Notifications

It's all very well for OpenNMS to know that something significant has happened, but ultimately humans need to be told. A given notification is triggered to be sent when a specific event occurs. Filtering can based on any event parameter, such as the node on which it occurs. For example, you might configure different notifications for two sets of servers, to notify an appropriate set of users depending on which server is affected.

Further, notifications have escalations; if a notification is not acknowledged (through the web interface) within a configured period of time, it is sent to the next destination on the escalation, and so on up the list. Notifications can be sent by e-mail, SMS text message, page, or by any other method for which a script can be written.