Checkmk
DeutschEnglish
master2.3.0
to checkmk.com
Important

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

1.1. La supervision doit-elle intervenir ?

On pourrait penser qu’il va de soi qu’un système de supervision ne devrait jamais intervenir dans les événements — mais qu’il devrait, justement, se contenter de surveiller. Et il est probablement préférable d’en rester là.

Il est toutefois indéniable qu’il est séduisant d’imaginer qu’un système capable d’identifier de manière fiable les problèmes puisse également les corriger, à condition qu’il puisse fonctionner automatiquement.

On peut facilement imaginer quelques exemples pertinents :

  • Redémarrer un service qui a subi une plantage.

  • Le déclenchement d’un ramasse-miettes si une machine virtuelle Java est à court de mémoire.

  • La reconstruction d’un canal VPN s’il est définitivement hors service.

Si l'on peut accepter cela, il faut alors envisager la supervision sous un autre angle. D'un système qui se contente d'observer et qui n'est « pas indispensable » au fonctionnement, un processus progressif conduit à faire de la supervision un organe vital du centre de données.

Mais la correction des problèmes n’est pas la seule chose que la supervision peut faire automatiquement lorsqu’elle identifie un problème. La collection de données de diagnostic supplémentaires au moment d’une panne est très utile, mais aussi inoffensive. Vous pourriez sans doute penser spontanément à de nombreux autres cas dans lesquels on pourrait utiliser des gestionnaires d’alertes comme point de départ.

1.2. Les gestionnaires d’alertes dans Checkmk

CEE Les gestionnaires d’alertes sont des scripts que vous écrivez vous-même et qui sont exécutés pour vous par Checkmk dans les éditions commerciales si un problème est détecté — ou plus précisément — si un ordinateur hôte ou un service change de statut.

Les gestionnaires d’alertes sont très similaires aux notifications et se configurent de la même manière, mais il existe quelques différences importantes :

  • Les gestionnaires d’alertes sont indépendants des périodes de maintenance planifiées, des périodes de notification, des confirmations et des contrôles similaires.

  • Les gestionnaires d'alertes sont activés dès la première nouvelle tentative (si plusieurs tentatives de check ont été configurées).

  • Les gestionnaires d'alertes sont indépendants des utilisateurs et des groupes de contact.

  • Les gestionnaires d'alertes ne sont disponibles que dans les éditions commerciales.

On peut également dire que les gestionnaires d'alertes sont très « bas niveau ». Dès qu'un ordinateur hôte ou un service change de statut, vos gestionnaires d'alertes configurés sont immédiatement activés. De cette manière, un gestionnaire d'alertes peut même effectuer une réparation avec succès avant qu'une alerte ne soit générée.

Vous pouvez bien sûr, comme toujours dans Checkmk, utiliser des règles pour définir les conditions dans lesquelles un gestionnaire particulier doit être exécuté. Vous trouverez dans cet article comment procéder ainsi que toutes les informations relatives aux gestionnaires d'alertes.

CRE Un conseil pour les utilisateurs de la communauté Checkmk d'CRE : vous pouvez également faire en sorte que la supervision exécute automatiquement des actions. Utilisez pour cela les « gestionnaires d'événements » de Nagios. Configurez-les à l'aide de fichiers de configuration manuels en syntaxe Nagios sous ~/etc/nagios/conf.d/. Les gestionnaires d'événements sont bien documentés. Vous trouverez facilement des informations à ce sujet via Google.

2. Configuration des gestionnaires d'alertes

2.1. Enregistrement des scripts dans le répertoire approprié

Les gestionnaires d'alertes sont des scripts exécutés sur le serveur Checkmk. Ils doivent être stockés dans le répertoire ~/local/share/check_mk/alert_handlers/ et peuvent être codés dans n'importe quel langage pris en charge par Linux, par exemple BASH, Python ou Perl. N'oubliez pas de rendre les scripts exécutables à l'aide de l'chmod +x

Si un commentaire est inséré à la deuxième ligne du script (avec le hashtag #), celui-ci apparaîtra comme nom du script dans la liste de sélection de la règle :

~/local/share/check_mk/alert_handlers/myhandler
#!/bin/bash
# Foobar handler for repairing stuff
...
Copier le contenu du fichier dans le presse-papiers
Contenu du fichier copié avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

2.2. Un gestionnaire d'alertes simple à tester

Comme pour les notifications, le script récupère toutes les informations relatives à l'ordinateur hôte ou au service sous forme de variables d'environnement, qui commencent toutes par le préfixe ALERT_.

Pour vérifier exactement quelles variables d'environnement apparaissent dans le script, vous pouvez utiliser le gestionnaire d'alertes suivant à titre de test :

~/local/share/check_mk/alert_handlers/debug
#!/bin/bash
# Dump all variables to ~/tmp/alert.out

env | grep ^ALERT_ | sort > $OMD_ROOT/tmp/alert.out
Copier le contenu du fichier dans le presse-papiers
Contenu du fichier copié avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

  • env affiche toutes les variables d'environnement.

  • grep ^ALERT_ sélectionne celles qui commencent par ALERT_.

  • sort Trie la liste obtenue par ordre alphabétique.

2.3. Activation du gestionnaire d'alertes

L'activation du gestionnaire s'effectue à l'aide de l'Setup > Events > Alert handlers

Procédez comme suit :

  1. Enregistrez le script dans l'~/local/share/check_mk/alert_handlers/debug.

  2. Rendez-le exécutable via chmod +x debug.

  3. Accédez à la page de configuration via Setup > Events > Alert handlers.

  4. À cet endroit, définissez une nouvelle règle à l'aide de l'Add rule.

Le formulaire de sélection du gestionnaire d'alertes permet un accès direct et affiche le titre qui est enregistré dans la deuxième ligne du script. Vous pouvez également ajouter des arguments, que vous saisissez dans les champs de texte. Ceux-ci seront interprétés comme des arguments de ligne de commande dans le script. Dans votre shell, vous pouvez y accéder avec $1, $2, etc.

alert handler arguments

Une fois la règle enregistrée, le gestionnaire d'alertes sera immédiatement actif et s'exécutera à chaque changement d'état d'un ordinateur hôte ou d'un service !

2.4. Test et diagnostic des pannes

Pour effectuer un test, modifiez manuellement un service, par exemple, de Fake check results à CRIT. Le fichier devrait maintenant avoir été créé avec les variables. Voici ses vingt premières lignes :

OMD[mysite]:~$ head -n 20 ~/tmp/alert.out
ALERT_ALERTTYPE=STATECHANGE
ALERT_CONTACTNAME=check-mk-notify
ALERT_CONTACTS=
ALERT_DATE=2016-07-19
ALERT_HOSTADDRESS=127.0.0.1
ALERT_HOSTALIAS=myserver123
ALERT_HOSTATTEMPT=1
ALERT_HOSTCHECKCOMMAND=check-mk-host-smart
ALERT_HOSTCONTACTGROUPNAMES=all
ALERT_HOSTDOWNTIME=0
ALERT_HOSTFORURL=myserver123
ALERT_HOSTGROUPNAMES=check_mk
ALERT_HOSTNAME=myserver123
ALERT_HOSTNOTESURL=
ALERT_HOSTNOTIFICATIONNUMBER=1
ALERT_HOSTOUTPUT=Packet received via smart PING
ALERT_HOSTPERFDATA=
ALERT_HOSTPROBLEMID=0
ALERT_HOSTSHORTSTATE=UP
ALERT_HOSTSTATE=UP
Copier les instructions dans le presse-papiers
Instruction(s) copiée(s) avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Un fichier journal relatant l'exécution (ou la non-exécution) du gestionnaire d'alertes se trouve dans~/var/log/alerts.log . La section relative à l'exécution du gestionnairedebug , pour le serviceFilesystem / sur l'ordinateur hôtemyserver123 , ressemblera à ceci :

~/var/log/alerts.log
2016-07-19 15:17:22 Got raw alert (myserver123;Filesystem /) context with 60 variables
2016-07-19 15:17:22 Rule ''...
2016-07-19 15:17:22  -> matches!
2016-07-19 15:17:22 Executing alert handler debug for myserver123;Filesystem /
2016-07-19 15:17:22 Spawned event handler with PID 6004
2016-07-19 15:17:22 1 running alert handlers:
2016-07-19 15:17:22 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 1 running alert handlers:
2016-07-19 15:17:24 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 Handler [6004] for myserver123;Filesystem / exited with exit code 0.
2016-07-19 15:17:24 Output:

Quelques conseils supplémentaires utiles :

  • Les textes générés par les gestionnaires d'alertes sur la sortie standard apparaissent dans le fichier journal aux côtés de Output:.

  • Le code de sortie du script sera également consigné (exited with exit code 0).

  • Les gestionnaires d'alertes s'avèrent particulièrement utiles lorsqu'ils exécutent une instruction sur l'ordinateur hôte cible. Checkmk propose une solution prête à l'emploi pour Linux qui sera expliquée plus loin.

3. Configuration basée sur des règles

Comme le montre l'exemple d'introduction, les événements devant déclencher les gestionnaires d'alertes sont définis à l'aide de règles. Ce fonctionnement est tout à fait similaire à celui des notifications, mais quelque peu simplifié. Dans l'exemple, nous n'avons spécifié aucune condition, ce qui est bien sûr irréaliste dans la pratique. L'exemple suivant illustre une condition qu'un gestionnaire d'alertes définit pour des ordinateurs hôtes et des services spécifiques :

alert handlers rule condition

Le gestionnaire d'alertes ne sera déclenché

  • pour les ordinateurs hôtes myhost123 et myhost124 ,

  • pour le service JVM CaramKern Memory,

  • si l'état passe de OK ou WARN à CRIT,

  • et ce, uniquement lors de la deuxième tentative de check.

Pour que le gestionnaire soit déclenché, il est nécessaire, dans cet exemple, d’utiliser une règle Maximum number of check attempts for service afin de définir le nombre minimum de tentatives de vérification à 2. Afin de supprimer une notification en cas de réussite du garbage collector, ce nombre doit être défini sur 3 — car si le gestionnaire peut résoudre le problème directement après la deuxième tentative, la troisième tentative devrait détecter un état OK et aucune autre notification ne sera donc nécessaire.

Tip

Contrairement à d’autres endroits dans Checkmk, chaque règle de gestionnaire d’alertes sera exécutée si les conditions sont remplies. Même si deux règles font appel au même gestionnaire, celui-ci s’exécutera effectivement deux fois. L’alert helper (expliqué dans le chapitre suivant) supprimera la deuxième exécution avec un message d’erreur, car le même gestionnaire ne doit pas s’exécuter plusieurs fois simultanément. Il est toutefois recommandé de configurer les règles de manière à ce que ce cas ne se présente pas.

4. Comment les gestionnaires d'alertes sont exécutés

4.1. Exécution asynchrone

Les gestionnaires d'alertes sont très souvent utilisés pour se connecter à distance à une machine affectée via SSH ou un autre protocole, puis pour y exécuter une action contrôlée par un script. Cette machine rencontrant un problème, il n'est pas exclu que la connexion prenne beaucoup de temps, voire qu'elle aboutisse à un timeout.

Afin que la supervision ne soit pas interrompue et que d’autres gestionnaires d’alertes ne soient pas bloqués pendant ce temps, les gestionnaires d’alertes sont, par principe, exécutés de manière asynchrone. Un processus d’aide — l’alert helper — est chargé de cette fonction, et il est lancé par le CMC. Afin de réduire le dépassement de charge système, cela ne se produit que si au moins une règle de gestionnaire d’alertes a été créée. Dans le fichier `cmc.log`, vous verrez alors la ligne suivante :

~/var/log/cmc.log
2016-07-19 15:17:00 [5] Alert handlers have been switched on

À chaque changement d’état d’un ordinateur hôte ou d’un service, l’alert helper reçoit une notification du CMC contenant toutes les informations pertinentes relatives à l’événement. Il évalue ensuite toutes les règles d’alerte et détermine si un gestionnaire d’alertes doit être déclenché. Si tel est le cas, le script approprié sera lancé et s’exécutera en arrière-plan en tant que processus externe.

4.2. Arrêt du noyau de supervision

Lorsque vous arrêtez le CMC (par exemple via omd stop ou en éteignant le serveur de supervision), tous les alert helpers encore en cours d'exécution seront interrompus. Ceux-ci ne seront pas répétés ultérieurement — car qui sait quand ce « plus tard » aura lieu ? Il est possible que le redémarrage d'un service ou d'un élément similaire s'avère plus néfaste qu'utile !

4.3. Timeouts

Afin de se protéger contre le lancement d’un trop grand nombre de processus en cas d’erreur, un timeout de 60 secondes (réglable) s’applique lorsqu’un gestionnaire d’alertes est en cours d’exécution. À l’issue de ce timeout, le gestionnaire sera arrêté. Concrètement, cela signifie qu’à la fin du timeout, un signal 15 (SIGTERM) sera envoyé au gestionnaire. De cette manière, celui-ci a la possibilité de s’arrêter proprement. Au bout de 60 secondes supplémentaires (double timeout), il sera alors définitivement « arrêté » par un signal 9 (SIGKILL).

4.4. Superposition

Checkmk empêche l’exécution simultanée d’assistants d’alertes s’ils s’appliquent au même ordinateur hôte/service et s’ils exécuteraient le même script avec les mêmes paramètres. Une telle situation indique que le premier gestionnaire d’alertes est toujours en cours d’exécution et qu’il serait absurde de lancer une deuxième copie du même gestionnaire d’alertes — le deuxième gestionnaire d’alertes serait immédiatement annulé et identifié comme « ayant échoué ».

4.5. Codes de sortie et sortie

Les sorties et les codes de sortie du gestionnaire d’alertes sont évalués de manière fiable et renvoyés au noyau du processeur, où ils sont enregistrés dans l’historique de supervision. De plus, vous pouvez déclencher une notification (voir ci-dessous).

4.6. Paramètres globaux

Il existe un certain nombre de paramètres globaux pour l'exécution des gestionnaires d'alertes :

alert handlers options

L'option « Alert handler log level » influence la journalisation dans le fichier journal de l'alert helper (~/var/log/alerts.log).

4.7. Master control

alert handlers master control off

D'un simple clic dans le snap-in « Master control », vous pouvez désactiver les gestionnaires d'alertes de manière globale. Les gestionnaires en cours d'exécution ne seront pas affectés et se poursuivront jusqu'à leur terme.

N'oubliez pas de remettre le petit commutateur sur vert dès que possible ! Sinon, vous pourriez être induit en erreur par un faux sentiment de sécurité, en pensant que la supervision règle tous les problèmes…​


5. Gestionnaires d'alertes dans l'historique

Les gestionnaires d'alertes créent des entrées dans l'historique de supervision. Cela vous offre une meilleure traçabilité par rapport à la simple utilisation du fichier journal d'alerts.log. Une entrée est créée dès qu'un gestionnaire d'alertes démarre et une autre lorsqu'il s'arrête.

Les gestionnaires d'alertes sont donc considérés de la même manière que les plugins de supervision classiques, ce qui signifie qu'ils doivent produire une ligne de texte et renvoyer l'un des quatre codes de sortie suivants : 0 (OK), 1 (WARN), 2 (CRIT) ou 3 (UNKNOWN). Toutes les erreurs qui empêchent d’emblée l’exécution d’un gestionnaire (interruption due à une exécution en double, script manquant, timeout, etc.) sont automatiquement signalées par le code UNKNOWN.

Par exemple, en appelant ce gestionnaire très simple…​

~/local/share/check_mk/alert_handlers/dummy
#!/bin/bash
# Dummy handler for testing

sleep 3
echo "Everything is fine again"
exit 0
Copier le contenu du fichier dans le presse-papiers
Contenu du fichier copié avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

... produit un résultat comme ci-dessus dans l'historique du service concerné (comme toujours, le message le plus récent apparaît en haut) :

alert handler history

Il existe également une vue générique Monitor > System > Alert handler executions , qui offre un aperçu global de tous les gestionnaires d'alertes en cours d'exécution.

6. Notification via les gestionnaires d'alertes

L'exécution d'un gestionnaire d'alertes — ou plus exactement, l'achèvement d'une exécution — est un événement qui déclenche une notification. Vous pouvez ainsi être informé qu'un gestionnaire a terminé sa tâche. Il existe deux types d'événements que vous pouvez filtrer dans une règle de notification :

alert handler notif condition

Vous pouvez ainsi faire la distinction entre les gestionnaires exécutés avec succès (code de sortie 0 — OK) et les échecs (tous les autres codes). La notification par courrier électronique de Checkmk n'affiche pas le résultat du contrôle, mais celui du gestionnaire d'alertes.

7. Gestionnaire d'alertes pour chaque exécution de check

Les gestionnaires d'alertes ne sont normalement appelés que lorsque l'état d'un ordinateur hôte ou d'un service change (ou lors de tentatives de réessai en cas de problèmes). Les exécutions de vérification simples sans changement d'état ne déclenchent aucun gestionnaire d'alertes.

Avec l'option «Global settings > Alert handlers > Types of events that are being processed > All check executions!», vous pouvez configurer exactement cela. Chaque exécution d'un check peut potentiellement déclencher un gestionnaire d'alertes. Vous pouvez, par exemple, utiliser cette fonctionnalité pour transférer des données de la supervision active vers d'autres systèmes.

Soyez prudent avec ce paramètre ! Le lancement de processus et l'appel de scripts consomment beaucoup de ressources CPU. Checkmk peut facilement exécuter 1 000 contrôles par seconde, mais Linux ne pourrait certainement pas gérer 1 000 scripts de gestionnaires d'alertes par seconde.

Afin de rendre cela possible de manière utile, Checkmk offre la possibilité d'écrire des gestionnaires d'alertes sous forme de fonctions Python, qui s'exécutent alors en ligne, sans création de processus. Ces gestionnaires en ligne peuvent être enregistrés dans le même répertoire que les scripts de gestionnaires normaux. L'exemple fonctionnel suivant montre la structure d'un gestionnaire en ligne :

~/local/share/check_mk/alert_handlers/foo
#!/usr/bin/python
# Inline: yes

# Do some basic initialization (optional)
def handle_init():
    log("INIT")

# Called at shutdown (optional)
def handle_shutdown():
    log("SHUTDOWN")

# Called at every alert (mandatory)
def handle_alert(context):
    log("ALERT: %s" % context)
Copier le contenu du fichier dans le presse-papiers
Contenu du fichier copié avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Ce script n'a pas de fonction centrale, il définit simplement trois fonctions, bien que seule la fonction handle_alert() soit requise. Celle-ci est appelée après chaque exécution de check et, dans son argument context, reçoit un dictionnaire Python contenant des variables telles que "HOSTNAME", "SERVICEOUTPUT", etc. Celles-ci représentent les variables d'environnement que les gestionnaires normaux reçoivent également, mais ici sans le préfixe ALERT_. L'exemple ci-dessus peut être utilisé pour afficher le contenu de context.

Toutes les sorties générées par la fonction auxiliaire log() sont enregistrées dans ~/var/log/alert.log. Les deux variables globales omd_root et omd_site sont basées respectivement sur le répertoire personnel et le nom de l’instance Checkmk.

Les fonctions handle_init() et handle_shutdown() sont appelées par Checkmk lors du démarrage ou de l’arrêt du noyau de supervision et permettent une initialisation, par exemple lors de l’établissement d’une connexion à une base de données.

Informations supplémentaires :

  • Veuillez noter la fonction # Inline: yes à la deuxième ligne.

  • Le noyau du processeur doit être redémarré après chaque modification du script (omd restart cmc).

  • import Les instructions sont autorisées.

  • Les alert helpers Checkmk appellent vos fonctions de manière synchrone. Assurez-vous qu'aucun temps d'attente ne se produise !

8. Exécution à distance sous Linux

8.1. Principes de base

Chaque version de Checkmk comprend un gestionnaire d'alertes intégré qui permet l'exécution fiable de scripts sur les systèmes Linux surveillés. Les principales caractéristiques de cette solution sont les suivantes :

  • Les scripts sont lancés via SSH avec une restriction d'instruction.

  • Aucune instruction arbitraire ne peut être utilisée, mais uniquement celles que vous avez définies.

  • Tout cela peut être mis en œuvre à l’aide de la boulangerie d’agents.

Le gestionnaire d'alertes à distance Linux se compose des éléments individuels suivants :

  • Le gestionnaire d'alertes « linux_remote » (Exécuter un script sur un système Linux distant) sur le serveur Checkmk.

  • Le script « mk-remote-alert-handler » sur le système cible.

  • Les scripts (« gestionnaires à distance ») que vous avez écrits sur le système cible.

  • Les entrées dans .ssh/authorized_keys pour les utilisateurs du système cible qui les exécuteront.

  • Les règles dans Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux) qui génèrent des clés SSH.

  • Le gestionnaire d'alertes qui fait appel à linux_remote.

8.2. Configuration

Supposons que l'on souhaite exécuter le script /etc/init.d/foo restart sur le système Linux myserver123 chaque fois que le service Process FOO atteint un niveau critique (ce que nous avons déjà configuré). Procédez comme suit :

Codage du gestionnaire distant

Écrivez ensuite le script à exécuter sur le système cible. Comme nous travaillons avec la boulangerie d’agents, installez le script sur le serveur Checkmk (et non sur le système cible !). Le répertoire approprié est ~/local/share/check_mk/agents/linux/alert_handlers. Ici aussi, le commentaire de la deuxième ligne fournit un titre pour la sélection dans l’interface utilisateur :

~/local/share/check_mk/agents/Linux/alert_handlers/restart_foo
#!/bin/bash
# Restart FOO service

/etc/init.d/foo restart || {
    echo "Could not restart FOO."
    exit 2
}
Copier le contenu du fichier dans le presse-papiers
Contenu du fichier copié avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Rendez le script exécutable :

OMD[mysite]:~$ cd local/share/check_mk/agents/linux/alert_handlers
OMD[mysite]:~/local/share/check_mk/agents/linux/alert_handlers$ chmod +x restart_foo
Copier les instructions dans le presse-papiers
Les instructions ont été copiées avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Notre script d'exemple est conçu de telle sorte qu'en cas d'erreur, il se termine par un code 2 afin que le gestionnaire d'alertes l'évalue comme une «CRIT».

Préparation du package d'agent avec le gestionnaire

Nous allons ici décrire la procédure avec la boulangerie d’agents. Vous trouverez plus bas des conseils pour une installation manuelle.

Définissez une règle sous «Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux)». Dans les propriétés, vous pouvez voir le gestionnaire distant Restart FOO service que vous venez de définir. Sélectionnez-le pour l'installation :

alert handlers install remote

Une fois que vous l'avez enregistrée, la règle apparaîtra dans la liste : une paire de clés SSH permettant d'appeler le gestionnaire a été générée automatiquement et son empreinte apparaîtra dans la règle. L'empreinte elle-même a été raccourcie pour s'adapter à la largeur de cette capture d'écran :

alert handlers install remote2

La clé publique est destinée à l'agent. La clé privée sera requise ultérieurement par le serveur Checkmk afin qu'un script installé de cette manière puisse être appelé sans avoir à saisir un mot de passe.

Il est également possible d'utiliser un autre utilisateur en tant qu'root, bien sûr uniquement s'il dispose des droits appropriés pour l'action requise. L'agent Checkmk n'installera la clé SSH que sur les systèmes où cet utilisateur existe déjà.

Création de l'agent

Créez maintenant de nouveaux agents avec l'button bake agents. Dans la liste des agents prêts, une entrée devrait désormais apparaître, dans laquelle votre gestionnaire distant et votre clé SSH sont visibles. La capture d'écran a également été raccourcie ici. Cette fois-ci, en fonction du nombre de paquets pouvant être téléchargés :

alert handlers baked handler

Installation de l'agent

Ensuite, installez le paquet RPM ou DEB sur votre système cible (l'installation de l'archive TGZ ne permet pas de réaliser la configuration de la clé SSH et est donc incomplète). L'installation entraîne les conséquences suivantes :

  • Votre script de gestionnaire distant sera installé.

  • Le programme auxiliaire mk-remote-alert-handler sera installé.

  • Pour les utilisateurs sélectionnés (ici root), une entrée sera créée dans le fichier authorized_keys afin de permettre l'exécution du gestionnaire.

  • Le répertoire .ssh et le fichier authorized_keys seront créés si nécessaire.

Avec une installation via DEB, cela ressemblera à ceci :

root@myserver123:~# dpkg -i check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb
Selecting previously unselected package check-mk-agent.
(Reading database ... 515080 files and directories currently installed.)
Preparing to unpack ...check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb ...
Unpacking check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Setting up check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Reloading xinetd...
 * Reloading internet superserver configuration xinetd                            [ OK ]
Package 9d3ab34905da4934: adding SSH keys for Linux remote alert handlers for user root...
Copier les instructions dans le presse-papiers
Instruction(s) copiée(s) avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Un coup d'œil à la configuration SSH pour root révèle :

root@myserver123:~# cat /root/.ssh/authorized_keys
command="/usr/bin/mk-remote-alert-handler restart_foo",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAACAQCqoDVNFEbTqYEmhSZhUMvRy5SqGIPp1nE+EJGw1LITV/rej4AAiUUBYwMkeo5aBC6VOXkq78CdRuReSozec3krKkkwVbgYf98Wtc6N3WiljS85PLAVvPadJiJCkXFctbxyI2xeF5TQ1VKDRvzbBjXE9gjTnLWbPy77RC8SVXLoOQgabixpWQquIIdGyccPsWGTRgeI7Ua0lgWZQUJt7OIKQ0X7Syv2VHKJNqtW28IWu8y2hBEY/TERip5EQoNT/VclhHqjDG2y3F45PswcXD5in6y30EnfHGcwk+PD6fgp7jPGbO2+QBUwYgW67GmRpbaVQ97CqXFJvORNF+C6+O8DNweyH3ogspjfKvM7eN+M4NIJzjMRyNBMzqF3VmrMeqpzRjfFj2BS/8UbXGgHzZRapwrK3+GXX1pG49n77cIs+GWos9xb1DxX1pEu2tgQwRBBhYcTkk2eKkH18LKzFUyObxtQmf40C24cdQOp6USbwzsniqehsLIHH2unQ7bW6opF/GiaEjZamGbgsPOe8rmey5Vcd//e8cS+OsmcPZNybsTJpBeHpes+5bw0e1POw9GD9qptylrQLYIO5R467Ov8YlRFgYKyaDFHD40j5/JHPzmtp4vjH8Si7YZZOzvTRgBYEoEgbLS5dgdr/I5ZMRKfDPCpRUbGhp9kUEdGX99o5Q== mk-remote-alert-handler-9d3ab34905da4934
Copier les instructions dans le presse-papiers
Instruction(s) copiée(s) avec succès dans le presse-papiers !
L'accès en écriture au presse-papiers a été refusé !

Sachez que votre système peut être configuré de telle sorte qu'un accès SSH en tant qu'root ne soit généralement pas possible. Dans ce cas, vous pouvez passer par un autre utilisateur et y utiliser sudo, qui est configuré de manière à ce que l'instruction souhaitée puisse être exécutée sans mot de passe.

Appel du gestionnaire à l'aide d'une règle

Nous avons presque atteint notre objectif. L'agent est prêt. Il ne manque plus qu'une règle pour appeler effectivement le gestionnaire d'alertes. La procédure est celle décrite au début de cet article et s'effectue par la création d'une règle appropriée. Cette fois-ci, choisissez Linux via SSH comme gestionnaire, saisissez l'utilisateur pour lequel la clé SSH doit être installée, puis sélectionnez votre gestionnaire distant :

alert handlers rule foo

Définissez également une condition raisonnable dans la règle, sinon une connexion SSH sera tentée à chaque alerte de service !

Test

Lorsque, par exemple, vous définissez maintenant manuellement le service concerné sur CRIT, vous verrez rapidement apparaître dans l'historique du service :

alert handlers foo failing

Bien entendu, si aucun service foo n'existe, alors /etc/init.d/foo restart ne peut pas non plus fonctionner. On constate toutefois que cette instruction a été traitée et que le statut d'erreur a été correctement signalé. De même, Checkmk a déclenché une notification qui a été stoppée par un gestionnaire d'alertes.

Le message « Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts. » est d'ailleurs inoffensif et n'apparaît qu'au premier contact avec l'ordinateur hôte. Pour éviter l'échange manuel fastidieux de la clé de l'ordinateur hôte, SSH est appelé avec « -o StrictHostKeyChecking=false ». Lors de la première connexion, la clé sera enregistrée pour une utilisation future.

8.3. Configuration sans boulangerie d’agents

Bien sûr, la préparation manuelle d’un agent fonctionne également. Dans ce cas, nous vous recommandons d’effectuer la procédure de boulangerie d’agents sur un système de test, puis d’examiner les données pertinentes et de les reproduire manuellement sur votre propre système. Vous trouverez ici une liste des chemins d’accès aux fichiers.

Dans ce cas précis, il est également important que vous créiez dans la boulangerie d’agents une règle pour l'installation du gestionnaire distant, car c'est dans cette règle que les clés SSH seront générées pour l'accès et pour l'utilisation par le gestionnaire d'alertes ! La clé publique pour l'installation dans authorized_keys se trouve dans le fichier de configuration ~/etc/check_mk/conf.d/wato/rules.mk (ou dans un sous-dossier de rules.mk).

9. Fichiers et répertoires

9.1. Chemins d'accès sur le serveur Checkmk

Chemin d'accès Fonction

~/var/log/alerts.log

Fichier journal contenant tous les événements pertinents pour le gestionnaire d'alertes (enregistrés par l'alert helper).

~/var/log/cmc.log

Fichier journal pour le noyau du processeur. Certaines informations relatives au gestionnaire d'alertes y sont également stockées.

~/local/share/check_mk/alert_handlers/

Enregistrez ici vos gestionnaires d'alertes personnalisés.

~/var/check_mk/core/history

C'est ici que le fichier journal de l'historique de la supervision est stocké et évalué par le noyau du processeur.

~/local/share/check_mk/agents/linux/alert_handlers/

Gestionnaires d'alertes distants à exécuter sur les systèmes Linux.

9.2. Chemins d'accès sur l'ordinateur hôte Linux sous supervision

Chemin d'accès Fonction

/usr/bin/mk-remote-alert-handler

Script auxiliaire pour l'exécution des gestionnaires à distance.

/usr/lib/check_mk_agent/alert_handlers/

Gestionnaires à distance que vous avez écrits.

/root/.ssh/authorized_keys

Configuration SSH pour l'utilisateur root.

~harri/.ssh/authorized_keys

Configuration SSH pour un utilisateur harri.
Last modified: Thu, 05 Feb 2026 14:58:34 GMT via commit 4776cff3b
Sur cette page