 |
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
Une fonctionnalité utile du système de notification de Checkmk permet aux utilisateurs — même ceux qui ne disposent pas de droits d’administrateur — de personnaliser les notifications. Les utilisateurs peuvent :
Ajouter des notifications qu’ils ne recevraient pas autrement (« s’abonner »)
Supprimer les notifications qu’ils recevraient autrement (si cela n’est pas restreint)
Personnaliser les paramètres de notification
Désactiver complètement leurs notifications
2. Gestion des notifications à l'aide de règles personnalisées
Du point de vue de l’utilisateur, le point d’accès est le menu Utilisateur, puis l’Notification rules. Sur la page Your personal notification rules, une nouvelle règle peut être créée via Add rule.
Le contenu des règles de notification personnelles est similaire à celui des règles de notification globales, à une différence près : elles ne comportent pas de sélection de contact. L’utilisateur lui-même est automatiquement sélectionné comme contact. Cela signifie qu’un utilisateur ne peut ajouter ou supprimer que ses propres notifications personnelles.
Toutefois, l’utilisateur ne peut supprimer des notifications que si l’option « Allow users to deactivate this notification » est activée dans la règle (globale) qui les crée :
Dans l’ordre des règles de notification, les règles personnelles viennent toujours après les règles globales et peuvent donc modifier le tableau de notification généré jusqu’à présent. Ainsi, à l’exception du blocage de suppression que nous venons de décrire, les règles globales s’appliquent toujours comme paramètre par défaut pouvant être personnalisé par l’utilisateur.
 |
Les modifications apportées aux règles de notification ne nécessitent pas d’activation, elles prennent effet immédiatement. |
2.1. Structure des règles de notification
Nous présentons ci-après la structure générale des règles de notification personnelles, avec les définitions des propriétés générales, de la méthode de notification et des conditions.
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.
Méthode de notification
La méthode de notification 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. Vous pouvez également écrire très facilement vos propres scripts dans le langage de programmation de votre choix afin de mettre en place des notifications définies par l'utilisateur — par exemple, pour rediriger une notification vers votre propre système de tickets.
Une méthode peut inclure des paramètres — par exemple, permettre à la méthode qui envoie des courriers électroniques ASCII et HTML de définir explicitement l'adresse électronique de l'expéditeur (From:).
Avant de définir des paramètres directement dans la règle de notification, il convient de savoir que les paramètres des méthodes de notification peuvent également être spécifiés via des règles pour les ordinateurs hôtes et les services : Sous Setup > Services > Service monitoring rules, dans la section Notifications, vous trouverez un jeu de règles pour chaque méthode de notification, que vous pouvez utiliser pour définir les mêmes paramètres — et qui, comme d’habitude, peuvent dépendre de l’hôte ou du service.
Les définitions de paramètres dans les règles de notification permettent de modifier ces paramètres au cas par cas. Vous pouvez ainsi, par exemple, définir un objet global pour votre courrier électronique, mais également définir un objet alternatif à l’aide d’une règle de notification individuelle.
Au lieu de paramètres, vous pouvez également sélectionner l’option «Cancel previous notifications» — grâce à laquelle toutes les notifications de cette méthode issues de règles antérieures seront supprimées. Pour en savoir plus à ce sujet, consultez le thème « Suppression des notifications ».
|
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. 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 relatives à ces cas particuliers. |
Conditions
Les conditions déterminent quand une règle sera appliquée. 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
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é.
Supposons que vous souhaitiez qu’une notification soit déclenchée lorsqu’un événement de supervision se produit pour un service dont le nom commence par « NTP » sur un ordinateur hôte du dossier « Main » :
Supposons en outre que cette condition soit désormais étendue pour notifier également tous les changements d'état d'un ordinateur hôte vers l'état « DOWN » :
Le résultat de cette règle de notification comportant ces trois conditions distinctes est qu’aucune notification ne sera jamais envoyée, car aucun événement de supervision ne contiendra à la fois le changement d’état d’un ordinateur hôte et le nom du service commençant par NTP.
La remarque suivante est répétée à plusieurs reprises dans ce guide de l'utilisateur. Toutefois, en ce qui concerne la configuration de vos notifications, il convient de la souligner à nouveau : Affichez l'aide en ligne avec l'option « Help > Show inline help » pour obtenir des détails sur l'effet des différentes conditions. L'extrait suivant de l'aide en ligne pour l'option « Match services » illustre très bien ce comportement : « Remarque : les notifications d'ordinateur hôte ne saisistront jamais cette règle si cette option est utilisée. »
L'exception à l'opération ET
La règle de notification ne s'appliquera que si un événement de supervision satisfait à toutes les conditions configurées. Comme mentionné ci-dessus, il existe une exception importante à cette règle générale : pour les conditions Match host event type et Match service event type :
Si vous sélectionnez uniquement « Match host event type », la règle ne saisira aucun événement de service. De même, cela s'applique à la sélection des événements « Match service event type » et « host ». Si vous activez toutefois les deux conditions, la règle s'appliquera si le type d'événement est activé dans l'une ou l'autre des deux listes de cases à cocher. Dans ce cas exceptionnel, ces conditions ne seront donc pas liées par un ET logique, mais plutôt par un OU. De cette manière, vous pouvez facilement gérer les notifications d'hôte et de service à l'aide d'une seule règle.
Une autre astuce concernant les conditions « Match contacts » et « Match contact groups » :
La condition vérifiée ici est de savoir si l'ordinateur 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'ordinateur 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.
2.2. Suppression des notifications par règles
Comme déjà mentionné lors de la sélection de la méthode de notification, vous trouverez également l’option « Cancel previous notifications ». Afin de bien comprendre le fonctionnement d’une telle règle, il est préférable de visualiser le tableau des notifications.
Supposons que certaines règles relatives à un événement de supervision spécifique aient déjà été traitées. Cela a généré deux notifications pour notre utilisateur, l’une par courrier électronique et l’autre par SMS.
Vient ensuite la règle suivante avec la méthode « SMS » et la sélection « Cancel previous notifications ». À la suite de cette règle, la notification par SMS destinée à notre utilisateur sera supprimée, et seul un courrier électronique sera généré.
Si une règle suivante 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 (effacer) 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 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.
2.3. 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 :
Pour plus d’informations sur la manière de suivre les envois réussis ou échoués dans l’interface utilisateur de Checkmk et dans les fichiers journaux, veuillez vous reporter à l’article sur les règles de notification globales.
Important : les notifications traçables ne sont pas disponibles pour les notifications groupées !
3. Notification groupée
3.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 spécifiques, mais malheureusement, il ne s’avère pas efficace dans tous les cas.
Vous pouvez prendre un exemple tiré du projet Checkmk lui-même : Une fois par jour, nous créons 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 généré. 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 » (Maximum bulk size). Une fois le maximum atteint, la notification groupée sera immédiatement envoyée.
3.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 elle-même. La notification groupée suivante sera toujours envoyée indépendamment de toute période de temps.
4. Paramètres administrateur
4.1. Désactivation temporaire des notifications
La désactivation complète des notifications par un utilisateur est protégée par l'autorisation General Permissions > Disable all personal notifications, qui est définie par défaut sur no pour le rôle d'utilisateur user.
Un utilisateur ne verra les cases à cocher correspondantes dans ses paramètres personnels que si vous attribuez explicitement ce droit au rôle user :
En tant qu’administrateur ayant accès aux paramètres personnels de l’utilisateur, vous pouvez effectuer des actions de désactivation au nom de l’utilisateur, même si l’autorisation décrite ci-dessus n’est pas présente. Vous trouverez ce paramètre sous Setup > Users > Users, puis dans les propriétés du profil utilisateur.
Cela vous permet, par exemple, de désactiver très rapidement les notifications d’un collègue en vacances — sans avoir à modifier la configuration proprement dite.
4.2. Empêcher les personnalisations définies par l’utilisateur
Si vous souhaitez empêcher toute personnalisation, vous pouvez révoquer l'autorisation « General Permissions > Edit personal notification settings » du rôle « user ».
En tant qu’administrateur, vous pouvez afficher toutes les règles utilisateur en sélectionnant « Setup > Events > Notifications », puis l’entrée de menu « Display > Show user rules » :
Après les règles globales, la liste des règles personnelles est affichée ; vous pouvez également effectuer l'édition à l'aide de l'option « 
».