The notification process in Centreon

Notifying a contact in Centreon

Before a contact can be notified in Centreon, it is necessary to go through several steps. If no notification escalation is defined, the notification management process is standard. It is described below:

  1. A service (or a host) is checked at regular intervals according to the check period defined for it (In the case of a passive service, we wait for the status of the service to change)

  2. If an anomaly occurs (Not-OK status), the service (or the host) goes into the SOFT state

  3. After the Max Check Attempts has taken place and if the service (or the host) persists in retaining its Not-OK status its state changes from SOFT to HARD. The monitoring engine caches the notification number to the service (or the host): i.e. 0.

At each notification interval of the service (or the host) and until the end of the Not-OK status, the monitoring engine performs the following operations:

  1. The monitoring engine checks that the notification period defined for the service (or the host) allows the notification for the service (or the host) when is switched into the HARD state. If the answer is yes, we go to the next step otherwise we wait for period defined for the service (or the host) to allow notification.

  2. The monitoring engine checks that the notification is enabled to the current status of the service (or of the host)

For every contact associated with the service (or the host):

  1. The monitoring engine checks several settings:

  • Is notification to this contact enabled?

  • Does the notification period defined for the contact allow notification?

  • Is the contact configured to be notified of the current status of the service (or the host)?

  1. If these three conditions are confirmed, the monitoring engine alerts the contact using the notifications script defined for the service or the host.

  2. The monitoring engine increments the notification number by 1

The diagram below summarizes the notifications management in Centreon:

../../_images/hnotifications_schema.png

Notifications escalation in Centreon

Notifications escalations allow two things:

  • Notifying various contacts according to the number of notifications sent

  • Changing the command of notification over time

In case of the use of notifications escalations, the retrieval of the list of contacts is a little different:

  1. A service (or a host) is checked at regular intervals according to the check period defined for it

  2. If an anomaly occurs (Not-OK status), the service (or the host) goes into the SOFT state

  3. After the Max Check Attempts exceeded and if the service (or the host) persists in its Not-OK status its state changes from SOFT to HARD. The monitoring engine caches the notification number for the service (or the host): i.e. 0.

At each interval or sending of notification to the service (or the host) and until the end of the Not-OK status, the monitoring engine performs the following operations:

  1. If no notification escalation is defined for the service (or the host) and the current notification number, the notification is processed in the same way as for a normal notification: the monitoring engine uses the notification configuration defined for the service (or the host).

  2. If a notification escalation is defined for the service (or the host) and the current notification number, the monitoring engine bases itself on the configuration of the escalation to select the contacts to be notified and the mechanism to be used.

  3. The processing mechanism for a notification is the same as the sending of a normal notification

For information the configuration of notification escalations is defined in the chapter covering The notifications escalations.