Checkmk
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

Dans Checkmk, vous pouvez surveiller votre infrastructure de nombreuses façons différentes. La supervision à l'aide d'agents ou de SNMP ne sont que deux méthodes parmi tant d'autres. La supervision à l'aide d'agents n'est qu'une méthode parmi tant d'autres. Toutes les méthodes basées sur des agents ont en commun le fait qu'elles ne signalent que les états tels que l'ordinateur hôte les perçoit de l'intérieur, mais vous connaissez sans doute certains services qui ne peuvent être surveillés efficacement que depuis l'extérieur. Il est certes possible de vérifier si le serveur web fonctionne depuis l'intérieur, mais l'accessibilité et les temps de réponse pour l'utilisateur réel ne peuvent pas être déterminés de cette manière.

Checkmk propose ses contrôles actifs pour ce type de situations. Ces contrôles vous permettent de surveiller les services réseau directement et facilement depuis l’extérieur, et d’afficher les informations dans votre système de supervision. Les contrôles actifs sont de petits programmes ou scripts qui effectuent une connexion à un service sur le réseau ou sur l’internet, puis fournissent à l’utilisateur les données de supervision. Bon nombre des scripts et programmes que vous trouverez dans Checkmk proviennent à l’origine de monitoring-plugins.org. Comme Checkmk est généralement compatible avec Nagios, vous pouvez également utiliser tous les plugins qui fonctionnent sous Nagios.

Lorsque vous intégrez de tels plugins de supervision, gardez à l’esprit l’objectif principal des contrôles actifs : en termes de supervision de bout en bout, ils sont censés vérifier l’accessibilité, le temps de réponse ou l’état de réponse d’un service accessible via le réseau sur l’ordinateur hôte surveillé. Checkmk propose toute une gamme de contrôles efficaces pour de nombreuses autres tâches de supervision. Vous trouverez un aperçu dans l’article Développer des extensions pour Checkmk.

Les plus importants de ces programmes et scripts sont disponibles dans Checkmk directement via l’interface web. En voici une petite sélection :

2. Mise en place de checks actifs

2.1. Configuration des checks actifs réguliers

Dans l'Setup, vous pouvez — comme déjà mentionné ci-dessus — configurer les contrôles les plus importants et les plus fréquemment utilisés directement dans l'interface web. Pour ce faire, ouvrez Setup > Services > HTTP, TCP, Email. Vous y trouverez les jeux de règles permettant de configurer ces contrôles :

List of rulesets for active checks.

La plupart des options des jeux de règles sont intuitives. Toutefois, si quelque chose n’est pas clair, vous pouvez également consulter l’aide en ligne pour obtenir des explications sur les nombreuses options.

2.2. Attribution de vérifications actives à un ordinateur hôte

Pour certaines règles, il est nécessaire de spécifier une adresse IP ou un nom de domaine dans les options. Dans de nombreux cas, il est possible de laisser cette option vide afin que le nom de domaine ou son adresse IP soit utilisé. De cette manière, vous pouvez facilement utiliser une seule règle pour fournir une vérification active à tout un groupe d’ordinateurs hôtes. Assurez-vous donc toujours — notamment à l’aide de l’aide en ligne mentionnée précédemment — si cette option est disponible dans le jeu de règles concerné. Vous pourriez ainsi vous épargner beaucoup de travail de configuration.

Check HTTP web service Il s’agit d’une vérification fréquemment utilisée pour surveiller de nombreux paramètres des serveurs web, tels que la validité des certificats, le temps de réponse, le code de réponse ou la recherche de chaînes de caractères dans les pages web fournies. Vous trouverez cette vérification sous Networking > Check HTTP web service. Supposons que vous souhaitiez surveiller la validité des certificats de tous les serveurs web de votre infrastructure, garantir des temps de réponse inférieurs à une seconde et un code d’état de 200, mais que vous ne souhaitiez pas créer des dizaines, voire des centaines de règles pour cela :

Example of a configuration of the 'Check HTTP web service' rule.
Tip

Pourquoi, avec Check certificates, existe-t-il un autre check actif pour les certificats ?

La vérification Check HTTP web service mentionnée ci-dessus effectue toujours une requête HTTP complète, ce qui limite son utilisation aux serveurs web. En revanche, son exécution est très efficace ; elle peut effectuer une série de vérifications avec une seule requête HTTP.

En comparaison, Check certificates vérifie uniquement la configuration de la connexion TLS et les certificats. Cette vérification peut donc également s'appliquer à d'autres services sécurisés par TLS, tels que IMAP/S. Elle permet également d'examiner les certificats de manière beaucoup plus détaillée, par exemple pour des noms de domaine spécifiques stockés via Server Name Indication (SNI).

Pour appliquer la vérification que vous venez de configurer à tous les ordinateurs hôtes concernés à l’aide d’une seule règle, réfléchissez d’abord à la meilleure façon de remplir le champ « Conditions ». Dans l’exemple suivant, nous utilisons la fonction « Labels » et ajoutons l’étiquette « webprotocol:https » à tous nos serveurs web. Avec une telle étiquette, vous pouvez créer une règle et définir le champ « Conditions » sur cette étiquette :

Restriction of the rule via a host label on the web server.

Une fois que vous avez activé la règle que vous venez de créer, recherchez dans le menu Monitor le nom du service Basic webserver health que vous venez de définir. Dans l'exemple suivant, vous pouvez voir les hôtes auxquels l'étiquette a été appliquée en conséquence.

The services generated by the rule in the monitoring.

Important : veuillez noter que pour les checks actifs, ce n’est pas seulement la première règle à laquelle les conditions s’appliquent qui est évaluée, mais également toutes les règles dans lesquelles les conditions pour un ordinateur hôte s’appliquent. C’est la seule façon de créer plusieurs services actifs sur un ordinateur hôte.

2.3. Intégration d'autres plugins compatibles Nagios

Bien entendu, Checkmk ne se limite pas aux contrôles actifs que vous pouvez trouver sous forme de jeux de règles dans l’interface web. En plus de ces plugins de supervision, vous en trouverez de nombreux autres sur votre site. Afin de simplifier l’exemple d’aperçu présenté ici, seules certaines lignes sont affichées dans l’exemple de sortie suivant :

OMD[mysite]:~$ ll ~/lib/nagios/plugins/
total 2466
-rwxr-xr-x 1 root root   56856 Feb  3 00:45 check_dig
-rwxr-xr-x 1 root root    6396 Feb  3 00:45 check_flexlm
-rwxr-xr-x 1 root root    6922 Feb  3 00:45 check_ircd
-rwxr-xr-x 1 root root   60984 Feb  3 00:45 check_ntp_peer
-rwxr-xr-x 1 root root   78136 Feb  3 00:45 check_snmp
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é !

Chacun de ces plugins de supervision propose également une option d’aide (-h), qui vous permet d’en savoir plus sur l’utilisation du plugin concerné sans avoir à vous rendre sur le site web monitoring-plugins.org.

Dans Setup > Services > Other services, Checkmk propose l'ensemble de règles spécial Integrate Nagios plugins afin de faciliter l'utilisation de ces plugins. Les deux options les plus importantes ici sont la spécification d'une description de service et d'une ligne de commande. Cette dernière peut être écrite comme si vous vous trouviez déjà dans le répertoire approprié :

Rule for the integration of Nagios plug-ins.

Notez que les macros indiquées ci-dessus, telles que $HOSTNAME$ ou $HOSTADDRESS$, sont également disponibles ici. Comme toujours, vous trouverez la liste de toutes les macros disponibles dans l'aide en ligne. Après avoir activé les modifications, vous pouvez voir le nouveau service sur l'ordinateur hôte attribué :

The service generated by the rule in the monitoring.

Utilisation de vos propres plugins

Dans certains cas, vous aurez déjà écrit vos propres plugins et souhaiterez désormais les utiliser dans Checkmk. Dans ce cas, la procédure est en grande partie identique. La seule exigence est que le plugin soit compatible avec Nagios. Cela inclut une sortie sur une seule ligne contenant les détails de l'état et un code de sortie décrivant cet état. Ce code doit être 0 pour OK, 1 pour WARN, 2 pour CRIT ou 3 pour UNKNOWN.

Un bref exemple illustrant cette syntaxe très simple présente le script suivant, que vous pouvez créer par exemple dans le sous-répertoire ~/tmp du répertoire d'instances :

~/tmp/myscript.sh
#!/bin/bash
echo "I am a self written check and I feel well."
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é !

En une seule opération, placez le plugin dans le chemin d'accès local de votre instance et rendez-le exécutable :

OMD[mysite]:~$ install -m755 ~/tmp/myscript.sh ~/local/lib/nagios/plugins/
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é !

La suite de la procédure est alors identique à celle des autres plugins créés via le jeu de règles « Integrate Nagios plugins », de sorte que vous puissiez voir le nouveau service à la fin :

The service generated by the custom plug-in in monitoring.

3. Particularités des checks actifs

Les services créés par des checks actifs se comportent différemment à certains égards par rapport aux autres services. Ainsi, les services d'un check actif…​

  • … continuent d'être checkés même si un ordinateur hôte est inDOWN

  • … s’exécutent indépendamment des autres services (passifs). Cela vous permet également de définir votre propre intervalle.

  • …​ sont toujours exécutés par le serveur Checkmk. Les MRPE constituent une exception, car ils sont exécutés directement sur un ordinateur hôte.

  • … ne sont pas intégrés via la reconnaissance du service, mais sont générés automatiquement.

4. Exécution de checks actifs sur un ordinateur hôte (MRPE)

Supposons que vous effectuiez la supervision d'un hôte A (par exemple, un serveur web) depuis votre instance Checkmk, lequel accède à son tour à des services hébergés sur l'hôte B (par exemple, une base de données). La supervision des services sur l’hôte B directement depuis l’instance Checkmk sera très probablement faussée par d’autres temps d’exécution de paquets, etc., et ne donnera donc aucune indication précise sur le comportement de l’accessibilité depuis l’hôte A en fonctionnement. Il est ici pratique de disposer d’un plugin Nagios exécuté depuis l’agent de l’hôte surveillé (ici A), qui vérifie directement les services sur l’hôte B.

Pour exécuter un plugin Nagios classique sur un ordinateur hôte en période de supervision, nous fournissons le Remote Plugin Executor de MK (en abrégé : MRPE). Selon que vous souhaitiez exécuter un tel plugin sur un système de type Unix ou sur un système Windows, placez-le à l'emplacement approprié dans le répertoire d'installation de l'agent correspondant. De plus, vous aurez besoin d'un fichier de configuration qui détermine comment le plugin doit être exécuté et à quoi ressemble la ligne de commande spécifique pour l'appel.

Vous trouverez des instructions détaillées dans les articles correspondants sur Linux et Windows.

5. Fichiers et répertoires

Chemin d'accès au fichier Description

~/lib/nagios/plugins/

Vous trouverez ici tous les plugins fournis avec Checkmk. Aucune distinction n'est faite entre les plugins développés par monitoring-plugins.org et ceux développés spécifiquement pour Checkmk.

~/local/lib/nagios/plugins/

Vous pouvez stocker vos propres plugins ici. Ils sont alors chargés dynamiquement et seront conservés même après une mise à jour de l’instance Checkmk.


Last modified: Mon, 15 Dec 2025 20:45:15 GMT via commit 0f6809b27
Sur cette page