Vérification locales (local checks)

Un check local peut être écrit dans n'importe quel langage de programmation pris en charge par l'ordinateur hôte cible. Le script doit être conçu de manière à ce que chaque check génère une ligne d'état composée de quatre parties. Voici un exemple :

Les quatre parties sont séparées par des espaces et ont les significations suivantes :

Si vous avez des doutes quant à un résultat possible, vous pouvez simplement le tester en écrivant un petit script avec l'instruction echo. Insérez le résultat que vous souhaitez tester dans l'instruction echo. Notre exemple utilise des guillemets doubles à l'extérieur, car les variables à l'intérieur (variables d'environnement et celles définies dans le script) sont évaluées. Par conséquent, vous devez encadrer les guillemets du nom du service avec \ afin que ces caractères ne soient pas interprétés par le shell comme le début et la fin d'une chaîne (et donc supprimés de la sortie) :

Pour les ordinateurs hôtes Windows, un tel script ressemblera beaucoup à ceci :

Les deux scripts produisent le même résultat en sortie :

Pour Checkmk, seule cette sortie est pertinente, et non la manière dont vous l'avez générée.

À propos, vous pouvez écrire autant de sorties que vous le souhaitez dans un script. Chaque ligne de sortie aura son propre service créé dans Checkmk. Par conséquent, aucun caractère de nouvelle ligne n'est autorisé dans la sortie, à moins qu'ils ne soient masqués, par exemple pour une sortie sur plusieurs lignes dans Checkmk.

Pour savoir comment vérifier si le script local sera correctement exécuté par l'agent, veuillez vous reporter à la section Analyse des erreurs.

Une fois le script écrit, il peut être distribué aux ordinateurs hôtes concernés. Le chemin d'accès utilisé dépendra du système d'exploitation. Vous trouverez une liste des chemins d'accès dans la section Fichiers et répertoires ci-dessous.

N'oubliez pas de rendre le script exécutable sur les systèmes de type Unix. Le chemin d'accès indiqué dans cet exemple concerne Linux (paquet d'agent avec les paramètres par défaut) :

Si vous utilisez la boulangerie d’agents, le script peut être distribué à l'aide d'une procédure basée sur des règles. Vous trouverez plus d'informations sur la création de règles dans le chapitre « Distribution via la boulangerie d’agents ».

À chaque invocation de l’agent Checkmk, le check local contenu dans le script sera également exécuté et ajouté à la sortie de l’agent. La reconnaissance du service fonctionne également automatiquement, comme pour les autres services :

Une fois le service ajouté à la supervision et les modifications activées, la mise en place du service que vous avez créé vous-même à l’aide d’un check local sera terminée. Si un problème survient lors de la reconnaissance du service, l’analyse des erreurs peut vous aider.

Vous pouvez également définir des métriques dans un check local. La syntaxe la plus concise pour les données de métriques est la suivante :

où «value» correspond à la valeur actuelle.

La syntaxe complète pour les données métriques est la suivante :

Ici, warn et crit définissent les valeurs seuils (supérieures). Pour que ces valeurs seuils s’affichent dans le graphique, le calcul dynamique doit être activé (état P). L’état est alors calculé à l’aide de Checkmk. Les derniers paramètres spécifiés pour min et max fixent la plage de valeurs.

Un exemple complet pourrait donc se présenter comme suit :

Les valeurs sont séparées par des points-virgules. Si une valeur n’est pas requise, le champ reste vide ou est omis à la fin, comme dans les exemples suivants pour warn, crit et max :

Les définitions de métriques pour les checks locaux ne diffèrent pas de celles des autres types de checks. Au final, vous disposez de trois options pour attribuer des unités et des noms faciles à comprendre aux métriques :

Vous pouvez également générer plusieurs métriques. Dans les définitions, celles-ci sont séparées par le caractère « pipe » (|), par exemple comme ceci :

Sur les ordinateurs hôtes Windows, vous devez faire précéder ces barres verticales dans le script d'un accent circonflexe (^) afin que ces barres apparaissent également dans la sortie :

Une sortie complète avec deux métriques ressemblera alors à ceci :

Une fois que vous aurez également ajouté le nouveau service à la supervision, vous verrez, dans la liste des services, le texte correspondant aux détails de l'état dans le champ « Summary ». En cliquant sur le service, vous afficherez la page contenant ses détails. Les métriques sont affichées dans le champ « Details », et en dessous, vous verrez les graphiques du service générés automatiquement par Checkmk :

Dans les sections précédentes, vous avez appris à fournir des valeurs pour les métriques et à les utiliser pour générer des graphiques. La suite logique consiste désormais à utiliser les valeurs de seuil supplémentaires transmises pour un calcul dynamique de l'état du service. C'est exactement ce que permet Checkmk afin de rendre le traitement des données reçues cohérent avec bon nombre des états générés via les plugins.

Si, dans le premier champ de la sortie, qui détermine l'état, vous transmettez la lettre P au lieu d'un nombre, l'état du service sera calculé sur la base des valeurs seuils transmises. En plus de la valeur réelle, les valeurs seuils transmises sont alors également affichées sous forme de lignes jaunes et rouges dans le graphique.

Le résultat ressemblerait alors à ceci :

… et l'affichage dans une vue de service comme ceci :

Cet affichage diffère du précédent sur deux points :

Certains paramètres ont non seulement des valeurs seuils supérieures, mais aussi des valeurs seuils inférieures. L'enregistrement de l'humidité en est un exemple. Dans de tels cas, la check local offre la possibilité de passer deux valeurs seuil pour chacun des états « WARN » et « CRIT ». Celles-ci sont séparées par deux points et représentent respectivement les valeurs seuils inférieures et supérieures.

Dans la syntaxe générale, cela se présente comme suit :

… dans l'exemple ci-dessous :

… et dans l'affichage d'une vue de service comme ceci :

Si vous ne vous intéressez qu'aux valeurs de seuil inférieures, omettez les champs correspondant aux valeurs de seuil supérieures :

Avec cette sortie, vous spécifiez que le service doit passer à l'état « WARN » si la valeur est inférieure à 40 et à l'état « CRIT » si elle est inférieure à 30 : le service recevra donc l'état « WARN » si la valeur spécifiée est 37.

L'option permettant de répartir une sortie sur plusieurs lignes est également disponible. Comme Checkmk fonctionne sous Linux, vous pouvez utiliser la séquence d'échappement '\n' pour forcer un saut de ligne. Même si, en raison du langage de script, la barre oblique inversée elle-même doit être masquée, elle sera correctement interprétée par Checkmk :

Dans les détails du service, ces lignes supplémentaires seront visibles sous l'Summary :

Sous Linux ou un autre système d'exploitation de type Unix, tout plugin peut être exécuté de manière asynchrone. Pour une check local, la configuration nécessaire est très similaire à celle d'un plugin. Pour ce faire, créez un sous-répertoire portant le nom du nombre de secondes pendant lesquelles vous souhaitez que la sortie soit mise en cache et placez votre script dans ce sous-répertoire.

Dans l'exemple suivant, le check local ne sera exécuté que toutes les 10 minutes (600 secondes) :

Les données mises en cache sont écrites dans un répertoire de cache.

Pour un service fournissant des données mises en cache, les informations spécifiques au cache sont ajoutées à la vue du service :

Sous Windows, la configuration est également similaire à celle d'un plugin d'agent. Au lieu d'utiliser un sous-répertoire spécial comme sous Linux et autres, les options sont définies dans un fichier de configuration :

Comme vous pouvez le voir ci-dessus, sous Windows, vous pouvez configurer l'exécution asynchrone (avec async) et l'intervalle de temps (avec cache_age) séparément.

Sinon, sous Windows, vous pouvez également effectuer la configuration dans la boulangerie d’agents.

Si vous rencontrez des problèmes avec un script que vous avez écrit vous-même, vous devriez vérifier les sources d'erreur potentielles suivantes :

Si le script lui-même est correct, l'agent peut être exécuté sur l'ordinateur hôte. Avec les systèmes d'exploitation de type Unix tels que Linux, BSD, etc., l'instruction ci-dessous est disponible. L'option `-A` permet de spécifier le nombre de lignes supplémentaires à afficher après un résultat positif. Ce nombre peut être personnalisé en fonction du nombre de lignes de sortie attendues :

Dans la dernière ligne, vous pouvez reconnaître un service mis en cache grâce aux informations « cached » qui précèdent, indiquant l'heure Unix actuelle et l'intervalle d'exécution en secondes.

Sous Windows, vous pouvez obtenir un résultat très similaire avec PowerShell et le Cmdlet Select-String, comme avec l’instruction grep sous Linux. Dans l’instruction suivante, les deux chiffres situés après le paramètre Context déterminent le nombre de lignes à afficher avant et après le résultat :

En guise de dernière étape, le traitement de la sortie du script peut également être testé sur le serveur Checkmk à l'aide de l'instruction « cmk » — une fois pour la reconnaissance du service :

… ainsi que le traitement de la sortie du service à l'aide d'une instruction similaire :

Pour ces deux instructions, nous avons raccourci la sortie en supprimant les lignes non pertinentes pour ce thème.

Vous pouvez également ouvrir la liste des services de l'ordinateur hôte dans la supervision, puis accéder à l'Check_MKs sur le service et à la colonne « Icons ». Vous pouvez alors sélectionner l'entrée de menu « Download agent output » pour récupérer un fichier texte contenant la sortie complète de l'agent.

Si des erreurs surviennent lors d'un check local, Checkmk les identifiera dans la sortie du service. Cela s'applique également aux métriques erronées, aux informations fausses ou incomplètes dans la sortie du script, ou à un état non valide. Ces messages d'erreur devraient vous aider à identifier rapidement les erreurs dans un script.

Vous stockez les contrôles locaux dans ces répertoires. Les contrôles locaux peuvent être n'importe quel fichier exécutable.

Les données mises en cache de sections individuelles, y compris la section « local », sont stockées ici et rattachées à l'agent à chaque exécution tant que les données sont valides.