 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduction
Dans la continuité de l'article « Notifications : les bases », qui décrit les principes fondamentaux des notifications, le présent article traite désormais des notifications par courrier électronique et de la création de notifications via des règles.
2. La vue d'ensemble des notifications
Vous pouvez accéder à la page d'aperçu des notifications via Setup > Events > Notification. Toutes les informations importantes concernant ce thème sont regroupées ici :
Un système de notification opérationnel repose sur l'interaction d'un certain nombre de composants qui doivent tous être configurés. Cette page d'aperçu vous évite d'avoir à rechercher les règles, paramètres, etc. individuels dans les différentes sections de Checkmk. Vous pouvez accéder à tous les aspects liés au thème des notifications à partir d'ici.
2.1. État des notifications
Un aperçu de l'état actuel des notifications s'affiche sur le côté gauche de la page :
Sont affichés :
Failed notifications |
Le nombre de notifications ayant échoué. S'il existe des notifications ayant échoué, un lien vers l'aperçu correspondant s'affiche ci-dessous. |
Total sent notifications |
Nombre de notifications envoyées. S'il existe des notifications ayant échoué, un lien vers l'Notifications of host & services, filtré sur les 7 derniers jours, s'affiche ci-dessous. Vous pouvez l'utiliser pour examiner de plus près quelles notifications ont été envoyées. |
Core status of notifications |
Indique sur combien d'instances Checkmk les notifications sont activées. Si elles sont désactivées sur une instance, par exemple via le snap-in master control, le nom de l'instance s'affiche. Cela vous permet de vérifier si cette désactivation était intentionnelle. |
2.2. Règles de notification
À droite des affichages d'état, vous trouverez des liens vers toutes les règles de notification existantes dans Checkmk :
À partir de là, vous pouvez accéder aux règles permettant d’optimiser vos notifications ainsi qu’à toutes les autres règles relatives aux notifications.
 |
Les règles affichées ici vous sont peut-être déjà familières depuis d’autres sections de Checkmk. Aucune nouvelle règle n’a été créée ici, seules les règles existantes ont été clairement récapitulées. |
2.3. Règle de notification globale et prédéfinie
La dernière partie de la page d'aperçu est constituée de la règle globale existante.
Si vous venez d'installer Checkmk, une seule règle aura été prédéfinie :
Une telle règle est structurée comme suit :
Condition |
Tous les changements d'état des ordinateurs hôtes vers DOWN et UP , et des services vers CRIT , WARN et OK. |
Méthode |
Envoie un courrier électronique au format HTML (avec des graphiques de métriques intégrés). |
Contact |
Tous les contacts de l'ordinateur hôte/service concerné. |
Comme d'habitude, vous pouvez modifier la règle 
, la cloner 
, la supprimer 
ou créer une nouvelle règle.
Dès que vous disposez de plusieurs règles, vous pouvez modifier leur ordre de traitement en les glissant-déposant à l'aide de l'icône 
.
|
Les modifications apportées aux règles de notification ne nécessitent pas d'activation, elles prennent effet immédiatement. |
3. Notifications simples par courrier électronique
Mais avant de vous lancer dans des notifications plus complexes, commencez par une forme très simple de notification : un simple courrier électronique.
Une notification par courrier électronique envoyée par Checkmk au format HTML ressemble à ceci :
Comme le montre l'exemple, le courrier électronique contient également les métriques actuelles du service concerné.
Avant de recevoir un tel courrier électronique de Checkmk, quelques préparatifs sont nécessaires, comme décrit ci-dessous.
3.1. Conditions préalables
Dans la configuration par défaut de Checkmk, un utilisateur recevra des notifications par courrier électronique lorsque les conditions préalables suivantes seront remplies :
Le serveur Checkmk dispose d'une configuration opérationnelle pour l'envoi de courriers électroniques.
Une adresse électronique est configurée pour l'utilisateur.
L'utilisateur est membre d'un groupe de contact et est donc un contact.
Un événement de supervision se produit sur un ordinateur hôte ou un service attribué à ce groupe de contact, ce qui déclenche une notification.
3.2. Configuration de l'envoi d'e-mails sous Linux
Pour que l'envoi de courriers électroniques fonctionne correctement, votre serveur Checkmk doit disposer d'une configuration de serveur SMTP opérationnelle. Selon votre distribution Linux, celle-ci peut utiliser, par exemple, Postfix, Qmail, Exim ou Nullmailer. La configuration sera mise en œuvre à l'aide des ressources de votre distribution Linux.
La configuration se limite généralement à l'enregistrement d'un « hôte intelligent » (également appelé serveur relais SMTP) vers lequel tous les courriers électroniques seront acheminés. Il s'agira alors du serveur de messagerie SMTP interne de votre entreprise. En règle générale, les hôtes intelligents ne nécessitent pas d'authentification au sein d'un réseau local (LAN), ce qui simplifie les choses. Dans certaines distributions, le smarthost vous sera demandé lors de l'installation. Avec l'appliance Checkmk, vous pouvez configurer le smarthost facilement via l'interface web.
Vous pouvez facilement tester l’envoi de courriers électroniques à l’aide de l’instruction mail en ligne de commande.
Comme il existe de nombreuses implémentations différentes de cette instruction sous Linux, Checkmk fournit, à des fins de standardisation, la version issue du projet Heirloom mailx directement dans le chemin d'accès de l’utilisateur de l’instance (sous ~/bin/mail).
Le fichier de configuration correspondant est ~/etc/mail.rc.
La meilleure façon de tester cela est de le faire en tant qu’utilisateur de l’instance, car les scripts de notification s’exécuteront ultérieurement avec les mêmes autorisations.
Le contenu du courrier électronique est lu à partir de l'entrée standard, l'objet est spécifié par -s, et l'adresse du destinataire est simplement ajoutée en tant qu'argument à la fin de la ligne de commande :
Le courrier électronique devrait être envoyé sans délai.
Si cela ne fonctionne pas, vous trouverez des informations dans le fichier journal du serveur SMTP situé dans le répertoire /var/log (voir Fichiers et répertoires).
3.3. Adresse électronique et groupes de contact
L'adresse électronique et les groupes de contact d'un utilisateur sont définis dans l'administration des utilisateurs :
Dans une instance Checkmk nouvellement créée, il n’existe initialement que le groupe de contact « Everything ». Les membres de ce groupe sont automatiquement responsables de tous les ordinateurs hôtes et services, et seront informés par courrier électronique de chaque événement de supervision pertinent.
3.4. Cas particuliers : système de tickets, messagerie instantanée et moteur d'événements
Au lieu d'un courrier électronique ou d'un SMS, vous pouvez également envoyer des notifications vers un système de tickets (tel que Jira ou ServiceNow), une messagerie instantanée (Slack, Mattermost) ou un moteur d'événements (Event Console).
Il existe une méthode de notification distincte pour chacun de ces cas particuliers, que vous pouvez sélectionner dans la règle de notification. Cependant, vous devez tenir compte des deux points suivants lors de la création de la règle :
Lors de la sélection des contacts, assurez-vous que les notifications ne sont envoyées qu’à un seul contact, par exemple en sélectionnant un seul utilisateur. Avec les méthodes de notification pour les systèmes de tickets, etc., la sélection des contacts sert uniquement à spécifier que des notifications sont envoyées. Cependant, les notifications ne sont pas envoyées à l'utilisateur sélectionné, mais au système de tickets. Notez qu'une sélection de contacts via des groupes de contacts, tous les contacts d'un objet ou similaire génère généralement plusieurs notifications identiques pour un événement, qui se retrouvent alors deux, trois fois, voire plus souvent dans le système de tickets.
Si la première condition est remplie, mais que l'utilisateur est utilisé dans plusieurs règles de notification pour la même méthode, seule la dernière règle s'applique dans chaque cas. Il est donc conseillé de créer un utilisateur fonctionnel distinct pour chacune de ces règles de notification.
3.5. Réglage fin des courriers électroniques HTML
Lors de l'envoi de courriers électroniques HTML, vous pouvez souhaiter ajouter des informations supplémentaires ou définir de manière flexible une adresse de réponse (Reply to) à un contact spécifique pour toute demande de renseignements. Pour cela, il existe la règle « Setup > Notifications > Parameters for notification methods > HTML Email » et, dans les règles de notification, la méthode de notification par courrier électronique HTML. Grâce à ces règles, vous pouvez ajouter un certain nombre de paramètres tels que l'adresse de réponse, des champs supplémentaires contenant des détails ou du texte libre formaté en HTML.
Veuillez noter que dans le champ Custom HTML section (e.g. title, description…), pour des raisons de sécurité, seul un petit ensemble de balises HTML est autorisé. Il s'agit des balises suivantes :
| Balise | Fonction | Conseils |
|---|---|---|
|
Autorisée lorsqu’elle est associée aux attributs « |
|
|
||
|
||
|
||
|
Obsolète. N'utilisez pas cette balise ! |
|
|
||
|
||
|
||
|
Obsolète. N'utilisez pas cette balise ! |
|
|
Les espaces et les indentations sont conservés. |
|
|
||
|
||
|
||
|
À utiliser uniquement dans les listes suivantes : |
|
|
||
|
Comme pour toutes les règles de Checkmk, une application très fine est possible, ce qui vous permet de personnaliser un ensemble détaillé de notifications pour les ordinateurs hôtes et les services selon vos besoins.
4. Gestion des notifications à l'aide de règles
Outre les simples notifications par courrier électronique, vous pouvez également configurer des systèmes de notification plus complexes avec Checkmk.
4.1. Création simplifiée de règles
Afin de faciliter la création de règles pour les notifications, l'interface de Checkmk diffère ici de ce à quoi vous êtes habitué dans d'autres domaines. Avec l'option «Setup > Events > Notifications > Add notification rule», vous pouvez commencer à créer des notifications :
Vous devez maintenant prendre une décision.
Si vous sélectionnez « Guided mode, », vous serez guidé, section par section, tout au long de la création d’une règle de notification. Chaque section traite spécifiquement d’un aspect de la notification. Remplissez la section correspondante avec les données pertinentes pour votre environnement. Vous trouverez les descriptions des différents thèmes plus loin dans cet article. Une fois que vous avez modifié une section, cliquez sur « Next step… ». Vos informations seront alors vérifiées, à condition qu’elles soient techniquement obligatoires. Si, par exemple, des données techniquement pertinentes telles que l’adresse électronique à utiliser sont manquantes, vous recevrez un message d’erreur. Une fois que vous aurez correctement saisi les données de base essentielles, vous serez redirigé vers la section suivante, puis finalement vers la fin, où vous aurez préparé une règle de notification complète. Terminez ensuite la création en cliquant soit sur « Apply & test notification rule », soit sur « Apply & create another rule ».
Vous pouvez également utiliser l’Overview mode. Cette option est particulièrement utile pour la modification ciblée de paramètres individuels dans une règle de notification existante — de même si vous maîtrisez déjà parfaitement la création de règles et ne souhaitez plus être guidé. Dans l’Overview mode, vous voyez toutes les sections d’édition en même temps et pouvez modifier directement tous les champs et toutes les options. La vérification technique est alors effectuée une seule fois et pour toutes les sections dès que vous cliquez sur Apply & test notification rule ou Apply & create another rule.
4.2. Structure des règles de notification
Nous présentons ci-après la structure générale des règles de notification, avec les définitions des conditions, des types d'événements, des filtres, des méthodes de notification, des contacts et des propriétés générales.
Conditions
Les conditions déterminent quand une règle sera utilisée. Elles constituent la base de chaque règle. Pour bien comprendre, il est important de garder à l'esprit que la source est toujours un événement de supervision sur un ordinateur hôte ou un service concret.
Les conditions portent sur
les attributs statiques de l’objet – par exemple, si le nom du service contient le texte «
/tmp» ou si un ordinateur hôte appartient à un groupe d'hôtes spécifique,l'état actuel ou le changement d'état, par exemple si le service vient de passer de OK à CRIT,
ou avec des éléments totalement différents, par exemple si la période de « temps de travail » est actuellement active.
Il y a deux points importants à prendre en compte lors de la définition des conditions :
Si aucune condition n’a été définie, la règle s’appliquera à chaque événement de supervision.
Dès que vous sélectionnez ne serait-ce qu’une seule condition, la règle ne s’applique que si toutes les conditions sont remplies. Toutes les conditions sélectionnées sont liées par un « ET ». Il n’existe qu’une seule exception à cette règle importante, dont nous parlerons plus tard et que nous ne prendrons pas en compte pour l’instant.
Cela signifie que vous devez vérifier très attentivement si les conditions que vous avez choisies peuvent être remplies simultanément afin qu’une notification soit déclenchée dans le cas souhaité.
Définition des types d'événements
Dans l'exemple suivant de structure d'une règle de notification, deux changements d'état doivent déclencher des notifications :
Les ordinateurs hôtes qui passent à l'état « DOWN » et
Les services qui passent à l'état «CRIT».
Ceci est défini à l'étape 1 :
L'exception à l'opération ET
En règle générale, dans Checkmk : La règle de notification ne s'applique que si un événement de supervision satisfait à toutes les conditions configurées. Il existe une exception importante à cette règle générale : pour les conditions « Host events » et « Service events ».
Si vous sélectionnez uniquement « Host events », la règle ne saisira aucun événement de service. Il en va de même pour la sélection des événements « Service events » et des événements d’ordinateur hôte. Si vous activez toutefois les deux conditions, la règle s’appliquera dès lors qu’un événement est défini dans l’une ou l’autre de ces deux conditions. Dans ce cas exceptionnel, ces conditions ne seront donc pas liées par un ET logique, mais par un OU. De cette manière, vous pouvez gérer facilement les notifications d’hôte et de service à l’aide d’une seule règle.
Configuration des filtres d'ordinateur hôte et de service
À l'étape 2, vous utilisez divers filtres pour déterminer les ordinateurs hôtes et les services auxquels la règle de notification doit s'appliquer.
Supposons que vous configuriez le filtre de manière à ce qu’une notification ne soit envoyée que si un événement de supervision concernant un service commençant par le nom NTP se produit sur un ordinateur hôte du dossier Main :
Le résultat de cette règle de notification avec les trois conditions individuelles (changements d’état, nom du service, dossier) serait que les notifications ne seraient envoyées que si un service passait à CRIT — et les changements d’état de l’ordinateur hôte seraient ignorés car aucun événement de supervision ne contiendrait à la fois le changement d’état d’un ordinateur hôte et le nom du service NTP.
Une autre astuce concernant l’option Contact group filters dans l’image ci-dessus : La condition vérifiée ici est de savoir si l’hôte/le service en question dispose d’une attribution de contact spécifique. Cela peut être utilisé pour mettre en œuvre des fonctions telles que « Les notifications d’hôte du groupe de contact Linux ne doivent jamais être envoyées par SMS ». Cela n’a rien à voir avec la sélection de contacts décrite ci-dessus.
Méthode de notification
La méthode de notification à l'étape 3 spécifie la technique à utiliser pour envoyer la notification, par exemple par courrier électronique HTML.
Chaque méthode est mise en œuvre à l’aide d’un script. Checkmk inclut un certain nombre de scripts prédéfinis. Vous pouvez également écrire très facilement vos propres scripts personnalisés dans le langage de programmation de votre choix afin de mettre en œuvre des notifications définies par l'utilisateur — par exemple, pour rediriger une notification vers votre propre système de tickets.
Certaines méthodes de notification peuvent inclure des paramètres.
Par exemple, les méthodes pour les courriers électroniques ASCII et HTML vous permettent de spécifier explicitement l’adresse électronique de l’expéditeur (From:).
La page appropriée pour définir les paramètres s’affiche après avoir sélectionné la méthode, dès que vous cliquez sur « Create ».
Toutefois, avant de définir des paramètres dans la règle de notification individuelle ici, sachez que vous pouvez également définir des paramètres pour les méthodes de notification de manière générale à deux autres endroits dans Checkmk :
Dans les paramètres des méthodes de notification, qui sont décrits plus loin dans cet article. Dans la règle de notification, sélectionnez la définition de paramètre souhaitée sous « Select parameters » avant de cliquer sur « Create » pour modifier la définition du paramètre sélectionné pour cette règle de notification.
Dans les règles pour les hôtes et les services : Sous « Setup > Services > Service monitoring rules », vous trouverez un jeu de règles pour chaque méthode de notification dans la section « Notifications », que vous pouvez utiliser pour définir les mêmes paramètres — et comme d’habitude, en fonction de l’hôte ou du service.
Ne modifiez les définitions des paramètres dans la règle de notification que si vous souhaitez vous écarter de ces paramètres pour des cas particuliers. Par exemple, vous pouvez définir un objet spécifique pour vos courriers électroniques de manière globale, mais définir un autre objet dans une règle de notification individuelle.
Au lieu de « Send notification », vous pouvez également sélectionner « Suppress all previous ». Les notifications issues de règles précédentes qui utilisaient cette méthode seront alors supprimées. Vous trouverez plus d’informations à ce sujet dans la section « Suppression des notifications par règles ».
|
Pour de nombreuses méthodes de notification permettant le transfert vers d’autres systèmes, vous trouverez des informations plus détaillées dans des articles distincts. La liste des articles se trouve dans le chapitre consacré aux scripts de notification. |
Sélection des contacts
La procédure la plus courante consiste à envoyer les notifications à tous les utilisateurs enregistrés en tant que contact pour l’ordinateur hôte/le service concerné. Il s’agit de la procédure « normale » et logique, car c’est également via les contacts que l’on définit les objets que chaque utilisateur reçoit dans son affichage d’interface graphique — en l’occurrence, les objets dont l’utilisateur est responsable.
Vous pouvez spécifier plusieurs options lors de la sélection des contacts avec l’Add recipient et ainsi étendre la notification à davantage de contacts. Checkmk supprimera automatiquement les contacts en double. Pour que la règle ait un sens, au moins une sélection doit être effectuée.
Les deux options d’Restrict previous options tos fonctionnent de manière quelque peu différente.
Ici, les contacts sélectionnés avec les autres options seront à nouveau restreints.
Avec celles-ci, vous pouvez également créer un opérateur ET entre des groupes de contacts, par exemple pour permettre l’envoi de notifications à tous les contacts qui sont membres à la fois des groupes Linux et Data center.
En saisissant Explicit email addresses, vous pouvez notifier des personnes qui ne sont en réalité pas désignées comme utilisateurs dans Checkmk. Cela n’a bien sûr de sens que si cette méthode de notification est utilisée dans le cadre d’une méthode de notification qui envoie effectivement des courriers électroniques.
Si, dans la méthode choisie, vous avez sélectionné Suppress all previous, les notifications ne seront supprimées que pour le contact sélectionné ici.
|
Lorsque vous utilisez un système de tickets, une messagerie instantanée ou un moteur d'événements comme méthode de notification, vous devez également tenir compte des remarques concernant ces cas particuliers. |
Conditions d'envoi des notifications
Vous pouvez pour l'instant ignorer l'étape « Sending conditions » pour les règles simples. Celles-ci présentent surtout un intérêt si vous souhaitez configurer des escalades.
Propriétés générales
Comme pour toutes les règles dans Checkmk, vous pouvez ici ajouter une description et un commentaire pour la règle, ou même la désactiver temporairement.
L'option d'Allow users to deactivate this notification vous permet d'autoriser les utilisateurs à se « désabonner » des notifications générées par cette règle de notification. Nous vous montrons comment procéder avec les notifications personnelles.
4.3. Définir les paramètres des méthodes de notification
Vous pouvez définir des paramètres distincts pour chaque méthode de notification. Ces paramètres sont définis et gérés séparément des règles de notification proprement dites dans Checkmk. Cela vous permet d’utiliser les paramètres pour plusieurs règles à la fois. Il vous suffit d’effectuer les modifications de manière centralisée à un seul endroit pour obtenir une présentation uniforme de toutes les notifications du même type, quelles que soient les règles qui les déclenchent.
Ouvrez l'aperçu de tous les paramètres personnalisables via Setup > Events > Notifications et le bouton « Parameters for notifications methods » :
À partir de là, vous pouvez créer, éditer et — s’ils ne sont utilisés dans aucune règle — supprimer les paramètres généraux pour chaque méthode.
4.4. Test des règles de notification
Pour tester les règles de notification, Checkmk propose un outil intelligent accessible via Test notifications. Vous pouvez l'utiliser pour simuler une notification pour un ordinateur hôte ou un service et identifier quelles règles de notification sont actives. En plus de la simulation, vous pouvez également faire envoyer la notification.
Le moyen le plus rapide d’accéder au test de notification est de passer par Setup > Events > Test notifications. Il existe par ailleurs d’autres options permettant d’y accéder depuis certaines vues de la section de supervision (liste des services et détails des services) et de la section de configuration (propriétés de l’ordinateur hôte), dans chaque cas via le menu «Host > Test notifications».
Cliquez d’abord sur l’un des deux boutons pour déterminer si la notification concerne une « Host » ou une « Service ». Sélectionnez ensuite l’ordinateur hôte ou le service concerné. Comme événement, vous pouvez choisir un changement d’état ou le début d’une période de maintenance planifiée. Vous pouvez ajouter une description de l’événement à « Plugin output ». Utilisez la case à cocher « Send out notification for specific method » pour indiquer si la notification est uniquement simulée ou réellement envoyée.
Enfin, sous « Advanced condition simulation », vous disposez de deux options supplémentaires qui vous permettent de définir l’heure et le nombre de notifications. Cela vous permet de tester des règles de notification qui ne s’appliquent que pendant une certaine période de temps (par exemple, en dehors des heures de bureau) ou qui déclenchent une escalade après un nombre spécifié de notifications répétées.
Cliquez sur « Test notifications » pour lancer le test — ainsi que l’envoi, si vous avez sélectionné cette option. Les résultats s’affichent sous la case « Test notifications » :
Le résumé s’affiche en premier.
Sous « Test results », vous pouvez voir combien de règles de notification s’appliquent et combien de notifications en résultent.
Si vous avez sélectionné « Send out notification », l’notifications have been sent out du message correspondant s’affiche ici.
Cela doit alors entraîner immédiatement l’envoi d’un courrier électronique concernant ce problème.
La ligne ci-dessous résume les notifications générées à partir de vos saisies.
En cliquant sur l'icône « 
», vous pouvez afficher le contexte de la notification.
Cela vous permet de voir les variables d'environnement et leurs valeurs qui sont valides dans le contexte de cette notification.
Les deux sections suivantes fournissent ensuite plus de détails :
Sous « Predicted notifications », vous pouvez voir à qui et comment les notifications seraient envoyées. Vous recevrez également ces informations concernant la simulation si vous n’avez pas choisi d’envoyer la notification.
Sous « Global notification rules », la liste des règles de notification que vous avez créées ici est présentée.
À ce stade, seule la première colonne du tableau est importante ; elle utilise des icônes pour indiquer quelles règles s’appliquent 
et lesquelles ne s’appliquent pas 
.
|
Comme d'habitude, vous pouvez continuer à déclencher des notifications directement via l'interface graphique (GUI) comme alternative au test des notifications par simulation, par exemple avec les instructions Send custom notification et Fake check results. |
4.5. Notifications répétées avec une périodicité et escalade
Pour certains systèmes, il peut être judicieux de ne pas se contenter d’une seule notification lorsqu’un problème persiste sur une longue période, par exemple pour les ordinateurs hôtes dont la balise de l’hôte Criticality est définie sur Business critical.
Configurer des notifications répétées périodiquement
Checkmk peut être configuré de manière à ce que des notifications successives soient émises à intervalles fixes, jusqu’à ce que le problème ait été reconnu ou résolu.
Le paramètre correspondant se trouve dans le jeu de règles « Periodic notifications during host problems » ou, respectivement, « Periodic notifications during service problems » :
Une fois cette option activée, pour un problème persistant, Checkmk déclenchera des notifications régulières aux intervalles configurés. Ces notifications recevront un numéro croissant commençant par 1 (pour la notification initiale).
Les notifications périodiques ne servent pas seulement à rappeler l’existence d’un problème (et à importuner l’opérateur), elles constituent également la base des escalades, ce qui signifie qu’après un délai défini, une notification peut être transmise à d’autres destinataires.
Configurer les escalades et les comprendre
Pour configurer une escalade, créez une règle de notification supplémentaire utilisant la condition « Restrict to notification number ».
Si vous entrez une plage comprise entre 3 et 99 999 pour le numéro séquentiel, cette règle prend effet à partir de la troisième notification. L'escalade peut alors être effectuée soit en sélectionnant une autre méthode (par exemple, un SMS), soit en informant d'autres personnes (sélection de contacts).
Avec l'option « Throttling of 'Periodic notifications' », après un certain temps, la fréquence de répétition des notifications peut être réduite de sorte que, par exemple, au début, un courrier électronique puisse être envoyé toutes les heures, puis que cela puisse être réduit à un courrier électronique par jour.
Grâce à plusieurs règles de notification, vous pouvez créer un modèle d'escalade. Mais comment cette escalade fonctionnera-t-elle concrètement ? Qui est notifié et quand ? Voici un exemple, mis en œuvre avec une règle pour les notifications répétées périodiquement ainsi que trois règles de notification : Par exemple :
En cas de détection d'un problème dans un service, une notification sous forme de courrier électronique sera déclenchée toutes les 60 minutes jusqu'à ce que le problème soit soit résolu, soit confirmé.
Les notifications 1 à 5 sont envoyées aux deux personnes responsables du service.
Les notifications six à dix sont également envoyées au chef d'équipe concerné.
À partir de la onzième notification, un e-mail quotidien est envoyé à la gestion de l'entreprise.
À 9 heures du matin, un problème survient sur le site. Les deux employés responsables sont informés du problème mais ne donnent pas de réponse (pour quelque raison que ce soit). Ils reçoivent donc chacun un nouveau courrier électronique à 10 h, 11 h, 12 h et 13 h. À partir de la sixième notification, à 14 h, le chef d’équipe reçoit également un courrier électronique — mais la situation reste inchangée. À 15 h, 16 h, 17 h et 18 h, d’autres courriers électroniques sont envoyés aux membres de l’équipe et au chef d’équipe.
À 19 h, le troisième niveau d’escalade entre en vigueur : Désormais, plus aucun courrier électronique n’est envoyé aux membres de l’équipe ni au chef d’équipe. À la place, la gestion de l’entreprise reçoit désormais un courrier électronique tous les jours à 19 h jusqu’à ce que le problème soit résolu.
Dès que le problème a été résolu et que le service dans Checkmk revient à l’état «OK», un message de «fin d’alerte» est automatiquement envoyé au dernier groupe de personnes notifié : Ainsi, dans l’exemple ci-dessus, si le problème est résolu avant 14 h, aux deux membres de l’équipe ; si le problème est résolu entre 14 h et 19 h, aux membres de l’équipe et au chef d’équipe ; et après 19 h, uniquement à la gestion de l’entreprise.
4.6. Suppression des notifications par règles
Comme déjà mentionné lors du choix de la méthode de notification, vous trouverez également l'option de sélection «Suppress all previous». Afin de bien comprendre le fonctionnement d'une telle règle, il est préférable de visualiser le tableau des notifications. Supposons que le traitement des règles pour un événement de supervision concret soit partiellement terminé et que, en raison d'un certain nombre de règles, les trois notifications suivantes aient été déclenchées :
| Qui (contact) | Comment (méthode) |
|---|---|
Harry Hirsch |
Courrier électronique |
Bruno Weizenkeim |
Courrier électronique |
Bruno Weizenkeim |
SMS |
Voici maintenant une nouvelle règle utilisant la méthode « SMS » et la sélection « Suppress all previous ». La sélection de contacts choisit le groupe de contact « Windows », dont Bruno Weizenkeim est membre. À la suite de cette règle, l'entrée « Bruno Weizenkeim / SMS » est supprimée du tableau, qui se présente alors comme suit :
| Qui (contact) | Comment (méthode) |
|---|---|
Harry Hirsch |
Courrier électronique |
Bruno Weizenkeim |
Courrier électronique |
Si une règle ultérieure définit à nouveau une notification par SMS pour Bruno, cette règle aura alors la priorité et le SMS sera ajouté à nouveau au tableau.
En résumé :
Les règles peuvent supprimer des notifications spécifiques.
Les règles de suppression doivent venir après les règles qui créent les notifications.
Une règle de suppression ne « supprime » pas réellement une règle précédente, mais supprime plutôt les notifications générées par les règles précédentes (qui peuvent être multiples).
Les règles suivantes peuvent rétablir les notifications précédemment supprimées.
4.7. Envoi synchrone pour les courriers électroniques HTML
Vous pouvez sélectionner et configurer la livraison traçable via SMTP pour la méthode de notification « courrier électronique HTML » en saisissant l’hôte intelligent (avec son nom et son numéro de port), ainsi que les données d’accès et la méthode de chiffrement :
Dans l’historique du service concerné, vous pouvez ensuite suivre la livraison avec précision. Voici un exemple dans lequel un service — à des fins de test — a été configuré manuellement sur CRIT. La capture d’écran ci-dessous montre les notifications pour ce service, que vous pouvez afficher sur la page de détails du service via Service > Service Notifications :
Vous verrez ici les quatre étapes individuelles dans l’ordre chronologique de bas en haut, telles que nous les avons déjà présentées dans le chapitre consacré à l’historique des notifications de l’article sur les principes de base des notifications.
La différence importante est que vous pouvez désormais voir dans l’entrée la plus haute de 
que le courrier électronique a été remis avec succès à l’hôte intelligent et que sa réponse est success.
Vous pouvez également suivre les différentes étapes dans le fichier ~/var/log/notify.log.
Les lignes suivantes correspondent à la dernière étape et contiennent la réponse du serveur SMTP :
2021-08-26 10:02:22,016 [20] [cmk.base.notify] Got spool file d3b417a5 (mysrv;CPU load) for local delivery via mail
2021-08-26 10:02:22,017 [20] [cmk.base.notify] executing /omd/sites/mysite/share/check_mk/notifications/mail
2021-08-26 10:02:29,538 [20] [cmk.base.notify] Output: success 250 - b'2.0.0 Ok: queued as 1BE667EE7D6'L'1BE667EE7D6 Message-ID apparaîtra dans le fichier journal de l'hôte intelligent.
C'est là — si cela vous préoccupe — que vous pouvez vérifier où le courrier électronique est arrivé.
Dans tous les cas, vous pouvez prouver que le courrier électronique a bien été envoyé depuis Checkmk, et à quel moment.
Répétons le test ci-dessus, mais cette fois-ci avec un mot de passe mal configuré pour le transfert SMTP vers l'hôte intelligent.
Vous pouvez voir ici en texte clair le message d'erreur SMTP Error: authentication failed provenant de l'hôte intelligent :
Que peut-on faire en cas d’échec des notifications ? Une fois encore, la notification par courrier électronique n’est apparemment pas une bonne solution. À la place, Checkmk affiche un avertissement clair sur fond rouge dans le snap-in « Aperçu » :
Vous pouvez ici :
Cliquer sur le texte « … failed notifications » pour obtenir la liste des envois ayant échoué.
Cliquer sur l'icône «
» pour confirmer ces messages et supprimer l'avertissement en cliquant sur « 
» Confirm dans l'aperçu qui s'ouvre.
Important : veuillez noter que la livraison directe par SMTP en cas d'erreur peut entraîner l'exécution prolongée d'un script de notification et provoquer un timeout. C'est pourquoi il est fortement recommandé d'utiliser le spouleur de notification et de sélectionner une livraison asynchrone des notifications.
Le comportement en cas d'erreurs récurrentes (telles qu'un timeout SMTP) peut être défini à l'aide de l'option « Global settings > Notifications > Notification spooler configuration » pour chaque méthode de notification :
Outre un timeout facultatif (la valeur par défaut est de 1 minute) et un nombre maximal de tentatives, il est également possible de définir si le script est autorisé à s’exécuter plusieurs fois en parallèle et donc à envoyer plusieurs notifications (Maximum concurrent executions). Si le script de notification est très lent, une exécution parallèle peut s’avérer judicieuse — toutefois, le script doit être programmé de manière à ce que les exécutions multiples se déroulent sans problème (et, par exemple, que le script ne réserve pas certaines données pour lui-même).
Une transmission multiple et parallèle via SMTP ne pose aucun problème, car le serveur cible est capable de gérer plusieurs connexions parallèles. Ce n’est certainement pas le cas lors d’une transmission directe par SMS via un modem sans spooler supplémentaire ; dans ce cas, il convient de s’en tenir au paramètre 1.
Important : la livraison traçable via SMTP n’est pas disponible pour les notifications groupées !
5. Notifications groupées
5.1. Aperçu
Toute personne travaillant dans le domaine de la supervision a déjà été confrontée à un problème isolé déclenchant un véritable déluge de notifications (successives). Le principe des hôtes parents permet de réduire ce phénomène dans certaines circonstances, mais il ne s’avère malheureusement pas efficace dans tous les cas.
Vous pouvez vous inspirer du projet Checkmk lui-même : Une fois par jour, nous construisons des paquets d’installation Checkmk pour chaque distribution Linux prise en charge. Notre propre supervision Checkmk est configurée de telle sorte que nous disposons d’un service qui n’est alors en état « OK » que si le nombre requis de paquets a été correctement construit. Il peut arriver occasionnellement qu’une erreur générale dans le logiciel entrave la création des paquets, provoquant la mise en état « CRIT » simultanée de 43 services.
Nous avons configuré les notifications de telle sorte que, dans un tel cas, un seul courrier électronique répertorant les 43 notifications dans l'ordre soit envoyé. Cela est naturellement plus clair que 43 courriers électroniques individuels, et cela réduit également le risque que, « dans le feu de l'action », l'on passe à côté d'un 44e courrier électronique concernant un tout autre problème.
Le fonctionnement de cette notification groupée est très simple. Lorsqu’une notification survient, elle est d’abord mise en attente pendant un court instant. Les notifications suivantes qui surviennent pendant ce laps de temps sont immédiatement ajoutées au même courrier électronique. Ce regroupement peut être défini pour chaque règle. Ainsi, par exemple, vous pouvez fonctionner avec des courriers électroniques individuels pendant la journée, mais avec une notification groupée pendant la nuit. Si une notification groupée est activée, les options suivantes vous sont généralement proposées :
Le délai d'attente peut être configuré selon vos besoins. Dans de nombreux cas, une minute suffit, car tous les problèmes concernés devraient alors être apparus au plus tard. Vous pouvez bien sûr définir un délai plus long, mais cela entraînera un retard important dans les notifications.
Comme il n’est évidemment pas judicieux de tout mettre dans le même panier, vous pouvez préciser quels groupes de problèmes doivent faire l’objet d’une notification collective. L’option « Host » est très couramment utilisée — elle garantit que seules les notifications provenant du même ordinateur hôte sont regroupées.
Voici quelques informations supplémentaires concernant les notifications groupées :
Si le regroupement est activé dans une règle, il peut être désactivé par une règle suivante — et inversement.
La notification groupée s'effectue toujours par contact. Chaque contact dispose en effet de son propre « pot de collection privé ».
Vous pouvez limiter la taille de ce « pot » (Max. notifications per bulk). Une fois le maximum atteint, la notification groupée sera immédiatement envoyée.
5.2. Notifications groupées et périodes de temps
Que se passe-t-il lorsqu’une notification se trouve dans la période de notification, mais que la notification groupée qui contient cette notification — et qui arrive un peu plus tard — se trouve en dehors de la période de notification ? La situation inverse est également possible…
Ici, un principe très simple s’applique : toutes les configurations qui limitent les notifications à des périodes de temps ne s’appliquent qu’à la notification en question. La notification groupée suivante sera toujours envoyée indépendamment de toute période de temps.
6. Que se passe-t-il si aucune règle n'est applicable ?
Même les personnes chargées de la configuration peuvent commettre des erreurs. Une erreur possible dans la configuration des notifications pourrait être qu’un problème critique de supervision soit détecté, mais qu’aucune règle de notification ne s’applique.
Pour vous protéger contre un tel cas, Checkmk propose le paramètre « Fallback email address for notifications ». Vous le trouverez sous « Setup > General > Global settings » dans la section « Notifications ». Saisissez ici une adresse électronique. Cette adresse électronique recevra alors les notifications pour lesquelles aucune règle de notification ne s'applique.
|
Vous pouvez également désigner un utilisateur comme destinataire dans ses paramètres personnels. L'adresse électronique enregistrée pour cet utilisateur est alors utilisée comme adresse de secours. |
L'adresse de secours ne sera toutefois utilisée que si aucune règle ne s'applique, et non lorsqu'aucune notification n'a été déclenchée ! Comme nous l'avons montré dans la section consacrée à la suppression des notifications, la suppression explicite des notifications est souhaitée — il ne s'agit pas d'une erreur de configuration.
La saisie d’une adresse de secours sera « recommandée » sur la page Notifications avec un avertissement à l’écran :
Si, pour quelque raison que ce soit, vous souhaitez simplement faire disparaître l’avertissement, mais que vous ne souhaitez pas pour autant recevoir de courriers électroniques à l’adresse de secours, saisissez tout d’abord une adresse de secours, puis créez une nouvelle règle en tant que première règle, qui supprimera toutes les notifications précédentes. Cette règle n’a aucun effet sur la configuration des notifications, car aucune notification n’a encore été créée ici. Mais cela vous permet de vous assurer qu’au moins une règle s’appliquera toujours, ce qui permet d’éliminer cet avertissement.
Nous vous déconseillons formellement cette approche, car vous risquez de négliger des lacunes dans votre chaîne de règles.
|
Si vous souhaitez uniquement désactiver les notifications pour vous-même, vous pouvez le faire via les règles de notification personnelles. |