Notifications

Une grande partie de la complexité du système de notification de Checkmk tient à ses nombreuses options de réglage, qui permettent d’éviter les notifications sans importance. Dans la plupart des cas, il s’agit de situations où les notifications sont déjà retardées ou supprimées lorsqu’elles surviennent. De plus, le noyau de supervision dispose d’une intelligence intégrée qui supprime certaines notifications par défaut. Nous souhaitons aborder tous ces aspects dans ce chapitre.

Lorsqu’un ordinateur hôte ou un service est en période de maintenance planifiée, les notifications de l’objet sont supprimées. C’est là — parallèlement à une évaluation correcte des disponibilités — la raison la plus importante justifiant la prise en compte des périodes de maintenance dans la supervision. Les détails suivants sont pertinents à cet égard :

Vous pouvez définir une période de notification pour chaque ordinateur hôte et chaque service lors de la configuration. Il s'agit d'une période de temps qui définit le délai dans lequel la notification doit être limitée.

La configuration s'effectue à l'aide de l'Monitoring Configuration > Notification period for hosts, ou respectivement du jeu de règles Notification period for services, que vous pouvez trouver rapidement via la recherche dans le menu de configuration. Un objet qui ne se trouve pas actuellement dans une période de notification sera signalé par une icône de pause grise .

Les événements de supervision concernant un objet qui ne se trouve pas actuellement dans sa période de notification ne feront pas l'objet d'une notification. Ces notifications seront « réémises » lorsque la période de notification sera à nouveau active – si l'ordinateur hôte/le service se trouve toujours dans un état problématique. Seul l'état le plus récent fera l'objet d'une notification, même si plusieurs changements d'état de l'objet se sont produits pendant la période hors de la période de notification.

Par ailleurs, dans les règles de notification, il est également possible de limiter une notification à une période de temps spécifique. De cette manière, vous pouvez restreindre davantage les périodes. Toutefois, les notifications qui ont été ignorées en raison d’une règle comportant des conditions temporelles ne seront pas automatiquement répétées ultérieurement !

Si un ordinateur hôte a complètement échoué, ou est au moins inaccessible à la supervision, ses services ne peuvent évidemment plus être surveillés. Les vérifications actives enregistreront alors en règle générale « CRIT » ou « UNKNOWN », car elles tenteront activement d’accéder à l’ordinateur hôte et rencontreront ainsi une erreur. Dans une telle situation, toutes les autres vérifications — soit la grande majorité — seront omises et resteront donc dans leur ancien état. Celles-ci seront signalées par l’icône « stale time » (Temps de surveillance) .

Il serait naturellement très fastidieux que toutes les vérifications actives se trouvant dans un tel état signalent leurs problèmes. Par exemple, si un serveur web n’est pas accessible — et que cela a déjà été signalé —, il ne serait pas très utile de générer en plus un courrier électronique pour chacun de ses services HTTP dépendants.

Afin de minimiser ce type de situations, le noyau de supervision ne génère en principe des notifications pour les services que si l’ordinateur hôte se trouve dans l’état « UP ». C’est également la raison pour laquelle l’accessibilité de l’ordinateur hôte est vérifiée séparément. Sauf configuration contraire, cette vérification s’effectue à l’aide d’un Smart Ping ou d’un ping.

Si vous utilisez Checkmk Community (ou l’une des éditions commerciales avec un noyau du processeur Nagios), il peut néanmoins arriver, dans des cas isolés, qu’un problème d’ordinateur hôte génère une notification pour un service actif. La raison en est que Nagios considère que les résultats des vérifications d’ordinateur hôte restent valides pendant un court laps de temps. Même si seules quelques secondes se sont écoulées entre le dernier ping réussi vers le serveur et la vérification active suivante, Nagios peut encore considérer l’ordinateur hôte comme «UP» alors qu’il est en réalité «DOWN». En revanche, le Checkmk Micro Core (CMC) maintiendra la notification de service en mode «standby» jusqu’à ce que l’état de l’ordinateur hôte ait été vérifié, minimisant ainsi de manière fiable les notifications indésirables.

Imaginez qu’un routeur réseau important pour un site d’entreprise comptant des centaines d’ordinateurs hôtes tombe en panne. Tous ses ordinateurs hôtes seront alors indisponibles pour la supervision et passeront à l’état « DOWN ». Des centaines de notifications seront donc déclenchées. Ce n’est pas souhaitable.

Afin d’éviter de tels problèmes, le routeur peut être défini comme hôte parent pour ses hôtes. S’il existe des hôtes redondants, plusieurs hôtes parents peuvent également être définis. Dès que tous les hôtes parents entrent en état d’DOWN, les hôtes qui ne sont plus joignables seront signalés comme étant en état d’UNREACH et leurs notifications seront supprimées. Le problème concernant le routeur lui-même fera bien sûr toujours l’objet d’une notification.

À noter que le CMC fonctionne en interne d’une manière légèrement différente de Nagios. Afin de réduire les fausses alertes tout en traitant les notifications valides, le CMC accorde une attention particulière aux heures exactes des vérifications des ordinateurs hôtes concernés. Si une vérification d’ordinateur hôte échoue, le noyau du processeur attendra le résultat de la vérification de l’ordinateur hôte parent avant de générer une notification. Cette attente est asynchrone et n'a aucun effet sur la supervision générale. Les notifications provenant des ordinateurs hôtes peuvent ainsi ne subir que des retards minimes.

Checkmk est configuré « par défaut » de telle sorte que, lorsqu’un événement de supervision se produit, un courrier électronique de notification est envoyé à chaque contact associé à l’ordinateur hôte ou au service concerné. Cela semble certes judicieux au premier abord, mais dans la pratique, de nombreuses autres exigences apparaissent, par exemple :

Checkmk vous offre une flexibilité maximale pour mettre en œuvre ces exigences grâce à son mécanisme basé sur des règles.

Dans la configuration des notifications, vous gérez la chaîne de règles de notification, qui détermine qui doit être averti et de quelle manière. Lorsqu’un événement de supervision se produit, cette chaîne de règles est exécutée de haut en bas. Chaque règle comporte une condition qui détermine si la règle s’applique effectivement à la situation en question.

Si la condition est remplie, la règle détermine deux choses :

Important : contrairement aux règles pour les ordinateurs hôtes et les services, ici l'évaluation se poursuit même après que la règle applicable a été satisfaite. Les règles suivantes peuvent ajouter d'autres notifications. Les notifications générées par les règles précédentes peuvent également être supprimées.

Le résultat final de l'évaluation de la règle sera un tableau dont la structure ressemblera à ceci :

Désormais, pour chaque entrée de ce tableau, le script de notification qui exécute effectivement la notification de l'utilisateur correspondant à la méthode sera appelé.

Il se peut que vous disposiez de services qui entrent occasionnellement dans un état de problème pendant de courtes périodes, mais les interruptions sont très brèves et ne sont pas critiques pour vous. Dans de tels cas, les notifications sont très gênantes, mais peuvent être facilement désactivées. Les jeux de règles Delay host notifications et Delay service notifications sont adaptés à cette situation.

Vous spécifiez ici une durée en minutes — et une notification sera retardée jusqu’à ce que ce délai soit écoulé. Si l’état « OK » / « UP » se reproduit avant cela, aucune notification ne sera déclenchée. Naturellement, cela signifie également que la notification d’un véritable problème sera retardée.

Il va sans dire que l’élimination de la cause réelle des problèmes sporadiques serait bien préférable au report des notifications — mais c’est bien sûr une autre histoire…​

Une autre méthode très similaire pour retarder les notifications consiste à autoriser plusieurs tentatives de vérification lorsqu’un service entre dans un état de problème. Ceci est réalisé à l’aide de l’Maximum number of check attempts for hosts, ou respectivement, du jeu de règles Maximum number of check attempts for service.

Si vous définissez ici une valeur de 3, par exemple, une check dont le résultat est CRIT ne déclenchera dans un premier temps aucune notification. On parle alors de soft state (CRIT). L’état dur reste OK. Ce n’est que si trois tentatives successives renvoient un état « not-OK » que le service passera à l’état dur et qu’une notification sera déclenchée.

Contrairement aux notifications différées, vous avez ici la possibilité de définir des vues de manière à ce que ces problèmes ne s’affichent pas. Une agrégation BI peut également être configurée de sorte à n’inclure que les états durs, et non les états mous.

Lorsqu’un ordinateur hôte ou un service change fréquemment d’état sur une courte période, on parle d’« état instable ». Il s’agit d’un état réel. Le principe ici est de réduire les notifications excessives pendant les phases où un service ne fonctionne pas (tout à fait) de manière stable. Ces phases peuvent également faire l’objet d’une évaluation spécifique dans les statistiques de disponibilité.

Les objets instables sont signalés par l’icône «». Tant qu’un objet est instable, les changements d’état successifs ne déclenchent aucune notification supplémentaire. Une notification sera toutefois déclenchée chaque fois que l’objet entre ou sort de l’état d’instabilité.

La détection de l’instabilité par le système peut être influencée de la manière suivante :

Consultez l'aide contextuelle d'Help > Show inline help pour plus de détails sur les valeurs personnalisables.

Pour commencer, nous allons vous montrer comment consulter l'historique des notifications au niveau de l'ordinateur hôte et au niveau de service dans Checkmk afin de pouvoir suivre le processus de notification.

Un événement de supervision qui déclenche une notification dans Checkmk est, par exemple, le changement d'état d'un service. Vous pouvez déclencher manuellement ce changement d'état à l'aide de l'instruction « Fake check results » à des fins de test.

Pour tester la notification, vous pouvez ainsi faire passer un service de l'état « OK » à « CRIT ». Si vous affichez maintenant les notifications pour ce service sur la page de détails du service à l'aide de Service > Service notifications , vous verrez les entrées suivantes :

L'entrée la plus récente se trouve en haut de la liste. Cependant, la première entrée se trouve en bas ; examinons donc les entrées une par une, de bas en haut :

Afin de faciliter la bonne compréhension des contextes de toutes les différentes options de configuration et conditions de base, et de permettre un diagnostic précis des problèmes lorsqu’une notification apparaît ou ne s’affiche pas comme prévu, nous décrivons ici tous les détails du processus de notification, y compris l’ensemble des composants impliqués.

Les composants suivants interviennent dans le système de notification de Checkmk :

Une fois que le noyau du processeur a généré une notification brute, celle-ci passe par la chaîne de règles de notification, ce qui donne lieu à un tableau de notifications. Outre les données de la notification brute, chaque notification contient les informations supplémentaires suivantes :

Dans le cas d'une transmission synchrone, un script de notification approprié est alors exécuté pour chaque entrée du tableau. Dans le cas d'une transmission asynchrone, une notification est transmise sous forme de fichier au spouleur de notification.

Le spouleur de notification est une fonction complémentaire puissante des éditions commerciales. Il permet une transmission asynchrone des notifications. Que signifie « asynchrone » dans ce contexte ?

Une livraison synchrone est alors envisageable si le script de notification s'exécute rapidement et, surtout, ne peut entraîner aucun timeout. Avec les méthodes de notification qui accèdent à des spoolers existants, cela va de soi. Les services de spool du système peuvent être utilisés notamment avec les courriers électroniques et les SMS. Le script de notification transmet un fichier au spooler — avec cette procédure, aucun état d'attente ne peut se produire.

Lorsque vous utilisez la livraison traçable via SMTP ou d’autres scripts établissant des connexions réseau, vous devez toujours recourir à la livraison asynchrone. Cela s’applique également aux scripts qui envoient des messages texte (SMS) via HTTP sur internet. Les timeouts lors de l’établissement d’une connexion à un service réseau peuvent durer jusqu’à plusieurs minutes, provoquant un engorgement comme décrit ci-dessus.

La bonne nouvelle, c’est que la livraison asynchrone est activée par défaut dans Checkmk. D’une part, le spouleur de notification (mknotifyd) est également lancé au démarrage de l’instance, ce que vous pouvez vérifier à l’aide de l’instruction suivante :

D'autre part, la transmission asynchrone (Asynchronous local delivery by notification spooler) est sélectionnée dans Global settings > Notifications > Notification Spooling :

La supervision n'est utile que si l'on peut s'y fier. Cela implique que les notifications soient reçues de manière fiable et rapide. Malheureusement, la livraison des courriers électroniques n'est toutefois pas tout à fait optimale. L'envoi est généralement traité en transmettant le courrier électronique au serveur SMTP local. Celui-ci tente de livrer le courrier électronique de manière autonome et asynchrone.

En cas d’erreur temporaire (par exemple, lorsque le serveur SMTP destinataire n’est pas joignable), le courrier électronique est placé dans une file et une nouvelle tentative est effectuée ultérieurement. Ce « ultérieurement » intervient généralement après 15 à 30 minutes. À ce moment-là, la notification pourrait bien arriver bien trop tard !

Si le courrier électronique ne peut vraiment pas être remis, le serveur SMTP génère un message d’erreur clair dans son fichier journal et tente d’envoyer un courrier électronique d’erreur à l’« expéditeur ». Mais le système de supervision n’est pas un véritable expéditeur et ne peut pas non plus recevoir de courriers électroniques. Il s’ensuit que ces erreurs disparaissent tout simplement et que les notifications font alors défaut.

Les éditions commerciales offrent la possibilité d’une livraison traçable via SMTP. Cela se fait intentionnellement sans l’aide du serveur de messagerie local. Au lieu de cela, Checkmk envoie lui-même le courrier électronique à votre hôte intelligent via SMTP, puis évalue lui-même la réponse SMTP.

De cette manière, non seulement les erreurs SMTP sont traitées de manière intelligente, mais une livraison correcte est également documentée avec précision. C'est un peu comme une lettre recommandée : Checkmk reçoit un accusé de réception de l'hôte intelligent SMTP (serveur de réception) confirmant que le courrier électronique a bien été accepté — y compris un identifiant de courrier.

Le processus pratique de configuration des notifications avec suivi de la livraison via SMTP est décrit dans les règles de notification globales et dans les règles de notification personnelles.

À ce jour, la livraison synchrone incluant les messages d’erreur et la traçabilité n’a été mise en œuvre que pour les courriers électroniques HTML. Vous trouverez dans le chapitre consacré à la rédaction de vos propres scripts comment renvoyer un statut d’erreur dans un script de notification que vous avez vous-même écrit.

Les notifications peuvent prendre des formes multiples et variées. En voici quelques exemples typiques :

C'est pourquoi Checkmk fournit une interface très simple qui vous permet d'écrire vos propres scripts de notification. Ceux-ci peuvent être écrits dans n'importe quel langage de programmation pris en charge par Linux, même si Shell, Perl et Python représentent à eux trois 95 % du « marché ».

Les scripts standard fournis avec Checkmk se trouvent dans ~/share/check_mk/notifications. Ce répertoire fait partie intégrante du logiciel et n’est pas destiné à être modifié. Enregistrez plutôt vos propres scripts dans ~/local/share/check_mk/notifications. Assurez-vous que vos scripts sont exécutables (chmod +x). Ils seront alors détectés automatiquement et mis à disposition pour être sélectionnés dans les règles de notification.

Si vous souhaitez personnaliser un script standard, il vous suffit de le copier depuis ~/share/check_mk/notifications vers ~/local/share/check_mk/notifications et d’y apporter vos modifications dans la copie. Si vous conservez le nom d’origine, votre script remplacera automatiquement la version standard et aucune modification ne sera nécessaire dans les règles de notification existantes.

En cas de notification, votre script sera exécuté avec les autorisations de l'utilisateur de l'instance. Dans les variables d'environnement commençant par NOTIFY_, le script recevra toutes les informations concernant l'ordinateur hôte/le service concerné, l'événement de supervision, les contacts à notifier et les paramètres spécifiés dans la règle de notification.

Les textes que le script écrit dans la sortie standard (avec print, echo, etc.) apparaissent dans le fichier journal du module de notification ~/var/log/notify.log.

Les scripts de notification ont la possibilité d’utiliser un code de sortie pour indiquer si une erreur réplicable ou finale s’est produite :

De plus, dans tous les cas, la sortie standard du script de notification, ainsi que le statut, seront enregistrés dans l’historique des notifications de l’ordinateur hôte/du service et seront donc visibles dans l’interface graphique.

Important : les notifications traçables ne sont pas disponibles pour les notifications groupées !

Le traitement des erreurs de notification du point de vue de l’utilisateur sera expliqué dans le chapitre consacré à la livraison traçable via SMTP.

À titre d'exemple, vous pouvez créer un script qui écrit toutes les informations relatives à la notification dans un fichier. Le langage de programmation utilisé est le shell Bash de Linux :

Rendez ensuite le script exécutable :

Voici quelques explications concernant le script :

Pour que le script soit utilisé, vous devez le définir comme méthode dans une règle de notification. Les scripts écrits par vos soins ne comportent pas de déclaration de paramètres ; par conséquent, toutes les cases à cocher telles que celles proposées, par exemple, dans la méthode « HTML Email », seront absentes. À la place, vous pouvez saisir une liste de textes en tant que paramètres qui seront disponibles pour le script sous la forme « NOTIFY_PARAMETER_1 », « NOTIFY_PARAMETER_2 », etc. Pour un test, fournissez les paramètres « Fröhn », « Klabuster » et « Feinbein » :

Pour effectuer le test, configurez le service CPU load sur l'ordinateur hôte myserver pour qu'il envoie des notifications à CRIT — à l'aide de l'instruction Fake check results. Dans le fichier journal du module de notification ~/var/log/notify.log, vous verrez alors l'exécution du script, y compris les paramètres et le fichier spool généré :

Le fichier ~/tmp/foobar.out contient désormais une liste alphabétique de toutes les variables d’environnement Checkmk qui incluent des informations concernant la notification. Vous pouvez ainsi vous repérer pour savoir quelles valeurs sont disponibles pour votre script. Voici les dix premières lignes :

Les paramètres sont également disponibles :

Dans l'exemple ci-dessus, vous avez vu un certain nombre de variables d'environnement qui seront transmises au script. Les variables disponibles dépendent précisément du type de notification, de la version et de l'édition de Checkmk, ainsi que du noyau de supervision utilisé (CMC ou Nagios). Outre l'astuce avec l'instruction « env », il existe deux autres moyens d'obtenir la liste complète de toutes les variables :

Vous trouverez ci-dessous une liste des variables les plus importantes :

Si votre script doit prendre en charge les notifications groupées, il devra être spécialement préparé, car il doit envoyer plusieurs notifications simultanément. Pour cette raison, une transmission via des variables d'environnement ne fonctionne pas non plus de manière pratique.

Donnez un nom à votre script à la troisième ligne de l'en-tête comme ci-dessous — le module de notification enverra alors les notifications via l'entrée standard :

The script will receive blocks of variables via the standard input. Each line has the form: NAME=VALUE. The blocks are separated by blank lines. The ASCII character with code 1 (\a) is used to represent line breaks in the text.

Le premier bloc contient une liste de variables générales (par exemple, des paramètres d'appel). Chaque bloc suivant assemble les variables en une notification.

La meilleure recommandation est de l'essayer vous-même avec un test simple qui écrit les données complètes dans un fichier afin que vous puissiez voir comment les données sont envoyées. Vous pouvez utiliser le script de notification suivant à cette fin :

Testez le script comme décrit ci-dessus et activez en outre l'option « Notification Bulking » dans la règle de notification.

Dès son installation, Checkmk fournit déjà toute une gamme de scripts permettant de réaliser des connexions aux services de messagerie instantanée, aux plateformes de gestion des incidents et aux systèmes de tickets les plus courants et les plus utilisés. Vous trouverez des informations sur l'utilisation de ces scripts dans les articles suivants :

Les fichiers journaux du serveur SMTP sont des fichiers système et leurs chemins d'accès absolus sont répertoriés ci-dessous. L'emplacement exact où les fichiers journaux sont stockés dépendra de votre distribution Linux.