J'ai reçu de nombreuses questions sur le fonctionnement des notifications. Ce document essaiera d'expliquer exactement quand et comment les notifications pour les hôtes et les services sont émises, et qui les reçoit.
La décision d'émettre des notifications est prise dans le cadre du contrôle de service et du contrôle d'hôte. Les notifications d'hôte et de service ont lieu dans les cas suivants …
Chaque définition de service comprend un paramètre <contact_groups> qui définit quels groupes de contacts recevront les notifications de ce service. Chaque groupe de contacts peut contenir un ou plusieurs contacts individuels. Quand Nagios® émet une notification de service, il notifie chaque contact membre d'un des groupes de contacts spécifiés dans le paramètre <contactgroups> de la définition du service. Nagios® est conscient qu'un contact peut être membre de plus d'un groupe, donc il commence par supprimer les doublons.
Chaque définition d'hôte comprend un paramètre <contact_groups> qui définit quels groupes de contacts recevront les notifications de cet hôte. Quand Nagios® émet une notification d'hôte, il notifie chaque contact membre d'un des groupes de contacts à notifier pour cet hôte. Nagios® supprime les doublons de la liste des contacts avant toute chose.
Le simple fait qu'une notification d'hôte ou de service doive être émise ne signifie pas que des contacts vont la recevoir. Il y a plusieurs filtres qu'une notification doit traverser avant d'être jugée valable pour l'émission. Même alors, des contacts peuvent ne pas la recevoir si leurs filtres de notification ne le permettent pas. Voyons en détail les filtres à traverser…
Le premier filtre que les notifications doivent traverser est un test pour savoir si les notifications sont activées au niveau global du programme ou non. Ceci est spécifié par le paramètre enable_notifications du fichier de configuration principal, mais peut être modifié en cours d'exécution via l'interface web. Si les notifications sont désactivées de manière globale, aucune notification ne sera envoyée - point final. Si elles sont activées, il y a encore d'autres tests à réussir…
Le premier filtre des notifications d'hôte et de service consiste à vérifier que l'hôte ou le service n'est pas dans une période d'arrêt planifié. Si c'est le cas, personne n'est notifié. S'il n'est pas dans une période d'arrêt planifié, la notification est passée au filtre suivant. Notez également que les notifications de services sont supprimées si l'hôte auquel est associé le service est dans une période d'arrêt planifié.
Le deuxième filtre des notifications d'hôte et de service consiste à vérifier si l'hôte ou le service oscille (à condition que vous ayez activé la détection d'oscillation). Si le service ou l'hôte oscille, personne n'est notifié. Sinon, la notification est passée au filtre suivant.
Le troisième filtre à traverser pour les notifications d'hôte et de service est formé par les paramètres de notification. Chaque définition de service contient des paramètres qui déterminent si les notifications doivent être envoyées pour les états WARNING, CRITICAL, et RECOVERY. De la même manière, chaque définition d'hôte contient des paramètres qui déterminent si les notifications doivent être envoyées quand l'hôte s'arrête [NdT: état DOWN], devient inaccessible [UNREACHABLE], ou se rétablit [RECOVERY]. Si la notification d'hôte ou de service est bloquée par ces paramètres, personne n'est notifié. Dans le cas contraire, la notification est passée au filtre suivant… Note : les notifications concernant les rétablissement d'hôtes et de services ne sont émises que si une notification a été envoyée à l'apparition du problème. Cela n'a pas de sens de recevoir une notification de rétablissement pour un problème dont vous n'aviez pas connaissance…
Le quatrième filtre des notifications d'hôte et de service à traverser concerne la période. Chaque définition d'hôte et de service comporte un paramètre <notification_period> qui spécifie quelle période contient les heures de notification valides pour cet hôte ou service. Si le moment où la notification apparaît n'est pas dans une plage valide de la période spécifiée, personne n'est contacté. Dans le cas contraire, la notification est passée au filtre suivant… Note : si le filtre de période n'est pas traversé, Nagios® réordonnancera la prochaine notification pour l'hôte ou le service (s'il est dans un état non-OK) dans la prochaine plage de temps valide pour la période. Cela permet de s'assurer que les contacts sont notifiés des problèmes dès que possible quand arrive le prochain moment valide de la période.
Le dernier jeu de filtres d'hôte et de service est conditionnée par deux éléments : (1) une notification a déjà été émise par le passé concernant un problème avec l'hôte ou le service, et (2) l'hôte ou le service est resté dans le même état non-OK depuis la dernière notification. Si ces deux conditions sont réunies, Nagios® vérifie que le temps écoulé depuis l'émission de la dernière notification est supérieur ou égal à la valeur spécifiée par le paramètre <notification_interval> de la définition de l'hôte ou du service. Si le temps écoulé depuis la dernière notification est insuffisant, personne n'est contacté. Si un temps suffisant s'est écoulé, ou si les deux conditions de ce filtre n'ont pas été réunies, la notification sera émise ! Le fait qu'elle parvienne ou non aux contacts individuels relève d'un autre jeu de filtres…
A ce point la notification a traversé le filtre du mode de programme et tous les filtres d'hôte et de service, et Nagios® commence à envoyer des notifications à tous ceux qui doivent en recevoir. Cela signifie-t-il que tous les contacts vont recevoir la notification ? Non ! Chaque contact possède son propre jeu de filtres que la notification doit traverser avant qu'ils ne la reçoivent. Note : les filtres de contact sont propres à chaque contact et n'affectent pas la façon dont les autres contacts reçoivent les notifications.
Le premier filtre à passer pour chaque contact concerne les paramètres de notification. Chaque définition de contact comprend des paramètres qui déterminent si les notifications de service peuvent être émises pour les états WARNING, CRITICAL, et RECOVERY. Chaque définition de contact contient également des options qui déterminent si les notifications d'hôte peuvent être émises lorsqu'un hôte passe dans les états DOWN, UNREACHABLE, ou RECOVERY. Si la notification d'hôte ou de service ne remplit pas ces conditions, les contacts ne recevront pas de notification. Dans le cas contraire, la notification est passée au prochain filtre… Note : les notifications concernant les rétablissement d'hôtes et de services ne sont émises que si une notification a été envoyée à l'apparition du problème. Cela n'a pas de sens de recevoir une notification de rétablissement pour un problème dont vous n'aviez pas connaissance…
Le dernier filtre à passer pour chaque contact concerne la période. Chaque définition de contact comprend un paramètre <notification_period> qui spécifie la période durant laquelle on peut envoyer des notification à ce contact. Si l'heure à laquelle la notification est faite n'est pas comprise dans la plage de temps de la période spécifiée, le contact ne recevra pas la notification. Dans le cas contraire, le contact la reçoit !
On m'a plusieurs fois demandé pourquoi les méthodes de notification (pager, etc.) ne sont pas directement intégrées au code de Nagios®. La réponse est simple - cela n'aurait pas beaucoup de sens. Nagios® n'est pas prévu pour être une application "tout-en-un". Si les contrôles de service étaient intégrés dans le cœur de Nagios®, il serait très difficile pour les utilisateurs d'ajouter de nouvelles méthodes de contrôle, de modifier celles qui existent, etc. Les notifications fonctionnent de la même manière. Il y a mille et une façons d'envoyer des notifications et de nombreux modules ont déjà été développés pour faire le sale boulot, alors pourquoi réinventer la roue, et vous contenter d'un pneu de vélo ? Il est bien plus facile de déléguer à une application externe (c.-à-d. un simple script ou un système de messagerie complet) ce travail complexe. Des modules de messagerie qui peuvent traiter les notifications pour les pagers ou les téléphones portables sont listés ci-dessous, dans la section des ressources.
Lorsque vous bricolez vos commandes de notification, vous devez prendre en compte le type de notification qui se présente. La macro $NOTIFICATIONTYPE$ contient une chaîne de caractéres qui identifie précisément cela. Le tableau ci-dessous liste les valeurs possibles de cette macro et leur description :
| Valeur | Description |
|---|---|
| PROBLEM | Un service ou un hôte vient de passer (ou est encore) dans un état dénotant un problème. S'il s'agit d'une notification de service, cela signifie que le service est dans un état WARNING, UNKNOWN ou CRITICAL. Si c'est une notification d'hôte, cela signifie que l'hôte est dans l'état DOWN ou UNREACHABLE. |
| RECOVERY | Un service ou un hôte s'est rétabli. S'il s'agit d'une notification de service, cela signifie que le service vient de retourner dans l'état OK. Si c'est une notification d'hôte, cela signifie que l'hôte vient de reprendre l'état UP. |
| ACKNOWLEDGEMENT | Cette notification est liée à l'acquittement d'un problème d'hôte ou de service. Les notifications d'acquittement sont générées via l'interface web par les contacts de l'hôte ou du service concerné. |
| FLAPPINGSTART | L'hôte ou le service vient de commencer à osciller. |
| FLAPPINGSTOP | L'hôte ou le service vient de s'arrêter d'osciller. |
Il y a bien des moyens de configurer Nagios® pour envoyer des notifications. C'et à vous de décider de la (des) méthode(s) que vous voulez utiliser. Une fois ce choix fait, vous devrez installer les logiciels nécessaires, et définir les commandes de notification dans vos fichiers de configuration avant de pouvoir les utiliser. Voici quelques méthodes de notification possibles :
En gros, tout ce que vous pouvez faire en ligne de commande peut être adapté sous forme de commande de notification.
Si vous voulez envoyer une notification alphanumérique à votre pager ou à votre téléphone portable via email, vous trouverez peut-être les informations suivantes utiles [NdT : et si vous êtes aux USA]. Voici quelques hyperliens vers divers fournisseurs de service de messagerie, qui expliquent comment envoyer des messages alphanumériques aux pagers et aux téléphones portables…
Si vous cherchez à envoyer des messages à votre pager ou à votre téléphone portable sans email, jetez un coup d'œil aux applications suivantes. Elles peuvent être utilisées en conjonction avec Nagios® pour envoyer une notification via un modem quand un problème arrive. De cette façon, vous n'êtes pas dépendant de l'email pour émettre des notifications (gardez à l'esprit que l'email peut *ne pas* fonctionner s'il y a des problèmes réseau). Je n'ai pas personnellement essayé ces applications, mais certains m'ont dit l'avoir fait avec succès…
Si vous désirez une méthode atypique, vous pouvez essayer de vous amuser avec les alertes sonores. Si vous voulez des alertes sonores sur le serveur de supervision (avec voix synthéthique), essayez Festival [Anglais]. Si vous voulez les recevoir sur une autre machine, testez le Network Audio system (NAS) [Anglais] et rplay [Anglais].
Enfin, il y a un espace dans la section des contributions de la page d'accueil de Nagios® [Anglais] pour les scripts de notification réalisés par des utilisateurs. Vous pouvez y trouver votre bonheur, dans la mesure où ils gèrent le sale boulot nécessaire à l'émission de notifications alphanumériques…