Console d’évènements

Comme toujours dans Checkmk, vous devez d'abord activer les modifications pour qu'elles prennent effet. Ce n'est pas un inconvénient, car de cette manière, pour les modifications qui affectent plusieurs règles liées, vous pouvez spécifier exactement quand les règles doivent entrer en vigueur. Et au préalable, vous pouvez utiliser l'Event Simulatore pour vérifier si tout fonctionne comme prévu.

Commencez par cliquer sur le nombre de modifications accumulées en haut à droite de la page.

Cliquez ensuite sur « Activate on selected sites » pour activer la modification. La Event Console est conçue de manière à ce que cette action s'exécute sans interruption. La réception des messages entrants est assurée à tout moment, de sorte qu'aucun message ne puisse être perdu au cours du processus.

Seuls les administrateurs sont autorisés à activer les modifications dans la console d'événements. Ceci est contrôlé via l'autorisation « Activate changes for event console ».

Pour effectuer un test, vous pouvez bien sûr envoyer des messages via syslog ou SNMP. Vous devriez également le faire ultérieurement. Mais pour un premier test, la fonction de test intégrée à la console d'événements est plus pratique :

Vous disposez ici de deux options : l’ Try outévalue, sur la base du message simulé, laquelle des règles saisirait le message. Si vous vous trouvez au niveau supérieur de l’interface graphique de la Configuration de l’EC, les ensembles de règles seront mis en évidence. Si vous vous trouvez à l’intérieur d’un ensemble de règles, les règles individuelles sont mises en évidence. Chaque ensemble ou règle est marqué par l’un des trois symboles suivants :

Cliquer sur «Generate event» (Générer l'événement) a presque le même effet que «Try out» (Simuler l'événement), sauf que le message est cette fois-ci réellement généré. Toutes les actions définies sont effectivement exécutées. L'événement apparaîtra alors également dans la liste des événements ouverts de la supervision. Vous pouvez voir le code source du message généré dans la confirmation :

L'événement généré apparaît dans le menu « Monitor » sous « Event Console > Events » :

Pour un premier test concret sur le réseau, vous pouvez facilement envoyer manuellement un message syslog depuis un autre ordinateur Linux. Le protocole étant très simple, vous n’avez même pas besoin d’un programme spécial ; il vous suffit d’envoyer les données via netcat ou nc en utilisant le protocole UDP. Le contenu du paquet UDP se compose d’une seule ligne de texte. Si celle-ci respecte une structure spécifique, l’Event Console décompose clairement les composants :

Mais vous pouvez également envoyer n'importe quoi. La console d'événements l'acceptera quand même et l'évaluera simplement comme un texte de message. Les informations supplémentaires telles que l'application, la priorité, etc. seront bien sûr manquantes. Pour des raisons de sécurité, l'CRITt de statut sera supposée :

Au sein de l'instance Checkmk exécutant l'EC, il existe un canal nommé dans lequel vous pouvez écrire localement des messages texte via echo. Il s'agit d'une méthode très simple pour établir une connexion avec une application locale et également d'un moyen de tester le traitement des messages :

À ce propos, il est également possible d'envoyer des messages au format syslog ici, afin que tous les champs des données liées à l'événement soient correctement renseignés.

L’instruction « Update & Acknowledge » affiche la zone suivante au-dessus de la liste des événements :

Le bouton « Update » vous permet, en une seule action, d’ajouter un commentaire à l’événement, d’ajouter une personne de contact et de réaliser une confirmation de l’événement. Le champ « Change contact » est volontairement un champ de texte libre. Vous pouvez également y saisir des informations telles que des numéros de téléphone. Ce champ n’a notamment aucune incidence sur la visibilité de l’événement dans l’interface graphique — il s’agit purement d’un champ de commentaire.

La case à cocher « Set event to acknowledged » (Valider l'événement) fera passer l'événement de la phase « open » (En attente de confirmation) à « acknowledged » (Validé), et il s'affichera désormais comme « handled » (Événement validé). Ce processus est analogue à la confirmation des problèmes liés à l'ordinateur hôte et au service.

Une exécution ultérieure de l’instruction avec la case à cocher décochée supprime cette confirmation.

L’instruction « Change State » permet de modifier manuellement l’état d’un événement, par exemple de « CRIT » à « WARN ».

L’instruction « Custom Action » permet d’exécuter des actions librement définissables sur des événements. Au départ, seule l’action « Send monitoring notification » est disponible. Cela enverra une notification Checkmk qui sera handleée de la même manière que celle provenant d’un service activement supervisé. Cette notification passe par les règles de notification et peut générer des courriers électroniques, un SMS ou tout autre élément que vous avez configuré en conséquence. Voir ci-dessous pour plus de détails sur la notification par l’EC.

Le bouton « Archive Event » supprime définitivement un événement de la liste des événements ouverts. Étant donné que toutes les actions sur les événements — y compris cette suppression — sont également enregistrées dans les archives, vous pourrez toujours accéder ultérieurement à toutes les informations relatives à l’événement. C’est pourquoi nous ne parlons pas de suppression, mais plutôt d’archivage.

Vous pouvez également archiver facilement des événements individuels à partir de la liste des événements à l’aide de la fonction « ».

Afin d’assurer la visibilité des ordinateurs hôtes et des services dans la supervision pour les utilisateurs normaux, Checkmk utilise des groupes de contact. Ces groupes sont attribués aux ordinateurs hôtes et aux services via l’interface graphique de configuration, la configuration des règles ou celle des dossiers.

Avec la Event Console, il n'existe pas d'affectation de ce type des événements à des groupes de contact. En effet, on ne sait tout simplement pas à l'avance quels messages seront effectivement reçus. Même la liste des ordinateurs hôtes n'est pas connue, car les sockets pour syslog et SNMP sont accessibles de partout. C'est pourquoi la Event Console inclut quelques fonctionnalités spéciales pour définir la visibilité.

Tout d’abord, lors de la configuration des rôles utilisateur, il existe l’autorisation «Event Console > See all events». Celle-ci est active par défaut, de sorte que les utilisateurs normaux sont autorisés à voir tous les événements ! Ce paramètre est délibérément défini pour garantir que les messages d’erreur importants ne passent pas inaperçus en raison d’une configuration incorrecte. La première étape vers une visibilité plus précise consiste à supprimer cette autorisation du rôle «user».

Afin de garantir que la visibilité des événements soit aussi cohérente que possible avec le reste de la supervision, la Event Console s'efforce autant que possible de saisir les hôtes d'où elle reçoit des événements à ceux configurés via l'interface graphique de configuration. Ce qui semble simple s'avère délicat dans les détails. Il arrive parfois qu'un nom de domaine soit absent de l'événement et que seule l'adresse IP soit connue. Dans d'autres cas, le nom de domaine est orthographié différemment de ce qui figure dans l'interface graphique de configuration.

L'affectation s'effectue comme suit :

Vous pouvez influencer l'affectation à un moment donné : En effet, si des groupes de contacts sont définis dans la règle et que l'hôte peut être affecté, l'affectation a généralement la priorité. Vous pouvez modifier cela dans une règle à l'aide de l'option «Precedence of contact groups» :

De plus, vous pouvez définir des paramètres directement dans la règle pour la notification. Cela permet de donner la priorité au type d’événement par rapport aux responsabilités habituelles d’un ordinateur hôte.

Tant pour les ensembles de règles …​

… que pour les règles individuelles …​

… dans la colonne «Hits», vous trouverez des informations sur la fréquence à laquelle le pack ou la règle a déjà saisi un message. Cela vous aide à éliminer ou à corriger les règles inefficaces. Mais cela peut également s’avérer intéressant pour les règles qui saisissent très souvent. Pour une performance optimale de l’EC, celles-ci devraient se trouver au début de la chaîne de règles. De cette manière, vous pouvez réduire le nombre de règles que l’EC doit tester sur chaque message.

Vous pouvez réinitialiser les compteurs à tout moment via l'entrée « Event Console > Reset counters » du menu.

Dans la section « Essayer une règle », vous avez déjà vu comment utiliser l’Event Simulator pour vérifier les évaluations de vos règles. Vous pouvez obtenir des informations similaires lors de l’exécution pour tous les messages, si, dans les paramètres de l’Event Console, vous définissez la valeur de « Debug rule execution » à « on ».

Le fichier journal de l'Event Console se trouve à l'adresse var/log/mkeventd.log. Vous y trouverez la raison exacte pour laquelle une règle vérifiée n'a pas pris effet :

Il va sans dire que vous ne devez utiliser cette journalisation intensive qu'en cas de besoin et avec prudence. Dans un environnement à peine plus complexe, d'énormes volumes de données seront générés !

Pour toutes les conditions impliquant des champs de texte, le texte de comparaison est toujours traité comme une expression régulière. La comparaison s’effectue toujours sans tenir compte de la casse. Ce dernier point constitue une exception aux conventions de Checkmk dans les autres modules. Cependant, cela rend la formulation des règles plus robuste, d’autant plus que l’orthographe des noms de domaine dans les événements n’est pas nécessairement cohérente s’ils ont été configurés localement sur chaque ordinateur hôte plutôt que de manière centralisée. Cette exception est donc très utile ici.

De plus, une correspondance d'infixe s'applique toujours, c'est-à-dire une vérification du contenu du texte de recherche. Vous pouvez donc omettre l'.*e au début ou à la fin du texte de recherche.

Il existe toutefois une exception : Si aucune expression régulière n’est utilisée dans la correspondance avec le nom de domaine, mais plutôt un nom de domaine explicite, la vérification portera sur une correspondance exacte et non sur la présence du nom de domaine dans le texte.

Attention : si le texte recherché contient un point (.), il sera considéré comme une expression régulière et la recherche infixe s'appliquera ; par exemple, myhost.com correspondra alors également à notmyhostide !

Le concept de groupes de correspondance dans le champ Text to match est ici très important et utile. Il s'agit des sections de texte qui correspondent aux expressions entre parenthèses dans l'expression régulière.

Supposons que vous souhaitiez effectuer la supervision du type de message suivant dans le fichier journal d'une base de données :

L'WP41 est bien sûr variable et vous ne souhaitez certainement pas formuler une règle distincte pour chaque occurrence différente. Vous utilisez donc .* dans l'expression régulière, qui représente n'importe quelle chaîne de caractères :

Database instance .* has failed

Si vous placez maintenant la partie variable entre parenthèses, l'Event Console mémorisera (capturera) la valeur réelle pour toute action future :

Database instance (.*) has failed

Une fois la règle appliquée avec succès, le premier groupe de correspondance est désormais défini sur la valeur « WP41 » (ou sur l'instance qui a généré l'erreur).

Vous pouvez voir ces groupes de correspondance dans l'Event Simulatore si vous passez le curseur sur la boule verte :

Vous pouvez également voir les groupes dans les détails de l'événement généré :

Les groupes de correspondance sont notamment utilisés pour :

À ce stade, voici une astuce : Il existe des situations où vous devez regrouper un élément dans l'expression régulière, mais où vous ne souhaitez pas créer de groupe de correspondance. Vous pouvez le faire en plaçant un « ?: » directement après la parenthèse ouvrante. Exemple : l'expression « one (.*) two (?:.*) three » crée, pour une correspondance sur « one 123 two 456 three », un seul groupe de correspondance « 123 ».

Dans le champ « Match original source IP address », vous pouvez saisir l'adresse IPv4 de l'expéditeur du message. Spécifiez soit une adresse exacte, soit un réseau sous la forme X.X.X.X/Y, par exemple 192.168.8.0/24 pour saisir toutes les adresses du réseau 192.168.8. X.

Notez que la correspondance avec l'adresse IP ne fonctionne que si les systèmes surveillés envoient directement leurs messages à la Event Console. Si un autre serveur syslog intermédiaire connecté transfère les messages, c'est son adresse qui apparaîtra à la place en tant qu'expéditeur dans le message.

Les champs « Match syslog priority » et « Match syslog facility » sont des informations standardisées, définies à l’origine par les spécifications syslog. En interne, un champ de 8 bits est divisé en 5 bits pour la facilité (32 possibilités) et 3 bits pour la priorité (8 possibilités).

Les 32 facilités prédéfinies étaient autrefois destinées à des éléments tels qu’une application. Mais le choix n’avait pas été fait de manière très visionnaire à l’époque. L’une de ces facilités est uucp — un protocole qui, au début des années 90 du siècle dernier, était déjà presque obsolète.

Mais il est un fait que chaque message transitant par syslog comporte l’une de ces facilités. Dans certains cas, vous pouvez également les attribuer librement lors de l’envoi du message, afin de pouvoir les filtrer ultérieurement. Ceci est très utile.

L'utilisation de la facilité et de la priorité comporte également un aspect lié aux performances. Si vous définissez une règle qui s'applique uniquement aux messages ayant tous la même facilité ou la même priorité, vous devriez également définir ces critères dans les filtres de la règle. L'Event Console peut alors contourner ces règles très efficacement lorsqu'un message présentant des valeurs différentes est reçu. Plus le nombre de règles comportant ces filtres est élevé, moins il est nécessaire de comparer les règles.

La case à cocher « Negate match: Execute this rule if the upper conditions are not fulfilled. » (Inverser la règle) fait en sorte que la règle ne s'applique que lorsque aucune des conditions n'est remplie. Cela n'est en réalité utile que dans le contexte de deux types de règles (option « Rule type » dans la case « Outcome & Action » de la règle) :

Vous trouverez ci-dessous plus d'informations sur les ensembles de règles.

Lorsqu’une règle correspond, elle spécifie ce qu’il faut faire avec le message. Cela se fait dans la case « Outcome & Action » :

L'Rule type peut être utilisé pour interrompre complètement l'évaluation à ce stade ou pour le paquet de règles actuel. La première option, en particulier, doit être utilisée pour éliminer la plupart des « bruits » inutiles à l'aide de quelques règles spécifiques dès le début. Ce n'est qu'avec les règles « normales » que les autres options de cette case sont réellement évaluées.

Avec l’option « State », la règle définit le statut de l’événement dans la supervision. Dans la règle, cet état sera « WARN » ou « CRIT ». Les règles qui génèrent des événements « OK » peuvent être intéressantes dans les exceptions pour représenter certains événements de manière purement informative. Dans un tel cas, une combinaison avec une expiration automatique de ces événements est alors intéressante.

Outre la définition d’un statut explicite, il existe deux options plus dynamiques. Le paramètre « (set by syslog) » reprend la classification basée sur la priorité syslog. Cela ne fonctionne que si le message a déjà été classé de manière exploitable par l’expéditeur. Les messages reçus directement par syslog contiendront l’une des huit priorités RFC, qui sont affectées comme suit :

Outre les messages syslog, les messages provenant du journal des événements Windows et ceux issus de fichiers texte déjà classés à l'aide du plugin Checkmk logwatch sur le système cible fournissent des états prêts à l'emploi. Pour les traps SNMP, cette fonctionnalité n'est malheureusement pas disponible.

Une méthode totalement différente consiste à classer le message en fonction du texte lui-même. Cela peut être effectué à l'aide du paramètre « (set by message text) » :

La correspondance avec les textes configurés ici n'a lieu qu'après la vérification de l'Text to match et une fois que les autres conditions de la règle ont été vérifiées, de sorte que vous n'avez pas à répéter ces vérifications.

Si aucun des modèles configurés n'est trouvé, l'événement renvoie l'état UNKNOWN.

L'idée derrière le champ « Service Level » est que chaque ordinateur hôte et chaque service au sein d'une organisation possède un certain niveau d'importance. Cela peut être associé à un contrat de service spécifique pour l'ordinateur hôte ou le service. Dans Checkmk, vous pouvez utiliser des règles pour attribuer de tels niveaux de service à vos ordinateurs hôtes et services, puis, par exemple, faire en sorte que les notifications ou les tableaux de bord personnalisés en dépendent.

Étant donné que les événements ne sont pas nécessairement liés à des ordinateurs hôtes ou à des services, l'Event Console vous permet d'attribuer un niveau de service à un événement à l'aide d'une règle. Vous pouvez ensuite filtrer les vues d'événements en fonction de ce niveau.

Par défaut, Checkmk définit quatre niveaux : 0 (aucun niveau), 10 (argent), 20 (or) et 30 (platine). Vous pouvez modifier cette sélection selon vos besoins dans l’Global settings > Notifications > Service Levels. Les chiffres désignant les niveaux sont déterminants, car les niveaux sont triés par ces chiffres et également comparés en fonction de leur importance relative.

Les groupes de contacts utilisés pour la visibilité seront également utilisés pour la notification des événements. Vous pouvez ici utiliser des règles pour attribuer explicitement des groupes de contacts à des événements. Vous trouverez plus de détails dans le chapitre consacré à la supervision.

Les actions sont très similaires aux gestionnaires d'alertes pour les ordinateurs hôtes et les services. Vous pouvez ici faire exécuter un script personnalisé lorsqu'un événement est ouvert. Vous trouverez ci-dessous, dans une section distincte, des informations détaillées sur les actions.

La suppression automatique (= archivage), que vous pouvez configurer via Delete event immediately after the actions, garantit qu’un événement ne soit plus visible du tout dans la supervision. Cela est utile si vous souhaitez uniquement déclencher certaines actions automatiquement ou si vous souhaitez uniquement archiver certains événements afin de pouvoir les rechercher ultérieurement.

Vous pouvez également faire en sorte que des actions soient exécutées automatiquement lorsqu’un événement est annulé. Il est important de savoir que lorsqu’un événement est annulé, un certain nombre de champs de données de l’événement sont écrasés par les valeurs du message OK avant que toute action ne soit exécutée. De cette manière, l'intégralité des données du message OK est alors disponible dans le script d'action. De plus, au cours de cette phase, l'état de l'événement est marqué comme « OK ». Ainsi, un script d'action peut détecter une écrasement et vous pouvez utiliser le même script pour les messages d'erreur et les messages OK (par exemple, lors de la connexion à un système de tickets).

Les champs suivants sont remplacés par les données du message OK :

Tous les autres champs restent inchangés, y compris l'ID de l'événement.

Si vous utilisez la réécriture et l'annulation dans la même règle, vous devez faire preuve de prudence lors de la réécriture du nom de domaine ou de l'application. Lors de l'annulation, la console d'événements checke toujours si le message d'annulation correspond au nom de domaine et à l'application de l'événement ouvert. Mais si ceux-ci ont été réécrits, l'annulation ne fonctionnerait jamais.

C'est pourquoi, avant d'annuler l'événement, la Event Console simule une réécriture du nom de domaine et de l'application afin de comparer les textes concernés. C'est probablement ce à quoi vous vous attendiez.

Vous pouvez également tirer parti de ce comportement si le champ « application » du message d'erreur et du message « OK » ultérieur ne saisissent pas la même valeur. Dans ce cas, il suffit de réécrire le champ « application » en lui attribuant une valeur fixe connue. Cela a en effet pour conséquence que ce champ sera ignoré.

Il existe (malheureusement) des situations où le texte des messages d'erreur et OK est absolument identique. Dans la plupart des cas, l'état réel n'est pas codé dans le texte, mais dans la priorité syslog.

C'est à cette fin qu'existe l'option « Syslog priority to cancel event ». Saisissez ici la plage debug …​ notice par exemple. Toutes les priorités de cette plage sont normalement considérées comme ayant un statut OK. Lorsque vous utilisez cette option, vous devez tout de même saisir un texte approprié dans le champ « Text to cancel event(s) », sinon la règle sera saisie pour tous les messages OK concernant la même application.

Vous pouvez activer le check des messages qui apparaissent trop souvent à l'aide de l'option « Count messages in interval » :

Vous devez d'abord spécifier une période de temps dans « Time period for counting » et le nombre de messages devant entraîner l'ouverture d'un événement dans « Count until triggered ». Dans l'exemple ci-dessus, ce paramètre est défini sur 10 messages par heure. Bien entendu, il ne s'agit pas de 10 messages arbitraires, mais de messages correspondant à la règle.

En règle générale, il est préférable de ne pas compter globalement tous les messages correspondants, mais uniquement ceux qui se rapportent à la même « cause ». Pour contrôler cela, il existe trois cases à cocher pour les options précédées de Force separate events for different …​. Celles-ci sont préréglées de telle sorte que les messages ne sont comptés ensemble que s’ils correspondent dans :

Cela vous permet de formuler des règles telles que « Si plus de 10 messages sont reçus par heure provenant du même ordinateur hôte, de la même application et de la même instance, alors…​ ». En raison de cette règle, cela peut entraîner la génération de plusieurs événements différents.

Si, par exemple, vous désélectionnez les trois cases à cocher, le comptage ne s’effectuera alors qu’au niveau global et la règle ne pourra générer qu’un seul événement au total !

À ce propos, il peut être judicieux de saisir 1 comme nombre. De cette manière, vous pouvez maîtriser efficacement les « tempêtes d’événements ». Si, par exemple, 100 messages du même type sont reçus en peu de temps, un seul événement sera néanmoins créé. Vous verrez alors dans les détails de l’événement

Une fois le dossier fermé, deux cases à cocher vous permettent de définir quand un nouvel événement doit être ouvert. Normalement, la confirmation de l’événement entraîne, si d’autres messages sont reçus, le démarrage d’un nouveau compteur et le déclenchement d’un nouvel événement. Cette fonction est désactivée à l’aide de l’option « Continue counting when event is acknowledged ».

L'option « Discontinue counting after time has elapsed » garantit qu'un événement distinct est toujours ouvert pour chaque période de comparaison. Dans l'exemple ci-dessus, une valeur seuil de 10 messages par heure a été spécifiée. Si cette option est activée, un maximum de 10 messages d'une heure sera ajouté à un événement déjà ouvert. Dès que l'heure s'est écoulée, si un nombre suffisant de messages a été reçu, un nouvel événement sera ouvert.

Par exemple, si vous définissez le nombre sur 1 et l'intervalle de temps sur un jour, vous ne verrez qu'un seul événement de ce type de message par jour au maximum.

Le paramètre «Algorithm » peut paraître un peu surprenant à première vue. Mais soyons réalistes : Que voulez-vous dire exactement par « 10 messages par heure » ? De quelle heure s'agit-il ? Toujours les heures pleines de la journée ? Il se pourrait que, dans la dernière minute d’une heure, neuf messages soient reçus, et neuf autres dans la première minute de l’heure suivante. Cela ferait alors 18 messages en seulement deux minutes écoulées, mais toujours moins de 10 par heure, et la règle ne s’appliquerait donc pas. Cela ne semble pas très raisonnable…​

Comme il n’existe pas de solution unique à ce problème, Checkmk propose trois définitions différentes de ce que signifie exactement « 10 messages par heure » :

Alors, quel algorithme devriez-vous choisir ?

Les événements qui n’ont pas encore atteint le nombre défini sont latents mais ne sont pas automatiquement visibles pour l’opérateur. Ils se trouvent en phase d’counting. Vous pouvez rendre ces événements visibles à l’aide du filtre « phase » dans la vue de la table des événements :

Tout comme l'arrivée d'un message particulier peut signifier un problème, l'absence d'un message peut également signifier un problème. Vous pouvez vous attendre à recevoir au moins un message par jour provenant d'une tâche particulière. Si ce message n'arrive pas, la tâche n'est probablement pas en cours d'exécution et doit être corrigée de toute urgence.

Vous pouvez configurer une option de ce type sous « Counting & Timing > Expect regular messages » :

Comme pour le comptage, vous devez spécifier une période de temps pendant laquelle vous vous attendez à ce que le ou les messages apparaissent. Ici, cependant, un algorithme complètement différent est utilisé, ce qui est beaucoup plus logique dans ce contexte. La période de temps est toujours alignée exactement sur des positions définies. Par exemple, l'intervalle hour commence toujours à la minute et à la seconde zéro. Vous disposez des options suivantes :

Pourquoi est-ce si compliqué ? C'est pour éviter les fausses alertes. Vous attendez-vous, par exemple, à recevoir un message de sauvegarde par jour ? Il y aura certainement de légères différences dans la durée d'exécution de la sauvegarde, de sorte que les messages ne seront pas reçus exactement à 24 heures d'intervalle. Par exemple, si vous vous attendez à ce que le message arrive vers minuit, à une heure ou deux près, un intervalle de 12 h 00 à 12 h 00 sera bien plus réaliste qu’un intervalle de 00 h 00 à 00 h 00. Toutefois, si le message ne parvient pas, vous ne recevrez une notification qu’à midi, à 12 h 00.

L'option «Merge with open event» est préréglée de telle sorte que, si le même message apparaît à plusieurs reprises, l'événement existant sera mis à jour. Vous pouvez modifier ce paramètre afin qu'un nouvel événement soit créé à chaque fois.

Le bouton « Add new action » vous permet de créer une nouvelle action. L'exemple suivant montre comment créer un script shell simple en tant qu'action de type « Execute Shell Script ». Les détails relatifs aux événements sont accessibles au script via des variables d'environnement, par exemple l'$CMK_ID de l'événement, l'$CMK_HOST, le texte complet $CMK_TEXT ou le premier groupe de correspondance sous la forme $CMK_MATCH_GROUP_1. Pour obtenir la liste complète des variables d'environnement disponibles, consultez l'aide en ligne de .

Les anciennes versions de Checkmk autorisaient les variables d'environnement ainsi que les macros telles que $TEXT$, qui étaient remplacées avant l'exécution du script. En raison du risque qu'un attaquant puisse injecter des instructions via un paquet UDP spécialement conçu, exécuté avec les privilèges du processus Checkmk, vous ne devez pas utiliser de macros. Les macros sont actuellement encore prises en charge pour des raisons de compatibilité, mais nous nous réservons le droit de les supprimer dans une future version de Checkmk.

Le script d'exemple présenté dans la capture d'écran crée le fichier tmp/test.out dans le répertoire d'instances, dans lequel il écrit un texte contenant les valeurs concrètes des variables pour le dernier événement concerné :

Les scripts sont exécutés dans l'environnement suivant :

Si votre script contient éventuellement des temps d'attente, vous pouvez le faire s'exécuter de manière asynchrone à l'aide du spooler Linux at. Pour ce faire, créez le script dans un fichier local/bin/myaction séparé et lancez-le avec l'instruction at, par exemple :

Le type d'action « Send Email » envoie un courrier électronique au format texte simple. Vous pourriez en réalité également effectuer cette opération à l'aide d'un script, par exemple en utilisant l'instruction en ligne de commande « mail ». Mais cette méthode est plus pratique. Notez que les espaces réservés sont également autorisés dans les champs « Recipient email address » et « Subject ».

Les événements peuvent provenir de n’importe quel ordinateur hôte, qu’il soit configuré ou non dans la supervision active. En effet, les ports syslog et SNMP sont ouverts à tous les ordinateurs hôtes du réseau. Par conséquent, les attributs d’hôte étendus tels que les alias, les balises de l’hôte, les contacts, etc. ne sont initialement pas disponibles. C’est notamment pour cette raison que les conditions des règles de notification ne fonctionnent pas nécessairement comme vous pourriez vous y attendre.

Par exemple, lors d’une notification, l’EC tente de trouver un ordinateur hôte dans la supervision active qui correspond à l’événement. Cette opération s’effectue selon la même procédure que celle utilisée pour la visibilité des événements. Si un tel ordinateur hôte est trouvé, les données suivantes sont extraites de cet ordinateur hôte :

Par conséquent, le nom de domaine figurant dans la notification traitée peut ne pas correspondre exactement au nom de domaine du message d'origine. Le codage des textes de notification, conforme à celui de la supervision active, simplifie toutefois la formulation de règles de notification uniformes incluant des conditions qui s'appliquent au nom de domaine.

L'affectation s'effectue en temps réel en envoyant une requête Livestatus au noyau de supervision qui s'exécute sur le même site que le contrôleur (EC) ayant reçu le message. Bien entendu, cela ne fonctionne que si les messages syslog, les traps SNMP, etc. sont toujours envoyés au site Checkmk sur lequel l'ordinateur hôte est activement supervisé !

Si la requête ne fonctionne pas ou si l'ordinateur hôte est introuvable, des données de substitution seront acceptées :

Si l'ordinateur hôte ne peut pas être attribué dans la supervision active, cela peut bien sûr entraîner des problèmes avec les notifications. D'une part en raison des conditions, qui peuvent alors ne plus s'appliquer, et d'autre part en raison de la sélection des contacts. Dans de tels cas, vous pouvez modifier vos règles de notification afin que les notifications provenant de la Event Console soient traitées spécifiquement à l'aide de leurs propres règles. À cette fin, il existe une condition distincte avec laquelle vous pouvez soit faire correspondre positivement uniquement les notifications EC, soit, à l'inverse, les exclure :

Pour que les notifications provenant de l’EC transitent par le système de notification de la supervision active, l’EC doit être adaptée afin de se conformer à son schéma. Ce faisant, les champs de données typiques d’une notification sont remplis de la manière la plus efficace possible. Nous venons de décrire comment les données de l’ordinateur hôte sont déterminées. Les autres champs sont les suivants :

Comme décrit ci-dessus, il peut s’avérer impossible de déterminer automatiquement les contacts pour un événement. Dans ce cas, vous pouvez spécifier des groupes de contacts directement dans la règle EC qui doit être utilisée pour la notification. Il est important de ne pas oublier de checker la case « Use in notifications » :

Il existe un commutateur central pour les notifications dans le snap-in « Master control ». Cela s'applique également aux notifications transmises par l'EC :

Tout comme pour l'affectation d'hôte, l'interrogation de ce commutateur par l'EC nécessite un accès Livestatus au noyau de supervision local. Une interrogation réussie est visible dans le fichier journal de l'Event Console :

La Event Console est capable de détecter les ordinateurs hôtes qui sont actuellement en période de maintenance planifiée et n'envoie pas de notifications dans de telles situations. Dans le fichier journal, cela se présentera comme suit :

Bien entendu, cela nécessite également que l'ordinateur hôte soit détecté avec succès lors de la supervision active. Si cela échoue, on suppose que l'ordinateur hôte n'est pas en période de maintenance et une notification sera générée dans tous les cas.

Lorsque vous écrivez vos propres scripts de notification, en particulier pour les notifications provenant de l'Event Console, un certain nombre de variables supplémentaires sont disponibles pour décrire l'événement d'origine (accessibles comme d'habitude avec le préfixe NOTIFY_) :

Pour mesurer vos performances, il existe un snap-in distinct pour la barre latérale, intitulé «Event Console Performance». Vous pouvez l'ajouter comme d'habitude à l'aide de l' :

Les valeurs affichées ici correspondent à des moyennes sur environ la dernière minute. Une tempête d'événements ne durant que quelques secondes ne peut pas être lue directement ici, mais les chiffres ont été quelque peu lissés et sont donc plus faciles à lire.

Pour tester les performances maximales, vous pouvez générer artificiellement une tempête de messages non classés (uniquement dans le système de test, s'il vous plaît !), par exemple dans une boucle shell en écrivant en continu le contenu d'un fichier texte dans le canal des événements.

Les valeurs les plus importantes du snap-in ont la signification suivante :

Vous pouvez voir combien de messages l'Event Console peut traiter par seconde à partir de l'Processing time per message. Ce temps est généralement lié au nombre de règles qui doivent être testées avant qu'un message ne soit traité. Vous disposez ici de plusieurs options d'optimisation :

De plus, l'EC propose une optimisation basée sur la priorité et la facilité syslog. Pour chaque combinaison de priorité et de facilité, une chaîne de règles distincte est créée en interne, dans laquelle seules les règles pertinentes pour les messages de cette combinaison sont incluses.

Chaque règle contenant une condition relative à la priorité, à la facilité ou, de préférence, aux deux, ne sera pas incluse dans toutes ces chaînes de règles, mais de manière optimale dans une seule. Cela signifie que la règle n'a pas besoin d'être checkée pour les messages ayant une classification syslog différente.

Après un redémarrage, vous verrez dans ~/var/log/mkeventd.log un aperçu des chaînes de règles optimisées :

Dans l'exemple ci-dessus, vous pouvez constater que, dans tous les cas, 67 règles doivent être vérifiées. Pour les messages provenant de la facilité daemon, 89 règles sont pertinentes ; ce n'est que pour la combinaison daemon / emerg que 120 règles doivent être vérifiées. Chaque règle comportant une condition relative à la priorité ou à la facilité réduit encore ce nombre de 67.

Bien entendu, vous ne pouvez définir ces conditions que si vous êtes certain qu’elles sont remplies par les messages concernés !

La Event Console dispose d'une protection automatique contre le « débordement ». Celle-ci limite le nombre d'événements en cours par ordinateur hôte, par règle et globalement. Sont pris en compte non seulement les événements ouverts, mais également ceux se trouvant dans d'autres phases, telles que « delayed » ou « counting ». Les événements archivés ne sont pas pris en compte.

Cela vous protège dans les situations où, en raison d’un problème systématique sur votre réseau, des milliers d’événements critiques affluent et où l’Event Console risquerait de « s’arrêter ». D’une part, cela empêche une dégradation des performances de l’Event Console, qui devrait alors stocker un trop grand nombre d’événements dans sa mémoire principale. D’autre part, l’aperçu pour l’opérateur est (quelque peu) protégé et les événements qui ne font pas partie de cette vague restent visibles.

Une fois la limite atteinte, l'une des actions suivantes se produira :

Les limites ainsi que l'effet associé à leur atteinte sont définis dans les paramètres de l'Event Console avec l'option « Limit amount of current events ». La figure suivante illustre le paramètre par défaut :

Si vous avez activé une valeur avec «…​create overflow event», lorsque la limite est atteinte, un seul événement artificiel sera créé, informant l'opérateur de la situation d'erreur :

Si vous avez également activé une valeur avec « …​notify contacts », les contacts appropriés seront informés via une notification Checkmk. Cette notification passera par les règles de notification Checkmk. Ces règles ne doivent pas nécessairement suivre la sélection de contacts de l’Event Console, mais peuvent la modifier. Le tableau suivant indique quels contacts sont sélectionnés si vous avez défini « Notify all contacts of the notified host or service » (ce qui est le réglage par défaut) :