Checkmk en ligne de commande

Lors de l'administration de Checkmk, à quelques exceptions près, vous n'avez jamais besoin de travailler en tant qu'utilisateur « root ». Dans cet article, nous partirons généralement du principe que vous êtes connecté en tant que utilisateur de l'instance. Pour ce faire, vous pouvez par exemple utiliser la commande suivante :

Il est également possible de réaliser un login direct via SSH pour accéder à une instance sans passer par root. Étant donné que l'utilisateur de l'instance est un utilisateur Linux « tout à fait normal », il vous suffit de lui attribuer un mot de passe (ce qui nécessite l'autorisation d'root, une seule fois, pour la configuration) :

Par la suite, un login SSH directement depuis un autre ordinateur devrait être possible (les utilisateurs Windows utiliseront de préférence PuTTY pour cela). Sous Linux, ce login s'effectue simplement à l'aide de l'instruction ssh :

Lors du premier login, un avertissement concernant une clé hôte inconnue s'affichera probablement. Si vous êtes certain qu'aucun pirate n'a pris le contrôle de l'adresse IP de votre système d'exploitation à ce moment précis, vous pouvez simplement le vérifier à l'aide de la commande « yes ».

Vous pouvez également utiliser la ligne de commande sur la Checkmk Appliance. La procédure à suivre est expliquée dans un article dédié.

Afin de limiter au maximum les problèmes, notamment ceux liés aux distributions individuelles ou aux configurations différentes des systèmes d’exploitation, le système Checkmk veille à ce que l’utilisateur de l’instance – ainsi que tous les processus de supervision – disposent toujours d’un environnement clairement défini. Outre le répertoire personnel et les autorisations, les variables d’environnement jouent un rôle important.

Entre autres, lors de la connexion en tant qu’utilisateur de l’instance, les variables suivantes seront définies ou modifiées. Ces variables sont disponibles pour être utilisées dans tous les processus s’exécutant au sein de l’instance. Cela s’applique également aux scripts qui sont indirectement invoqués par ces processus (par exemple, les scripts de notification propres à un utilisateur).

L'instruction « env » vous permet d'afficher toutes les variables d'environnement ; l'ajout de « | sort » à cette instruction permet d'organiser la liste de manière un peu plus claire :

Sous Linux, l'environnement est un attribut d'un processus. Chaque processus possède ses propres variables, qu'il transmet automatiquement aux sous-processus. Ces derniers démarrent initialement avec les mêmes variables héritées, mais peuvent également les modifier.

Avec l'instruction `env`, vous ne pouvez toujours consulter que l'environnement du shell actuel. Si vous soupçonnez une erreur dans l’environnement d’un processus particulier, une petite astuce vous permet néanmoins d’afficher la liste de son environnement. Pour cela, vous n’avez besoin que de l’ID du processus (PID). Vous pouvez l’identifier à l’aide, par exemple, de ps ax, pstree -p ou top. Vous pouvez alors accéder directement au fichier d’environs du processus via le système de fichiers /proc. Voici, à titre d’exemple, une instruction adaptée pour le PID 13222 :

Si vous avez besoin de variables définies par l'utilisateur pour vos propres scripts ou d’autres logiciels à exécuter dans l’instance, enregistrez-les dans le fichier ~/etc/environment, spécialement créé à cet effet. Toutes les variables définies ici seront disponibles partout dans l’instance :

Si vous souhaitez personnaliser votre shell (invite de commande ou autres éléments), vous pouvez le faire comme d'habitude dans le fichier .bashrc. Les variables d'environnement appartiennent toutefois à ~/etc/environment, ce qui garantit qu'elles seront disponibles pour tous les processus.

Rien ne vous empêche non plus d'avoir votre propre fichier .vimrc si vous aimez travailler avec Vim.

Le graphique suivant présente les répertoires les plus importants d'une installation Checkmk avec une instance nommée mysite et une instance <version> appelée, par exemple, 2.4.0p24.cee :

Le répertoire /omd constitue la base de cette structure. Tous les fichiers de Checkmk se trouvent ici, sans exception. /omd est en fait un lien symbolique vers /opt/omd, tandis que les données physiques réelles se trouvent dans /opt – mais tous les chemins d’accès aux données dans Checkmk utilisent toujours /omd.

Il est important de distinguer les données (surlignées en jaune) et les logiciels (en bleu). Les données de l'instance se trouvent à l'adresse /omd/sites/, et les logiciels installés à l'adresse /omd/versions/.

Comme tout utilisateur Linux, l’utilisateur de l’instance dispose également d’un répertoire personnel, que nous appelons le répertoire d’instances. Si votre instance s’appelle mysite, elle se trouve dans /omd/sites/mysite/. Comme d’habitude sous Linux, le shell abrège son propre répertoire personnel par un tilde (~) (ou un tiret). Comme vous vous trouverez effectivement dans ce répertoire immédiatement après un login, le tilde apparaît automatiquement dans l’invite de commande :

Les sous-répertoires du répertoire d'instances sont affichés par rapport au tilde :

Le répertoire d'instances contient plusieurs sous-répertoires, que vous pouvez lister à l'aide de la commande « ll » (alias de « ls -l ») :

Comme on peut le constater, les répertoires bin, include, lib, share et version sont des liens symboliques. Les autres sont des répertoires « normaux ». Cela reflète la séparation entre le logiciel et les données, comme expliqué ci-dessus. Le répertoire du logiciel doit être accessible en tant que sous-répertoire du site, mais il est physiquement situé dans /omd/versions/ et peut également être utilisé par d’autres sites.

Les répertoires de logiciels, comme c'est habituellement le cas sous Linux, appartiennent à root et ne peuvent donc pas être modifiés par un utilisateur de l'instance. Les sous-répertoires suivants sont présents – ceux de l'exemple se trouvent physiquement dans /omd/versions/2.4.0p24.cee/ , et sont accessibles via des liens symboliques depuis le répertoire d'instances :

Le lien symbolique version est une « étape intermédiaire » et sert de point de relais pour la version utilisée par l’instance. Lors d’une mise à jour du logiciel, celui-ci sera basculé de l’ancienne vers la nouvelle version. Néanmoins, n’essayez pas d’effectuer une mise à jour manuellement en modifiant le lien, car une mise à jour nécessite un certain nombre d’autres étapes supplémentaires – qui échoueront.

Les données proprement dites d’une instance se trouvent dans les sous-répertoires restants du répertoire d’instances. Sans exception, celles-ci appartiennent à l’utilisateur de l’instance. Le répertoire d’instances lui-même est également inclus. Checkmk ne stocke rien d’autre que les répertoires qui y sont répertoriés. Vous pouvez y créer sans problème vos propres fichiers et répertoires, dans lesquels vous pouvez conserver, selon vos besoins, des tests, des données téléchargées, des copies de fichiers journaux, etc.

Les répertoires suivants ont été prédéfinis :

Comme le montre le tableau ci-dessus, le répertoire ~/local/, avec ses nombreux sous-répertoires, est destiné à vos propres extensions. Dans une nouvelle instance, tous les répertoires de ~/local/ sont initialement vides.

Grâce à l'instruction pratique « tree », vous pouvez rapidement obtenir un aperçu de la structure de « ~/local/ ». L'option « -L 3 » limite la profondeur à 3 :

Tous les répertoires du niveau le plus bas sont activement intégrés au logiciel. Un fichier stocké ici sera traité de la même manière que s’il se trouvait dans le répertoire du même nom au sein de /omd/versions/…​ (ou, respectivement, dans le chemin d'accès logique du site dans ~/bin/, ~/lib/ ou ~/share/).

Exemple : sur l’instance, les programmes exécutables seront recherchés dans ~/bin/ et dans ~/local/bin/.

Il convient de noter qu’en cas de noms identiques, le fichier situé dans ~/local/ a toujours la priorité. Cela permet de modifier le logiciel sans avoir à changer les fichiers d’installation dans /omd/versions/. La procédure est simple :

En ce qui concerne le point 3 ci-dessus, si vous ne savez pas exactement à quel service s'applique la modification, redémarrez simplement l'ensemble de l'instance à l'aide de omd restart.

Dans Checkmk – comme déjà décrit – les fichiers journaux sont stockés dans le répertoire de données var/. Les fichiers journaux des composants concernés s’y trouvent. La sortie suivante, correspondant à l’une des éditions commerciales, est abrégée :

Sur l'interface web, vous pouvez facilement configurer l'étendue des données à consigner dans les fichiers journaux en recherchant dans Setup > General > Global settings toutes les entrées de journal contenant logging :

L'instruction cmk est en réalité une abréviation de check_mk, introduite pour accélérer la saisie de l'instruction. L'instruction comprend une aide en ligne intégrée très détaillée, accessible via l'option --help :

Comme vous pouvez le voir dans l'instruction ci-dessus, nous avons appelé l'aide avec l'option « -h » au lieu de « --help ». Car ce qui vaut pour l'instruction elle-même vaut également pour ses options : moins il y a à taper, plus c'est rapide. Ce n’est pas le cas pour toutes les options, mais pour celles qui sont souvent utilisées, il existe donc un formulaire abrégé en plus du formulaire long. Même si le formulaire long est plus intuitif, en particulier pour les débutants (check_mk --list-hosts), que le formulaire abrégé (cmk -l), nous utiliserons le formulaire abrégé dans le guide de l'utilisateur. En cas de doute, vous pouvez toujours consulter l’aide de l’instruction. Il est de toute façon conseillé de consulter attentivement l’aide de l’instruction, car nous ne présenterons pas toutes les options dans le guide de l'utilisateur.

En saisissant une option, vous lancez l'instruction cmk dans un mode spécifique. Voici un aperçu des options que nous présenterons dans ce chapitre, mais également dans d'autres parties du manuel :

Dans certains modes, des options supplémentaires spécifiques sont à votre disposition ; vous pouvez par exemple limiter la reconnaissance du service à certaines vérifications, par exemple à la vérification « df » à l'aide de l'instruction « cmk -I --detect-plugins=df myserver123 ».

Un certain nombre d'options fonctionnent toujours, quel que soit le mode dans lequel l'instruction est exécutée :

Dans la section suivante, nous vous montrerons comment utiliser ces instructions. Les exemples de sortie sont pour la plupart présentés sous une forme abrégée.

Les éditions commerciales utilisent le Checkmk Micro Core (CMC) comme noyau de supervision, tandis que la communauté Checkmk utilise Nagios. Une tâche importante de l’cmk consiste à générer un fichier de configuration lisible par le noyau, et qui contient tous les ordinateurs hôtes, services, contacts, groupes de contacts, périodes, etc. configurés. Sur la base de ces informations, le noyau sait quelles vérifications doivent être exécutées et quels objets il doit fournir à l’interface graphique via Livestatus.

Tant pour Nagios que pour le CMC, il est fondamental que le nombre d’ordinateurs hôtes, de services et d’autres objets reste toujours fixe pendant le fonctionnement, et que ce nombre ne puisse être modifié que par la génération d’une nouvelle configuration, suivie d’un rechargement du noyau du processeur. Avec Nagios, cela nécessite un redémarrage du noyau du processeur. Le CMC dispose d’une fonction très efficace pour le rechargement de sa configuration pendant le traitement actif.

Le tableau suivant met en évidence les différences importantes entre les configurations des deux noyaux du processeur :

La régénération de la configuration est toujours nécessaire si le contenu des fichiers de configuration dans ~/etc/check_mk/conf.d ou des services détectés automatiquement dans ~/var/check_mk/autochecks a été modifié. L'Setupe conserve une trace de ces modifications et les met en évidence dans l'interface graphique en tant que modifications à activer. Les instructions suivantes sont disponibles pour l'activation via la ligne de commande :

Un deuxième mode de Checkmk concerne l'exécution des contrôles basés sur Checkmk d'un ordinateur hôte. Cela vous permet de faire vérifier immédiatement tous les services détectés automatiquement, ainsi que ceux configurés manuellement, sans avoir à vous soucier du noyau de supervision ou de l'interface graphique.

Pour ce faire, saisissez cmk --check suivi du nom d’un ordinateur hôte configuré dans la supervision. L’option --check étant l’option par défaut de cmk, vous pouvez également l’omettre. De plus, vous devriez toujours ajouter les deux options -n (ne pas envoyer les résultats au noyau de supervision) et -v (afficher tous les résultats). Vous trouverez plus d’informations à ce sujet dans la description des options ci-dessous.

Autres conseils :

Les options suivantes influencent l'instruction :

La commande cmk -d récupère et affiche la sortie de l’agent Checkmk d’un ordinateur hôte. Avec cmk -d, les données de l’agent sont récupérées de la même manière que lors de la supervision. Elles ne sont ni validées ni traitées. Ainsi, les données affichées correspondent à une correspondance exacte avec celles qui sont transmises au Agent Controller (lorsque le chiffrement TLS est activé) ou à un programme de tunneling si des programmes source de données sont configurés.

Vous pouvez même exécuter cmk -d en utilisant le nom ou l'adresse IP d'un ordinateur hôte qui n'est pas configuré dans la supervision. Dans ce cas, les paramètres hérités de l'ordinateur hôte seront utilisés (connexion TCP au port 6556, pas d'Agent Controller, pas de chiffrement, pas de programme source de données).

Dans les éditions commerciales, vous pouvez également « cuire » les agents à partir de la ligne de commande, comme vous le feriez autrement via l'interface web. Cela vous offre la possibilité, par exemple, de mettre à jour régulièrement les agents, par exemple via un cron.

Pour installer les agents, utilisez l'option « -A » suivie du nom d'un ordinateur hôte (ou de plusieurs) :

La sortie indique que les paquets d'agent disponibles pour l'ordinateur hôte myserver123 ont été compilés avec succès. Si vous ne spécifiez pas d'ordinateur hôte, les paquets seront compilés pour tous les ordinateurs hôtes.

L'instruction ne génère les paquets que lorsque cela est nécessaire. Si les paquets sont toujours à jour, la sortie ressemblera à ceci :

Vous pouvez toujours forcer la compilation à l'aide de l'option -f (force).

L'instruction « cmk -l » affiche simplement la liste des noms des ordinateurs hôtes configurés dans l'Setup :

Comme les données sont fournies « brutes » et « non traitées », elles sont faciles à utiliser dans des scripts – par exemple, il est possible de créer une boucle sur tous les noms de domaine :

Si, au lieu de echo, vous insérez une instruction qui effectue une action utile, cela peut s'avérer très pratique.

L'appel de la commande `cmk --list-tag` affiche également les noms de domaine, mais offre en outre la possibilité de filtrer par balises de l’hôte. Il suffit de saisir une balise de l’hôte pour obtenir tous les hôtes possédant cette balise. L'exemple suivant répertorie tous les hôtes sous supervision par SNMP :

Saisissez plusieurs balises et elles seront combinées par un « ET ». L'instruction ci-dessous affiche tous les ordinateurs hôtes surveillés à la fois par SNMP et par l'agent Checkmk. Comme aucun ordinateur hôte ne remplit cette condition, la sortie reste vide :

Pour un ou plusieurs ordinateurs hôtes spécifiés, la commande « cmk -D » affiche les services configurés, les balises de l’hôte, les étiquettes d’hôte et d’autres attributs. La liste des services étant très longue, elle peut sembler quelque peu confuse sur le terminal. Envoyez le résultat via « less -S » pour éviter une coupure :

Checkmk fournit en standard un grand nombre de plugins de supervision prêts à l'emploi. À chaque version, quelques nouveaux plugins de supervision sont ajoutés, et la version 2.4.0 en comprend déjà plus de 2 000. Trois options de l'instruction « cmk » vous permettent d'accéder à des informations sur ces plugins de supervision.

cmk -L affiche une liste de tous les plugins avec leur nom, leur type et une description. Parallèlement, tous les plugins que vous avez vous-même écrits et qui sont stockés dans ~/local/ seront également répertoriés.

Les types suivants sont possibles :

La liste peut bien sûr être filtrée simplement à l'aide de l'grepe si vous recherchez quelque chose de spécifique :

Si vous souhaitez obtenir plus d'informations sur un plugin donné, vous pouvez consulter la documentation sous forme de page de manuel à l'aide de cmk -M :

Cela produit le résultat suivant :

L'utilisation de la commande « cmk -m » sans autre option permet d'accéder à un catalogue complet de toutes les pages de manuel des plugins de supervision.

Vous pouvez naviguer de manière interactive dans ce catalogue :

Pas ici. Les fichiers de configuration sont définis par les composants qui les écrivent et les lisent. En fin de compte, seule l'analyse du code source et des tests associés permet de révéler la structure de la configuration stockée dans le système de fichiers.

Notez également que les formats des fichiers de configuration peuvent changer d'une version de correctif à l'autre. Dans ce cas, des routines de migration assurent la conversion des formats de données modifiés.

De plus, les unités utilisées peuvent différer entre l’affichage dans l’Setupe et le stockage dans le fichier de configuration. Cela s’applique, par exemple, à l’affichage des périodes ou des températures.

L'exemple suivant présente un ensemble complet de paramètres pour le plugin de supervision qui effectue la supervision des systèmes de fichiers dans Checkmk (ici dans une version antérieure). En raison du grand nombre de paramètres, la capture d'écran a été divisée en deux parties et mise en forme avec une petite police :

La section correspondante dans le fichier de configuration proprement dit se présente ainsi (avec une mise en forme un peu plus soignée) :

Comme on peut le constater, il y a ici plus de 10 paramètres différents, chacun suivant sa propre logique. Certains sont configurés à l’aide de nombres à virgule flottante (0.8), d’autres à l’aide de nombres entiers (24), certains à l’aide de mots-clés ('onlow'), d’autres à l’aide de valeurs booléennes (True), et enfin certains à l’aide de tuples tels que ((5.0, 10.0)).

Cet exemple ne présente qu'un seul des plus de 2 000 plugins de supervision disponibles. De plus, Checkmk reconnaît d'autres configurations comme paramètres de contrôle : pensez notamment aux périodes, aux règles de l'Event Console, aux profils d'utilisateurs et bien plus encore.

Il existe une instruction pratique pour déterminer quel fichier Setup vient d'être modifié : find. En l'appelant avec les paramètres suivants, vous trouverez tous les fichiers (-type f) dans ~/etc/ qui ont été modifiés au cours de la dernière minute (-mmin -1) :

La base de la configuration est toujours le répertoire ~/etc/check_mk/. Celui-ci est divisé en différents domaines, dont la plupart sont liés à une fonctionnalité spécifique. Chaque domaine dispose d'un répertoire se terminant par .d, à partir duquel tous les fichiers se terminant par .mk sont automatiquement lus par ordre alphanumérique.

Au sein des répertoires de configuration .d/, il existe toujours un sous-répertoire nommé wato, par exemple ~/etc/check_mk/conf.d/wato/. Le service Setup ne lit et n'écrit généralement que dans ce répertoire. Cependant, le service responsable du répertoire de configuration lit également les autres fichiers situés dans son « propre » répertoire .d.

Si des fichiers se trouvent en dehors du répertoire wato/, ils ont soit été créés manuellement à un moment donné dans le but d’apporter des modifications effectives mais non visibles dans l’Setup, soit ils ont été créés par d’autres composants de Checkmk.

Les fichiers de configuration peuvent être des fichiers texte consultables dans n’importe quel éditeur, ou des fichiers binaires nécessitant des outils spécifiques. Les fichiers texte respectent la syntaxe Python, mais leur traitement par Checkmk présente certaines différences :

Le codage de caractères UTF-8 est toujours utilisé. Si vous devez apporter des modifications pour quelque raison que ce soit, assurez-vous que le fichier modifié puisse toujours être analysé par Python.

Les fichiers binaires ont l'extension .pb, qui signifie « Protocol Buffers » et est parfois également appelé « Protobuf ». Ce format, développé par Google pour la sérialisation de la configuration et des messages, peut être écrit et lu avec un faible dépassement. Cependant, des outils spéciaux sont nécessaires pour le visualiser. Le paquet Checkmk comprend protoc, qui effectue de nombreuses tâches simples. Par exemple, ce qui suit fournit un aperçu « brut » du dernier état d'un CMC arrêté :

Pour une analyse plus détaillée des fichiers Protobuf, vous pouvez utiliser protoscope.

Si vous soupçonnez que des fichiers de configuration sont corrompus (par exemple en raison d'un support de données défectueux), vous pouvez les faire checker. Checkmk fournit à cet effet le programme « cmk-validate-config » qui, contrairement à « cmk-update-config » (appelé lors d’une mise à jour du logiciel), n’effectue aucune modification telle que la migration des formats de données. « cmk-validate-config» vérifie à la fois la syntaxe (parenthèses, affectations correctes, etc.) et, en partie, la sémantique (types de données utilisés et présence de certaines clés). Si le programme détecte des erreurs de syntaxe, le premier fichier endommagé s’affichera :

Si les fichiers checkés sont OK, une liste de tous les fichiers examinés s'affichera :