La Event Console

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 façon, pour les modifications qui affectent plusieurs règles liées, vous pouvez spécifier exactement quand les règles doivent être mises en ligne. Et avant cela, vous pouvez utiliser le site Event Simulator pour tester si tout va comme prévu.

Tout d'abord, cliquez sur le nombre de modifications accumulées en haut à droite de la page.

Cliquez ensuite sur Activate on selected sites pour activer les modifications. L'Event Console est conçue de manière à ce que cette action se déroule sans interruption. La réception des messages entrants est assurée à tout moment, de sorte qu'aucun message ne peut être perdu au cours du processus.

Seuls les administrateurs sont autorisés à activer les modifications dans la CE, ce qui est contrôlé par l'autorisation Activate changes for event console.

Pour les tests, vous pourriez bien sûr envoyer des messages via Syslog ou SNMP. Vous devriez également le faire plus tard. Mais pour un premier test, l'adresse Event Simulator intégrée à la CE est plus pratique :

Ici, vous avez deux options :Try out évalue, sur la base du message simulé, laquelle des règles pourrait être saisie. Si vous vous trouvez au niveau supérieur de l'interface graphique de configuration du CE, les ensembles de règles sont 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 :

En cliquant sur Generate event, vous obtenez à peu près le même résultat que sur Try out, à ceci près que le message est effectivement généré.Toutes les actions définies sont exécutées. L'événement apparaît alors également dans les événements ouverts de la surveillance. 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 réel sur le réseau, vous pouvez facilement envoyer un message syslog à partir d'un autre ordinateur Linux à la main. Puisque le protocole est si simple, vous n'avez même pas besoin d'un programme spécial, vous pouvez simplement envoyer les données via netcat ou nc en utilisant UDP. Le contenu du paquet UDP consiste en une seule ligne de texte. Si cela est conforme à une structure spécifique, l'Event Console décompose les composants proprement :

Mais vous pouvez aussi simplement envoyer n'importe quoi. La CE l'acceptera alors de toute façon et l'évaluera simplement comme un texte de message. Des informations supplémentaires telles que l'application, la priorité, etc. seront bien sûr manquantes. Pour des raisons de sécurité, l'état CRIT sera supposé :

Dans l'instance Checkmk qui exécute la CE, il existe un tuyau nommé, dans lequel vous pouvez écrire des messages texte localement via echo. Il s'agit d'une méthode très simple pour connecter une application locale et également d'un moyen de tester le traitement des messages :

D'ailleurs, il est également possible d'envoyer des messages au format syslog, de sorte que tous les champs des données d'événement soient remplis proprement.

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 confirmer l'événement. Le champ Change contact est intentionnellement en texte libre. Vous pouvez y saisir des éléments tels que des numéros de téléphone. En particulier, ce champ n'a aucune influence 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 permet à l'événement de passer de la phase open à la phase acknowledged et d'être désormais affiché sous la forme handled, ce qui correspond à la confirmation des problèmes d'hôte et de service.

L'invocation ultérieure de l'instruction avec la case à cocher décochée supprime la 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éfinies sur les événements. Au départ, seule l'action Send monitoring notification est disponible. Elle envoie une notification Checkmk qui sera traitée de la même manière qu'une notification provenant d'un service activement surveillé. 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 le CE.

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 l'archive, 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 confortablement des événements individuels à partir de la liste des événements à l'aide de .

Pour assurer la visibilité des hôtes et des services dans la surveillance pour les utilisateurs normaux, Checkmk utilise des groupes de contacts. Ces groupes sont assignés aux hôtes et aux services via l'interface graphique, la configuration des règles ou des dossiers.

Dans le cas de l'Event Console, une telle affectation d'événements à des groupes de contacts n'existe pas. En effet, on ne sait tout simplement pas à l'avance quels messages seront effectivement reçus. Même la liste des hôtes n'est pas connue, car les sockets pour Syslog et SNMP sont accessibles de partout. C'est pourquoi l'Event Console comprend quelques fonctions spéciales pour définir la visibilité.

Tout d'abord, lors de la configuration des rôles d'utilisateur, il y a l'autorisation Event Console > See all events. Elle est active par défaut, de sorte que les utilisateurs normaux sont autorisés à voir tous les événements !Ceci est délibérément mis en place pour s'assurer que les messages d'erreur importants ne tombent pas à côté en raison d'une configuration incorrecte. La première étape pour une visibilité plus précise est de supprimer cette autorisation du rôle user.

Pour que la visibilité des événements soit aussi cohérente que possible avec le reste de la surveillance, l'Event Console essaie autant que possible de saisir les hôtes dont elle reçoit les événements en fonction des hôtes configurés via l'interface graphique de configuration. Ce qui semble simple est délicat dans les détails. Parfois, un nom d'hôte manque dans l'événement et seule l'adresse IP est connue. Dans d'autres cas, le nom d'hôte est orthographié différemment de ce qui est indiqué dans l'interface graphique de configuration.

L'attribution se fait comme suit :

Vous pouvez influencer l'affectation à un moment donné : 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:

En outre, vous pouvez effectuer des réglages directement dans la règle de notification, ce qui permet de donner la priorité au type d'événement par rapport aux responsabilités habituelles d'un hôte.

Tant pour les ensembles de règles ...

... que pour les règles individuelles ...

... dans la colonne Hits, vous trouverez des informations sur le nombre de fois que le paquet ou la règle a déjà saisi un message. Cela vous aide à éliminer ou à réparer les règles inefficaces. Mais cela peut également être intéressant pour les règles qui saisissent très souvent un message. Pour une performance optimale du CE, ces règles devraient se trouver au début de la chaîne de règles. De cette façon, vous pouvez réduire le nombre de règles que le CE doit saisir pour chaque message.

Vous pouvez remettre les compteurs à zéro à tout moment à l'aide de l'élément de menu Event Console > Reset counters.

Lors du test d'une règle, vous avez déjà vu comment vous pouvez utiliser Event Simulator pour vérifier les évaluations de vos règles. Vous pouvez obtenir des informations similaires au moment 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, dans lequel vous trouverez la raison exacte pour laquelle une règle qui a été checkée n'a pas pris effet :

Il va sans dire que vous ne devriez 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 en ignorant les majuscules et les minuscules. Il s'agit d'une exception aux conventions de Checkmk dans d'autres modules. Toutefois, cela rend la formulation des règles plus robuste, notamment parce que les noms d'hôte dans les événements ne sont pas nécessairement cohérents dans leur orthographe s'ils ont été configurés sur chaque hôte localement plutôt que de manière centralisée. Cette exception est donc très utile dans ce cas.

En outre, une correspondance d'infixe s'applique toujours - c'est-à-dire un check pour un contenu du texte de recherche. Vous pouvez donc saisir une .* 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 l'hôte, mais qu'un nom d'hôte explicite est utilisé, il sera saisi pour une correspondance exacte et non pour son contenu.

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

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

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

Le champ WP41 est bien entendu variable et vous ne souhaitez certainement pas formuler une règle distincte pour chaque cas différent. C'est pourquoi vous utilisez .* dans l'expression rationnelle, qui représente n'importe quelle chaîne de caractères :

Database instance .* has failed

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

Database instance (.*) has failed

Lorsque la règle a été saisie avec succès, le premier groupe de correspondance est maintenant défini sur la valeur WP41 (ou sur l'instance qui a produit l'erreur).

Vous pouvez saisir ces groupes de correspondance sur le site Event Simulator en plaçant 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 :

A ce stade, un conseil : dans certaines situations, vous devez grouper quelque chose dans l'expression régulière mais vous ne voulez 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 ne saisit pour one 123 two 456 three que le 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. Indiquez soit une adresse exacte, soit un réseau dans la notation 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 sur l'adresse IP ne fonctionne que si les systèmes surveillés envoient directement à l'Event Console. Si un autre serveur syslog intermédiaire connecté transmet les messages, son adresse apparaîtra comme celle de l'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 informations 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 à quelque chose comme une application, mais la sélection n'a pas été faite de manière très prospective à l'époque. L'une des facilités est uucp- un protocole qui, au début des années 90 du dernier millénaire, était déjà presque obsolète.

Mais il est un fait que chaque message qui arrive via syslog porte 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. C'est très utile.

L'utilisation de la facilité et de la priorité a également un aspect performant. Si vous définissez une règle qui ne s'applique de toute façon qu'aux messages qui ont tous la même facilité ou priorité, vous devez définir ces dernières en plus dans les filtres de la règle. L'Event Console peut alors contourner ces règles de manière très efficace lorsqu'un message avec des valeurs différentes est reçu. Plus il y a de règles avec ces filtres définis, moins il y a de comparaisons de règles nécessaires.

La case à cocher Negate match: Execute this rule if the upper conditions are not fulfilled. fait en sorte que la règle ne prenne effet que lorsqu'aucune des conditions n' est remplie. En fait, cela n'est utile que dans le contexte de deux types de règles (Rule type dans la case Outcome & Action de la règle) :

Vous pouvez en savoir plus sur les ensembles de règles ci-dessous.

Lorsqu'une règle est saisie, elle précise ce qu'il doit advenir du message, ce qui est fait dans la case Outcome & Action:

L'adresse Rule type peut être utilisée pour interrompre l'évaluation à ce point entièrement ou pour le paquet de règles actuel. La première option en particulier devrait être utilisée pour se débarrasser de la plupart des "bruits" inutiles en utilisant quelques règles spécifiques au tout début. Ce n'est qu'avec les règles "normales" que les autres options de cette case sont réellement évaluées.

Avec State, la règle définit le statut de l'événement dans la surveillance. 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 état explicite, il existe deux autres options dynamiques. Le paramètre (set by syslog) prend en charge la classification sur la base de la priorité syslog. Cela ne fonctionne que si le message a déjà été classifié de manière utilisable par l'expéditeur. Les messages reçus directement par syslog contiendront l'une des huit priorités RFC, qui sont mises en correspondance comme suit :

Outre les messages syslog, les messages provenant du journal des événements de Windows et les messages provenant de fichiers texte qui ont déjà été classés avec le plugin Checkmk Logwatch sur le système cible, fournissent des états prêts à l'emploi. Pour les trap SNMP, cela n'est malheureusement pas disponible.

Une méthode complètement différente consiste à classer le message sur la base du texte lui-même, ce qui peut être fait à l'aide du paramètre (set by message text):

La saisie des textes configurés ici n'a lieu qu'après la vérification de Text to match et des autres conditions de la règle, 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 retourne à l'état UNKNOWN.

L'idée derrière le champ Service Level est que chaque hôte et chaque service dans une organisation a un certain niveau d'importance. Cela peut être associé à un accord de service spécifique pour l'hôte ou le service. Dans Checkmk, vous pouvez utiliser des règles pour assigner de tels niveaux de service à vos hôtes et services et ensuite, par exemple, faire en sorte que la notification ou les tableaux de bord auto-définis en dépendent.

Comme les événements ne sont pas nécessairement en corrélation avec les hôtes ou les 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 de l'événement à l'aide 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 en fonction de vos besoins sur le site Global settings > Notifications > Service Levels. Les chiffres désignant les niveaux sont décisifs, car les niveaux sont triés en fonction de ces chiffres et comparés en fonction de leur importance relative.

Les groupes de contacts utilisés pour la visibilité sont également utilisés pour la notification des événements. Vous pouvez utiliser des règles pour affecter explicitement des groupes de contacts aux événements. Vous trouverez plus de détails à ce sujet dans le chapitre sur la surveillance.

Les actions sont très similaires aux gestionnaires d'alertes pour les hôtes et les services. Ici, vous pouvez avoir un script auto-défini exécuté lorsqu'un événement est ouvert. Tous les détails décrivant les actions peuvent être trouvés ci-dessous dans une section séparée.

La suppression automatique (= archivage), que vous pouvez définir avec Delete event immediately after the actions, garantit qu'un événement n'est pas du tout visible dans la surveillance. C'est utile si vous voulez seulement déclencher certaines actions automatiquement ou si vous voulez seulement archiver certains événements afin de pouvoir les rechercher plus tard.

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 remplacés par les valeurs du message OK avant que toute action ne soit exécutée. Ainsi, les données complètes du message OK sont disponibles dans le script d'action. En outre, pendant cette phase, l'état de l'événement est marqué comme OK. De cette manière, un script d'action peut détecter une annulation et vous pouvez utiliser le même script pour les messages d'erreur et les messages OK (par exemple, lors d'une 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'identifiant de l'événement.

Si vous utilisez la réécriture et l'annulation dans la même règle, vous devez faire attention lorsque vous réécrivez le nom d'hôte ou l'application. Lorsque vous annulez un événement, la console d'événements vérifie toujours si le message d'annulation saisit le nom d'hôte et l'application de l'événement ouvert. Mais si ces éléments sont réécrits, l'annulation ne fonctionnera jamais.

C'est pourquoi, avant d'annuler l'événement, l'Event Console simule une réécriture du nom de l'hôte et de l'application afin de comparer les textes pertinents, ce qui correspond probablement à ce que vous attendez.

Vous pouvez également tirer parti de ce comportement si le champ de l'application dans le message d'erreur et le message OK ultérieur ne se saisissent pas. Dans ce cas, il suffit de réécrire le champ de l'application en lui attribuant une valeur fixe connue, ce qui aboutit en fait au résultat suivant : 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.

Pour ce faire, il existe l'option Syslog priority to cancel event. Entrez ici la plage debug... notice par exemple. Toutes les priorités dans cette plage sont normalement considérées comme ayant un statut OK. Lorsque vous utilisez cette option, vous devez toujours entrer un texte approprié dans le champ Text to cancel event(s), sinon la règle saisira tous les messages OK qui affectent la même application.

Vous pouvez activer le check des messages trop fréquents avec l'option Count messages in interval:

Dans ce cas, vous devez d'abord spécifier une période à l'adresse Time period for counting et le nombre de messages qui doivent entraîner l'ouverture d'un événement à l'adresse Count until triggered. Dans l'exemple ci-dessus, ce nombre est fixé à 10 messages par heure. Bien entendu, il ne s'agit pas de 10 messages arbitraires, mais bien de messages saisis par la règle.

Normalement, il est logique de ne pas compter tous les messages correspondants globalement, mais seulement ceux qui se réfèrent à la même "cause". Pour contrôler cela, il y a les trois cases à cocher pour les options préfixées par Force separate events for different …​. Elles sont préréglées de telle sorte que les messages ne sont comptés ensemble que s'ils saisissent la même chose :

Cela vous permet de formuler des règles telles que "Si plus de 10 messages sont reçus par heure en provenance du même hôte, de la même application et de la même instance, alors...". En raison de la règle, plusieurs événements différents peuvent être générés.

Si, par exemple, vous désélectionnez les trois cases à cocher, le comptage ne se fera que globalement et la règle ne pourra générer qu'un seul événement au total !

D'ailleurs, il peut être judicieux d'indiquer 1 comme valeur de comptage, ce qui vous permet de contrôler efficacement les "tempêtes d'événements". Si, par exemple, 100 messages du même type sont reçus dans un court laps de temps, un seul événement sera créé. Vous verrez alors dans les détails de l'événement

Lorsque l'affaire est ensuite clôturée, deux cases à cocher vous permettent de définir quand un nouvel événement doit être ouvert. Normalement, une confirmation de l'événement crée une situation dans laquelle, si d'autres messages sont reçus, un nouveau décompte est lancé et un nouvel événement est déclenché. Vous pouvez désactiver cette fonction à 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, un seuil de 10 messages par heure a été spécifié. 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 fixez le nombre à 1 et l'intervalle de temps à un jour, vous ne verrez qu'un événement maximum de ce type de message par jour.

Le paramètre Algorithm peut surprendre à première vue. Mais soyons réalistes : qu'entendez-vous par "10 messages par heure" ?De quelle heure s'agit-il ? Toujours des heures entières de la journée ? Il se peut que neuf messages soient reçus dans la dernière minute d'une heure et neuf autres dans la première minute de l'heure suivante. Cela fait alors 18 messages en seulement deux minutes de temps écoulé, 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 la notion de "10 messages par heure":

Quel algorithme choisir ?

Les événements qui n'ont pas encore atteint le nombre fixé sont latents mais ne sont pas automatiquement visibles par l'opérateur. Ils se trouvent dans la phase 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 être synonyme de problème, l'absence de message peut également l'être. Vous pouvez vous attendre à recevoir au moins un message par jour de la part d'un travail particulier. Si ce message n'arrive pas, le travail ne fonctionne probablement pas et doit être réparé de toute urgence.

Vous pouvez configurer quelque chose comme cela sous Counting & Timing > Expect regular messages:

Comme pour le comptage, vous devez spécifier une période de temps au cours de laquelle vous vous attendez à ce que le(s) message(s) apparaisse(nt). Ici, cependant, un algorithme complètement différent est utilisé, ce qui est beaucoup plus logique à ce stade. 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 à recevoir un message d'une sauvegarde par jour, par exemple ? 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 à 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:00 à 12:00 sera beaucoup plus réaliste qu'un intervalle de 00:00 à 00:00. Toutefois, si le message n'apparaît pas, vous ne recevrez une notification qu'à 12:00 à midi.

L'option Merge with open event est prédéfinie de telle sorte qu'en cas d'apparition répétée du même message, l'événement existant sera mis à jour. Vous pouvez modifier cette option de manière à ce qu'un nouvel événement soit ouvert à 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 des événements sont disponibles pour le script via les variables d'environnement, par exemple le $CMK_ID de l'événement, le $CMK_HOST, le texte intégral $CMK_TEXT ou le premier groupe de correspondance en tant que $CMK_MATCH_GROUP_1. Pour une liste complète des variables d'environnement disponibles, consultez l'aide en ligne.

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 par le biais d'un paquet UDP spécialement conçu qui est exécuté avec les privilèges du processus Checkmk, vous ne devriez pas utiliser de macros. Les macros sont actuellement toujours prises en charge pour des raisons de compatibilité, mais nous nous réservons le droit de les supprimer dans une future version de Checkmk.

L'exemple de script 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 correspondant :

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

Si votre script contient éventuellement des temps d'attente, vous pouvez l'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 distinct et lancez-le à l'aide de l'instruction at, par exemple :

Le type d'action Send Email envoie un simple courrier électronique textuel. En fait, vous pourriez aussi le faire avec un script, par exemple en utilisant l'instruction en ligne de commande mail. Mais de cette façon, c'est plus pratique. Veuillez noter que les caractères génériques sont également autorisés dans les champs Recipient email address et Subject.

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

Par exemple, lors de la notification, le CE tente de trouver un ordinateur dans la surveillance active qui saisit l'événement. Pour ce faire, il utilise la même procédure que pour la visibilité des événements. Si un tel ordinateur est trouvé, les données suivantes sont extraites de cet ordinateur :

Par conséquent, le nom de l'hôte dans la notification traitée peut ne pas correspondre exactement au nom de l'hôte dans le message original. Le codage de textes de notification conformes à ceux de la surveillance active simplifie toutefois la formulation de règles de notification uniformes qui comprennent des conditions s'appliquant au nom de l'hôte.

Le mappage est effectué en temps réel en envoyant une requête Livestatus au noyau de surveillance qui fonctionne sur le même site que le CE qui a 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'hôte est activement surveillé !

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

Si l'hôte ne peut pas être attribué dans la surveillance active, cela peut bien sûr entraîner des problèmes au niveau des 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 ce cas, vous pouvez modifier vos règles de notification de manière à ce que les notifications provenant de l'Event Console soient traitées spécifiquement à l'aide de leurs propres règles. Pour ce faire, il existe une condition distincte avec laquelle vous pouvez soit saisir positivement uniquement les notifications de l'EC, soit les exclure à l'inverse :

Pour que les notifications de la CE puissent passer par le système de notification de la surveillance active, la CE doit être adaptée pour se conformer à son schéma. Au cours de ce processus, les champs de données typiques d'une notification sont remplis le plus efficacement possible. Nous venons de décrire comment les données de l'hôte sont déterminées. Les champs restants sont les suivants :

Comme décrit ci-dessus, il se peut qu'il ne soit pas possible 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 CE qui doit être utilisée pour la notification. Il est important que vous n'oubliiez pas de checker la case Use in notifications:

Il existe un commutateur central pour les notifications dans le snap-in Master control. Ceci s'applique également aux notifications transmises par le CE :

Tout comme pour l'attribution d'un hôte, l'interrogation du commutateur par le CE nécessite un accès Livestatus au commutateur de surveillance local. Une interrogation réussie est visible dans le fichier journal de la console d'événements :

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

Bien entendu, il faut pour cela que l'hôte soit trouvé dans la surveillance active. En cas d'échec, on suppose que l'hôte n' est pas en période de maintenance et une notification est 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, vous disposez d'un certain nombre de variables supplémentaires qui décrivent l'événement d'origine (accessibles comme d'habitude avec le préfixe NOTIFY_) :

Pour mesurer vos performances, vous disposez d'un snap-in séparé dans la barre latérale, appelé Event Console Performance. Vous pouvez l'inclure comme d'habitude avec :

Les valeurs affichées ici sont des moyennes sur la dernière minute environ. Une tempête d'événements qui ne dure 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 classifiés (uniquement dans le système de test, s'il vous plaît !), par exemple, dans une boucle de shell en écrivant continuellement le contenu d'un fichier texte dans le tuyau d'événements.

Les lectures 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 Processing time per message. Ce temps est généralement lié au nombre de règles qui doivent être essayées avant qu'un message ne soit traité. Vous disposez de plusieurs options d'optimisation à cet égard :

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 qui contient une condition sur la priorité, la facilité ou de préférence les deux, ne sera pas incluse dans toutes ces chaînes de règles, mais de préférence dans une seule. Cela signifie que la règle n'a pas besoin d'être checkée pour les messages avec une classification syslog différente.

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

Dans l'exemple ci-dessus, vous pouvez voir que 67 règles doivent être vérifiées dans tous les cas. Pour les messages provenant de l'installation daemon, 89 règles sont pertinentes, et seulement pour la combinaison daemon/emerg, 120 règles doivent être vérifiées. Chaque règle qui reçoit une condition sur la priorité ou l'installation réduit encore le nombre de 67.

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

L'Event Console dispose d'une protection automatique contre les débordements, qui limite le nombre d'événements en cours par hôte, par règle et globalement. Sont pris en compte non seulement les événements ouverts, mais aussi les événements 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 l'Event Console "s'arrête". D'une part, cela évite une dégradation des performances de l'Event Console, qui devrait contenir trop 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 l'orage restent visibles.

Lorsqu'une limite est atteinte, l'une des actions suivantes se produit :

Les limites ainsi que l'effet associé lorsqu'elles sont atteintes sont définis dans les paramètres de l'Event Console à l'aide de Limit amount of current events. L'illustration suivante montre le paramètre par défaut :

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

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