Supervision : comprendre les notifications de A à Z

I. Présentation des notifications en supervision

Je vais vous expliquer ici comment fonctionne le processus de notification dans un système de supervision open source. Je me suis basé sur la configuration de Naemon, mais c’est parfaitement applicable sur d’autres systèmes comme Nagios, Inciga ou Shinken.

Je considère un bon système de supervision quand celui-ci donne des alertes pertinentes. C’est-à-dire déclenchés au bon moment, au bon endroit aux bonnes personnes. Une bonne supervision dépend uniquement de sa rigueur dans la configuration. Ici seront abordés 80% des paramètres permettant de configurer une notification pertinente. Les 20% restant sont la capacité à contrôler les bonnes choses et définir les bons seuils d’alerte (je dis ça comme ça, mais ce n’est pas loin de la vérité je pense 😉 ).

Alors vous êtes prêt ? Alors c’est parti !

Avant commencer à aborder le fonctionnement pur et dur des notifications, il y quelques notions importantes à comprendre.
Chaque hôte et service est défini par un état :

Services : OK, WARNING, CRITICAL, UNKNOWN
Hôtes : UP, DOWN, UNRECHABLE

Ces états peuvent être de deux types, SOFT ou HARD. Le statut SOFT indique que le contrôle vient de changer d’état. Le statut HARD lui confirme l’état du service.

Par exemple je viens de remonter un problème (état CRITICAL : c’est l’état que je constate ; statut SOFT : je ne suis pas sûr que cela soit réellement une erreur) alors, je refais mon contrôle. Mon nouveau contrôle est de nouveau une erreur (état CRITICAL : c’est l’état que je constate ; statut HARD : Je confirme l’état, je l’ai vérifié !)

Après dans la pratique c’est un peu plus compliqué, mais retenez ça c’est une très bonne base. Je rajouterais juste que pour chaque objet hôte ou service, nous pouvons définir le nombre de fois que le contrôle devra être vérifié avant de passer en statut HARD avec le paramètre max_check_attempts.
Dans un objet hôte ou service voici comment on définit ces paramètres

max_check_attempts 3

En mettant le paramètre max_check_attempts à 1, ceci aura pour effet de valider l’état constaté directement au changement d’état.

Maintenant, je peux vous dire que le processus de notification se déclenche lorsque j’ai un changement d’état « validé » (HARD). C’est-à-dire que si je change d’état, mais qu’il n’est pas confirmé, rien ne se passe.
J’attire votre attention sur les intervalles de contrôles. Pensez à calculer les délais minimum et maximum de déclenchement de notifications suivant vos intervalles. On définit en minutes l’intervalle entre deux contrôles avec le paramètre check_interval. Après la détection d’un état non OK, on peut aussi accélérer l’intervalle entre deux contrôles avec le paramètre retry_interval.

Mon délai minimum de notification sera toujours égal à (retry_interval x (max_check_attempts – 1) ) moins 1 parce que mon premier retour non OK compte. Pour avoir mon délai maximum de notification, on ajoute le check_interval au délai minimum. Exemple avec les paramètres suivant :

check_interval 5 # temps en minutes
retry_interval 2 # temps en minutes
max_check_attempts 3 # nombre de tentatives

Mon intervalle entre deux contrôles quand tout va bien est de 5 minutes. Lorsque je recevrai un contrôle non OK, il sera ré exécuté 2 fois avant de passer en statut HARD. On ne fera pas 3 tentatives parce que le premier retour non OK compte comme le 1er essai. Mes intervalles entre chaque contrôle seront alors réduits à 2 minutes. Autrement dit, il y aura au minimum 4 minutes entre le moment où je détecte l’incident et le moment où je le valide (délai minimum).

Admettons que j’exécute mon contrôle et que tout va bien. Pas de bol mon incident intervient juste après. Je ne m’en rendrais compte que lors du prochain contrôle, 5 minutes après. À ce moment-là, on est dans un état non OK mais statut SOFT. Je dois effectuer encore 2 contrôles avec 2 minutes d’intervalle pour passer mon état en statut HARD. Mon processus de notification sera donc déclenché environ 9 minutes après l’incident réel (délai maximum).

J’espère que j’ai réussi à être clair si c’est le cas vous me direz que c’est nul ! Recevoir une notification entre 4 et 9 minutes après un incident ça ne sert à rien ! Je vous répondrais que cela dépend de la situation, mais ne mettez pas tous vos contrôles avec un intervalle d’une minute. C’est inutile et vous risquez surtout de surcharger le système et les contrôles prendront du retard. C’est comme dans une gare, si vous mettez tous les trains à suivre, le temps que chacun s’arrête vous aurez un bouchon.

Ce qu’il faut savoir c’est qu’ici nous sommes sur des contrôles actifs, vous verrez qu’on peut mettre en place des contrôles qui remontent un état instantanément, mais ce n’est pas le sujet ici.

II. Contrôles avant déclenchement des notifications

Maintenant avant de déclencher une notification, le système va passer le contrôle dans plusieurs filtres pour s’assurer qu’il doit déclencher une notification. Nous allons aborder ces filtres comme des questions que pourrait se poser le système superviseur.

1. Les notifications sont-elles activées ?

Dans le fichier de configuration principal, ce paramètre affecte l’ensemble des hôtes et services. Il peut également être spécifié dans un objet hôte ou service qui aura pour effet de désactiver les notifications sur l’objet cible. Dans le fichier de configuration principal (naemon.cfg, nagios.cfg, shinken.cfg…)

enable_notification=[0/1]

Attention, dans un objet hôte ou service, la syntaxe est légèrement différente.

notifications_enabled [0/1]

• 0 : les notifications sont désactivées
• 1 : les notifications sont activées (par défaut)

Si oui on passe au filtre suivant. Celui-ci était plutôt simple.

2. Était-il prévu que l’hôte ou le service retourne un état non OK ?

Quand nous savons qu’un contrôle peut retourner un état non OK, parce que je sais que je vais changer un disque sur un serveur par exemple (c’est donc prévu). Je peux dire que sur cette période de temps, si le contrôle est non OK c’est normal. C’est ce qu’on appelle un scheduled downtime. Je ne détaillerais pas ici cette notion. C’est assez particulier, mais sachez que ça ne se définit pas dans les fichiers de configuration.

En tout cas si nous sommes dans une période scheduled downtime, pas de notification. Sinon on passe à la suite !

3. Le contrôle est-il en oscillation ?

L’oscillation (flapping) c’est quand un contrôle passe régulièrement d’un état OK à non OK. Il est alors considéré instable. Il est possible de surveiller ce genre de situation en activant le paramètre flap detection. À partir de ce moment, si le système considère que le contrôle est en oscillation il ne déclenchera pas de notification. Ça évite de se faire spammer quand le processeur du serveur est à la limite des seuils d’alerte. Comme pour le scheduled downtime je ne vais pas détailler ici l’algorithme qui déterminera si le service est en oscillation ou non. Retenez que c’est un calcul qui retourne un pourcentage sur les 21 derniers contrôles et que vous pouvez activer ou non cette détection avec ces paramètres :

Dans le fichier de configuration générale (active ou désactive pour tout le système)

enable_flap_detection=[0/1]

Directement dans un objet hôte ou service

flap_detection_enabled [0/1]

• 0 : la détection est désactivée
• 1 : la détection est activée (par défaut)

Si le contrôle n’est pas considéré comme instable, vous aurez deviné qu’on passe au prochain test.

4. Dois-je déclencher une notification pour cet état ?

Pour cela dans chaque hôte et service on aura défini pour quel état on souhaite être alerté. Je peux dire par exemple que quand mon contrôle redevient OK, je n’ai pas envie d’être alerté. On dira plutôt alors qu’on veut être notifié de tous les états sauf OK. Voici comment le paramétrer :
Pour un objet service :

notification_options [w,u,c,r,f,s]

• w : pour l’état WARNING
• u : pour l’état UNKNOWN
• c : pour l’état CRITICAL
• r : pour RECOVERY, retour à la normale, état OK.
• f : pour FLAPPING, notifie le début et la fin d’un contrôle considéré instable.
• s : pour SCHEDULED DOWNTIME, notifie le début et la fin d’une période de « maintenance »
• n : NONE, aucune notification, reviens à désactiver les notifications

Pour un objet hôte :

notification_options [d,u,r,f,s]

• d : pour l’état DOWN
• u : pour l’état UNREACHABLE
• r : pour RECOVERY, retour à la normale, état UP.
• f : pour FLAPPING, notifie le début et la fin d’un contrôle considéré instable.
• s : pour SCHEDULED DOWNTIME, notifie le début et la fin d’une période de « maintenance »
• n : NONE, aucune notification, reviens à désactiver les notifications

Dans les deux cas, si rien n’est spécifié tous les types de notifications seront activés. Pour définir plusieurs types de notifications, séparez les arguments par une virgule.
Ça va ? Alors on passe au 5e filtre !

5. Est-ce que le changement d’état s’est fait dans une période de notification ?

Rien de compliqué, avec le paramètre notification_period on définit une période de temps sur laquelle nous voulons déclencher les notifications. Ce paramètre fait appel à un objet de type timeperiod. Ainsi on peut limiter l’exécution de notification à cette période de temps.
Dans un objet hôte ou service :

notification_period 24x7 # nom de mon objet période de temps

24x7 est un objet de type timeperiod configuré de base. Par son nom vous aurez deviné qu’il s’agit d’une période qui couvre tous les jours, 24h/24.

6. Est-ce que je renvoie une notification ?

Enfin, notre dernier filtre est un peu particulier, car il intervient sous conditions. Il faut qu’une notification ait déjà été envoyée pour un problème. Pour vous situer, j’ai vérifié (statut HARD) un état non OK sur un de mes contrôles. J’ai alors déclenché une notification. Je fais un nouveau contrôle, je suis toujours non OK. Que se passe-t-il ? Eh bien c’est le paramètre notification_interval qui va en décider. C’est lui qui donne l’intervalle (en minutes) entre chaque notification. Si au moment du contrôle cet intervalle est dépassé, je notifie de nouveau. Dans un objet hôte ou service :

notification_interval 30 # temps en minutes

La valeur par défaut de ce paramètre sera de 60 s’il n’est pas défini. La valeur par défaut peut également être modifiée dans le fichier de configuration principal.

III. Paramètres d'envois des notifications

Bon ça y est, nous sommes arrivés au moment de déclencher notre notification (enfin presque). Oui ce n’est pas vraiment terminé en réalité. Je sais que je dois déclencher une notification, mais à qui ? Comment ? C’est le paramètre contact ou contact_groups de chaque objet hôte ou service qui va nous le dire. Ce paramètre fait référence à un objet de type contact ou contactgroup. Dans un objet hôte ou service :

contacts michel, jean_pierre # nom de mon objet contact
contact_groups administrateurs # nom de mon objet groupe de contact

Vous pouvez en définir plusieurs en séparant par une virgule. Notez qu’il est « obligatoire » pour chaque objet hôte et service d’avoir au moins un contact (ou groupe) de défini. Vous aurez des erreurs warning au démarrage si ce n’est pas fait.

Vous verrez que ces objets contact sont bien plus que de simple contact (et personnellement je trouve que leurs noms sont mal choisis pour ces objets. (J’espère que j’arriverais à vous faire comprendre mon point de vue 😉 )

Donc j’ai défini dans mon objet hôte ou service, un ou plusieurs « contacts ». Je l’ai es identifié et maintenant je dois les notifier. Mais j’ai encore quelques filtres à passer ! (oui encore, mais courage c’est la fin après vous serez des as de la notif’ )

Ces filtres s’appliquent indépendamment pour chaque contact à notifier. Le premier nous l’avons déjà vu, ce sont les options de notifications. Nous pouvons sélectionner les états sur lesquelles le contact sera notifié. Ça marche exactement pareil que pour les objets hôte ou service, mais sur un contact. Dans un objet contact :

service_notification_options [w,u,c,r,f,s]
host_notification_options [d,u,r,f,s]

Vous aurez remarqué que la syntaxe est légèrement différente pour un objet contact. Le deuxième et dernier filtre (vous voyez ce n’était pas long) c’est la période de temps, nous l’avons déjà vu aussi c’est facile.
Dans un objet contact :

service_notification_period 24x7 # nom de mon objet période de temps
host_notification_period 24x7 # nom de mon objet période de temps

Là aussi vous aurez remarqué que la syntaxe est légèrement différente pour un objet contact.

On précise bien le paramètre pour les objets de type hôte ou services. Dans l’exemple j’ai mis 24h/24, mais en réalité je sais très bien que vous ne vous lèverez pas à 3h du matin pour redémarrer le serveur d’impression… (Mais le serveur de gestion des payes peut être que si ?)

Voilà maintenant je peux notifier mon contact ! Pour ça, j’utilise encore un paramètre ! La commande de notification ! Là j’appelle encore un objet, de type command cette fois ci.

host_notification_commands host-notify-by-email # nom de mon objet commande
service_notification_commands service-notify-by-email # nom de mon objet commande

Le système va tout bêtement exécuter la commande que vous avez dans votre objet commande. Du coup, sur votre machine si vous avez une commande qui permet d’envoyer un missile nucléaire. Eh bien vous pourrez envoyer un missile nucléaire lorsque vous débranchez votre accès internet ! Vous faite ce que vous voulez, vous exécutez une commande Linux, c’est no limit !

Je vous disais que l’interprétation de contact est mal choisie ici (détendez légèrement vos neurones, je vais vous expliquer). Pour moi un contact c’est une personne physique, avec un nom, une adresse, un numéro de téléphone, une adresse mail, un compte Twitter (ou pas). Bref c’est un mec avec des coordonnées pour le joindre. Coordonnées au pluriel parce que je choisis les coordonnées adaptées à la situation. On n’invite pas un copain à boire une bière par courrier hein 😉

Bien ici c’est pareil, moi M. SANTANA la journée je suis au bureau alors j’aimerais bien recevoir des notifications par mail parce que j’ai ma messagerie sous les yeux. Et j’ai un téléphone aussi au cas où il y a des gros problèmes quand je ne suis pas à mon bureau. Dans la technique si je veux faire ça, il va me falloir plusieurs contacts. Tout simplement parce que dans un objet contact je ne définis qu’un seul objet commande. Et nous sommes d’accord pour dire qu’en une seule commande je ne vais pas pouvoir choisir d’envoyer un SMS plutôt qu’un mail suivant la situation.

Le message que je voulais faire passer c’est qu’il va falloir être rigoureux et précis dans le nommage des contacts. Une petite astuce que je peux donner c’est d’utiliser les groupes de contacts. Je nomme mon groupe de contact par le nom de mon personnage (thierry_le_dsi par exemple) et dans ce groupe j’aurais les différents moyens de notifications avec plusieurs objets contact (mail_thierry, sms_thierry, …) et pour chaque contact j’aurais la commande associée à son moyen de notification.
Je vous fais un petit exemple concret pour visualiser tout ça 😉

define contactgroup {
  contactgroup_name thierry_le_DSI
  alias Thierry le directeur du système d’information
  members mail_thierry,sms_thierry
}

define contact {
  contact_name mail_thierry
  alias Contact mail de Thierry
  host_notifications_enabled 1
  service_notifications_enabled 1
  service_notification_period le_jour
  host_notification_period le_jour
  service_notification_options w,u,c,r
  host_notification_options d,u,r
  service_notification_commands service-notify-by-email
  host_notification_commands host-notify-by-email
}
define contact {
  contact_name sms_thierry
  alias Contact mail de Thierry
  host_notifications_enabled 1
  service_notifications_enabled 1
  service_notification_period le_soir
  host_notification_period le_soir
  service_notification_options w,u,c,r
  host_notification_options d,u,r
  service_notification_commands service-notify-by-sms
  host_notification_commands host-notify-by-sms
}

Ici mon contact mail_thierry ne peut être déclenché que sur la période de temps le_jour. Mais j’ai mon contact sms_thierry qui lui peut être déclenché sur la période de temps le_soir. Et donc pour chaque contact je fais appel à un objet qui exécute une commande différente. Du coup mon DSI recevra des notifications mail le jour et des notifications SMS le soir.

Et pour rappel, un groupe de contact peut en contenir un autre. Alors, n’hésitez pas à en abuser et par exemple créer un groupe directeur ou vous mettrez vos groupes thierry_le_dsi et pascal_le_pdg…

Voilà j’en ai terminé avec ce chapitre, vous avez de quoi être des AS de la notification désormais ! C’est assez général, mais le but ici était de comprendre les différents paramètres. À vous de les combiner de la bonne manière pour faire votre supervision.