Surveillance sous Linux

Vous installez l'agent Linux en installant le paquet RPM ou DEB. Le choix entre RPM et DEB dépend de la distribution Linux sur laquelle vous souhaitez installer le paquet :

Avant l'installation, vous devrez récupérer le paquet et le transférer sur l'hôte (par exemple à l'aide d'scp ou de WinSCP) sur lequel vous souhaitez que l'agent s'exécute.

Une fois que vous avez récupéré le paquet RPM ou DEB et, si nécessaire, que vous l'avez copié sur l'hôte à surveiller à l'aide de scp, WinSCP ou d'autres moyens, l'installation s'effectue à l'aide d'une seule commande.

Le paquet RPM est installé en tant qu'utilisateur root à l'aide de la commande rpm -U :

À propos, l'option -U signifie « mise à jour », mais elle permet également d'effectuer correctement une installation initiale. Cela signifie également que vous pouvez utiliser cette commande pour mettre à jour un agent existant vers la version actuelle — et utiliser la même commande pour les futures mises à jour du paquet de l'agent.

L'installation du paquet DEB — ainsi que sa mise à jour — s'effectue en tant qu'utilisateur root à l'aide de la commande dpkg -i :

Ici, le paquet a été installé pour la première fois sur un hôte qui ne disposait pas encore d’agent. L’utilisateur cmk-agent a été créé et systemd a été configuré. Nous aborderons dans un instant l’avertissement provisoire concernant insecure mode, c’est-à-dire le mode pull hérité.

Les éditions commerciales disposent d’un module logiciel, l’Agent Bakery, permettant de créer automatiquement des paquets d’agents personnalisés. Vous trouverez une description détaillée de ce module dans l’article général consacré aux agents. L’installation des paquets créés s’effectue de la même manière que celle décrite ci-dessus pour les paquets fournis.

Dans Checkmk Ultimate, vous pouvez en outre utiliser l'Agent Bakery pour doter les paquets d'agents d'une configuration d'enregistrement automatique, ce qui facilite la création automatique d'hôtes. Dans ce cas, l'enregistrement de l'agent s'effectue automatiquement après l'installation du paquet d'agent et l'enregistrement manuel, tel que décrit dans le chapitre suivant, n'est plus nécessaire.

Si vous utilisez l'Agent Bakery, vous pouvez également configurer les mises à jour automatiques de l'agent. Ces mises à jour sont décrites dans un article dédié.

Si l'Agent Controller a pu être configuré avec l'systemde lors de l'installation, l'étape suivante est l'enregistrement, qui configure le chiffrement TLS afin que les données chiffrées de l'agent puissent être déchiffrées par le serveur Checkmk, puis affichées dans la surveillance.

Une particularité existe lorsque l’agent a été installé avec l’Agent Controller pour la première fois. Dans ce cas, l’agent passe en mode pull hérité non chiffré afin que le serveur Checkmk ne soit pas privé des données de surveillance et puisse continuer à les afficher. Cela s’applique aussi bien à une nouvelle installation qu’à une mise à jour d’un agent de version 2.0.0 et antérieure.

Vous recevrez une notification concernant l'activation du mode pull hérité dans la sortie de commande lors de l'installation de l'agent. Cela se présentera comme suit dans la surveillance :

Le site Checkmk détecte, à partir de la sortie de l'agent, que l'Agent Controller est présent et que le chiffrement TLS est donc possible — mais pas encore activé. Le service Check_MK Agent passe à l'état « WARN » et y reste jusqu'à ce que vous l'enregistriez. Après l'enregistrement, seul le mode pull chiffré est utilisé pour la communication. Le mode pull hérité est désactivé et le restera. Il peut toutefois être réactivé par commande si nécessaire.

La situation est différente si l'Agent Controller n'a pas pu être enregistré en tant que démon auprès de systemd lors de l'installation. Sans Agent Controller, l'enregistrement n'est pas possible et le seul canal de communication reste le mode hérité.

Dans le chapitre suivant, vous pourrez déterminer si vous pouvez procéder à l'enregistrement en testant l'Agent Controller et l'environnement système.

Remarque : dans le jeu de règles d'Checkmk Agent installation auditing, vous trouverez divers paramètres permettant de vérifier l'état de l'agent et de le rendre visible dans la surveillance. Vous pouvez notamment spécifier ici l'état que doit avoir le service Check_MK Agent si la configuration TLS n'a pas encore été effectuée.

Immédiatement après l'installation de l'agent (ou lors de la mise à jour d'un agent de version 2.0.0 ou antérieure), seules les communications non chiffrées sont possibles en mode pull hérité. Une transmission de données exclusivement chiffrée ne peut être activée qu'une fois qu'une relation de confiance a été établie.

Les paquets préconfigurés pour l'enregistrement automatique et téléchargés via l'Agent Bakery constituent une exception à cette règle. Ces paquets effectuent l'enregistrement automatiquement après l'installation.

Dans tous les autres cas, vous devez effectuer l'enregistrement manuel immédiatement après l'installation de l'agent. Ce chapitre explique comment procéder à l'enregistrement.

L'enregistrement, et donc l'établissement de la relation de confiance mutuelle, s'effectue en tant qu'utilisateur Checkmk disposant d'un accès à l'API REST. Pour cela, l'utilisateur d'automatisation agent_registration constitue un bon choix : il dispose uniquement de l'autorisation d'enregistrer des agents et est créé automatiquement lors de chaque installation de Checkmk. Vous pouvez générer aléatoirement le mot de passe d'automatisation correspondant (secret d'automatisation) à l'aide de l'icône « ». Vous devez enregistrer l'utilisateur avant de pouvoir utiliser le nouveau mot de passe.

L'agent avec l'Agent Controller nécessite une distribution Linux équipée d'systemd, plus précisément d'systemd, version 219 ou plus récente.

Il y a de fortes chances que cette exigence soit satisfaite sur votre hôte, car depuis 2015, la plupart des distributions Linux ont adopté systemd comme système d'initialisation, en remplacement d'autres systèmes d'initialisation tels que SysVinit, par exemple SUSE Linux Enterprise Server à partir de la version 12, openSUSE à partir de la version 12.1, Red Hat Enterprise Linux à partir de la version 7, Fedora à partir de la version 15, Debian à partir de la version 8 et Ubuntu à partir de la version 15.04. Malheureusement, la simple comparaison du numéro de version n'apporte pas de certitude, car systemd peut être absent même sur un système Linux actuel s'il n'a été « que » mis à jour au fil des ans.

Outre la version d'systemd, certaines conditions préalables supplémentaires doivent être remplies, ce qui sera expliqué dans ce chapitre.

Attention : le mode push et l’enregistrement automatique dépendent nécessairement de l’Agent Controller et ne sont donc pas utilisables en mode legacy, un point sur lequel nous reviendrons à plusieurs reprises dans ce chapitre.

Vérifiez donc d'abord sur l'hôte sur lequel l'agent doit être installé si systemd est en cours d'exécution et de quelle version il s'agit :

La sortie de la commande ci-dessus indique que la version correcte d'systemd est installée. Si systemd n'est pas en cours d'exécution, ou s'il s'agit d'une version trop ancienne, l'Agent Controller ne peut pas être utilisé. Terminez la configuration comme décrit dans l'article Surveillance de Linux en mode hérité.

Vérifiez maintenant si l'Agent Controller peut être démarré :

Le numéro de version doit apparaître dans la sortie, par exemple :

Dans de rares cas, le message d'erreur suivant peut s'afficher :

Cela s'explique par le fait que votre système Linux utilise une architecture informatique différente de x86_64, par exemple l'ancienne architecture x86 32 bits ou ARM. Dans ce cas, l'Agent Controller ne peut pas être utilisé.

Effectuez la configuration comme décrit dans l'article Surveillance de Linux en mode hérité.

L'étape suivante consiste à déterminer quel programme attend des requêtes sur le port 6556 :

Le voici : cmk-agent-ctl. Les conditions requises pour une communication cryptée sont donc remplies. Si toutefois systemd, xinetd ou inetd figurent entre parenthèses, les conditions préalables à l'utilisation de l'Agent Controller ne sont pas remplies. Dans ce cas, effectuez également la configuration comme décrit dans l'article « Surveiller Linux en mode hérité ».

Commencez par créer le nouvel hôte via Setup > Hosts > Add host. Un hôte doit exister dans l'environnement de configuration avant de pouvoir être enregistré.

Dans Checkmk Ultimate, vous trouverez l'option « Checkmk agent connection mode » dans les propriétés de l'hôte, dans la section consacrée aux agents de surveillance. Vous pouvez y activer le mode « push » pour l'agent Checkmk, en alternative au mode « pull », disponible dans toutes les éditions.

L'enregistrement s'effectue à l'aide de l'cmk-agent-ctl Agent Controller, qui fournit une interface de commande pour configurer les connexions. Vous pouvez afficher l'aide relative aux commandes avec cmk-agent-ctl help, ainsi que pour des sous-commandes spécifiques disponibles, avec cmk-agent-ctl help register par exemple.

Le fait que l'hôte soit configuré pour le mode pull ou le mode push n'a aucune incidence sur les exemples de commande. L'Agent Receiver indique à l'Agent Controller dans quel mode il doit fonctionner lors de l'enregistrement.

Accédez maintenant à l'hôte à enregistrer. À partir de là, avec les privilèges d'root, envoyez une requête au site Checkmk :

Le nom d'hôte suivant l'option « --hostname » doit être exactement le même que celui utilisé lors de sa création dans la configuration. Les options « --server » et « --site » spécifient le nom du serveur Checkmk et du site. Le nom du serveur peut également être l'adresse IP ; le nom du site (ici mysite) correspond à celui que vous voyez dans le chemin d'accès URL de l'interface Web. Ces options sont complétées par le nom d'utilisateur et le mot de passe utilisés par l'utilisateur de l'automatisation. Si vous omettez l'option --password, le mot de passe vous sera demandé de manière interactive.

Si les valeurs spécifiées sont correctes, il vous sera demandé de confirmer l'identité du site Checkmk auquel vous souhaitez vous connecter. Pour plus de clarté, nous avons abrégé le certificat du serveur à confirmer :

Confirmez en cliquant sur « Y » pour terminer le processus.

Si aucun message d'erreur ne s'affiche, la connexion cryptée aura été établie. Toutes les données seront désormais transmises sous forme compressée via cette connexion.

Si vous souhaitez désactiver la vérification interactive du certificat — par exemple pour automatiser entièrement l'enregistrement —, vous pouvez utiliser le paramètre supplémentaire --trust-cert. Dans ce cas, le certificat transféré sera automatiquement considéré comme fiable. N'oubliez pas que vous devez prendre d'autres mesures pour vérifier l'intégrité du certificat. Cela peut être effectué (manuellement ou via un script) en inspectant le fichier /var/lib/cmk-agent/registered_connections.json.

Checkmk Ultimate offre la possibilité de créer automatiquement des hôtes lors de l'enregistrement. Pour l'enregistrement automatique, outre un utilisateur disposant des autorisations nécessaires pour enregistrer des hôtes, vous devez disposer d'au moins un dossier configuré pour contenir les hôtes à créer automatiquement.

Si ces conditions sont remplies, vous pouvez également effectuer l'enregistrement, y compris la création automatique d'hôtes, via la ligne de commande.

En général, vous utiliserez la procédure de configuration d'Agent Bakery, qui inclut le fichier de configuration /var/lib/cmk-agent/pre_configured_connections.json dans le paquet de l'agent et qui effectue l'enregistrement automatiquement lors de l'installation. L'appel de ligne de commande présenté ici est donc principalement destiné aux tests et au débogage, par exemple pour essayer vos propres étiquettes d'agent avec l'option --agent-labels <KEY=VALUE>.

La principale différence réside ici dans la sous-commande register-new modifiée, qui sert à demander l'enregistrement et la création d'un nouvel hôte sur le site Checkmk. Le nom de l'hôte est celui stocké dans la variable d'environnement $HOSTNAME. La confirmation du certificat qui s'ensuit est identique à celle présentée dans la section précédente.

Le fait que l'hôte soit créé en mode pull, en mode push ou pas du tout est défini par vos paramètres dans le jeu de règles Agent registration. Une fois l'enregistrement réussi, plusieurs minutes peuvent s'écouler avant que l'hôte n'apparaisse dans la surveillance.

La commande cmk-agent-ctl status affiche désormais exactement une relation de confiance avec le serveur Checkmk :

Si vous avez besoin de ces informations dans un format lisible par machine, ajoutez le paramètre supplémentaire --json pour récupérer la sortie au format JSON.

Remarque : il ne peut y avoir qu'une seule relation de confiance entre un hôte et un site. Par exemple, si vous enregistrez un hôte déjà enregistré mynewhost sous un nom différent (mynewhost2) mais avec la même adresse IP, la nouvelle connexion remplacera alors celle qui existe déjà. La connexion entre mynewhost et le site sera interrompue et aucune donnée d'agent ne sera plus fournie à l'hôte à des fins de surveillance.

Pour faciliter l'enregistrement de plusieurs hôtes, tout hôte sur lequel l'agent est installé peut effectuer un enregistrement au nom d'autres hôtes. Le processus d'enregistrement exporte un fichier JSON, qui peut ensuite être transféré vers l'hôte cible et y être importé. Comme précédemment, l'hôte enregistré dans la tâche doit déjà être configuré sur le site.

Tout d'abord, sur n'importe quel hôte de la configuration, l'enregistrement est effectué par procuration. Ici, bien sûr, le serveur Checkmk s'avère très pratique, car il est généralement le premier hôte à être configuré. Comme dans l'exemple ci-dessus, vous pouvez transmettre le mot de passe via l'option ou être invité à le saisir de manière interactive si vous omettez l'option --password. Dans l'exemple, nous redirigeons la sortie JSON vers un fichier :

Nous transférons ensuite le fichier /tmp/mynewhost3.json vers l'hôte que nous avons enregistré et importons ce fichier :

Ce processus est également possible en une seule étape à l'aide d'un pipeline où la sortie de `cmk-agent-ctl proxy-register` est transmise en entrée à `ssh hostname cmk-agent-ctl import` :

Une fois l'enregistrement terminé, effectuez un test de connexion et une découverte des services dans la configuration du serveur Checkmk. Enfin, incluez les services découverts dans la surveillance en activant les modifications.

Si le test de connexion échoue, reportez-vous au chapitre suivant pour obtenir des informations sur les tests et le dépannage.

Vous pouvez également désenregistrer un hôte.

Sur un hôte connecté au serveur Checkmk, vous pouvez révoquer la confiance. Ici, dans la commande suivante, l'identifiant unique universel (UUID) à spécifier est celui généré par la commande « cmk-agent-ctl status » :

Pour supprimer toutes les connexions de l'hôte et rétablir en outre le mode pull hérité, entrez la commande suivante :

Par la suite, l'agent se comporte comme après l'installation initiale et avant le premier enregistrement, et envoie ses données en clair.

Terminez la désinscription sur le serveur Checkmk : Dans la configuration, sur la page « Properties of host », sélectionnez l'option de menu « Host > Remove TLS registration » et confirmez l'invite.

Si vous préférez la ligne de commande : Sur le serveur Checkmk, pour chaque connexion d'un hôte sous surveillance, il existe un lien symbolique avec l'UUID qui pointe vers le dossier contenant la sortie de l'agent :

Dans Checkmk Ultimate , vous pouvez faire passer les hôtes du mode push au mode pull et inversement. Cela peut s’avérer nécessaire dans certains cas particuliers si des modifications de la topologie du réseau sont en cours, ou si une rétrogradation vers Checkmk Pro — où seul le mode pull est possible — doit être effectuée.

Commencez par définir le mode d’accès dans la configuration, dans les propriétés de l’hôte, à l’aide de l’option « Checkmk agent connection mode ». Dans la minute qui suit, tous les services passeront au statut « UNKNOWN » (Inconnu) car aucune donnée de surveillance n’est reçue. Effectuez ensuite un nouvel enregistrement. Au cours de ce réenregistrement, l’Agent Receiver du serveur Checkmk indique à l’Agent Controller s’il attend des données en mode pull ou push. Une vérification ultérieure à l'aide de cmk-agent-ctl status affichera alors un nouvel UUID et un mode correspondant à la modification effectuée dans la configuration.

Le script de l'agent est un simple script shell qui récupère des données sur votre système et les affiche sous forme de texte au formatage libre. Vous pouvez appeler ce script directement depuis la ligne de commande. La sortie pouvant être assez longue, l'option less permettant de faire défiler la sortie est très pratique ici. Vous pouvez quitter le script à l'aide de la touche Q :

Cela vous permet de vérifier si le script de l'agent, vos plug-ins et vos vérifications locales sont correctement installés.

À noter que vous n'avez pas besoin d'être administrateur pour appeler l'agent. Cependant, la sortie ne contiendra alors pas certaines informations qui nécessitent des privilèges d'root pour être obtenues (par exemple, les informations sur les chemins multiples et les sorties de ethtool).

Afin d'éviter que les messages d'erreur provenant de plug-ins ou de commandes inactifs ne « contaminent » les données requises, le script de l'agent supprime généralement le canal d'erreur standard (STDERR). Si vous recherchez un problème spécifique, vous pouvez réactiver le STDERR en appelant le script de l'agent dans un mode de débogage spécial.

Au préalable, vous devez vérifier si le script de l'agent et le contrôleur d'agent en mode vidage fournissent une sortie identique et, si nécessaire, vous assurer que l'environnement est identique. Cela peut être effectué en définissant des variables dans une vérification de plug-in/locale ou dans le shell. Vous pouvez créer un vidage de l'environnement en ajoutant la ligne

à un fichier de plug-in, puis en vérifiant le contenu du fichier après l’exécution par le contrôleur d’agent.

Les informations de débogage supplémentaires sont alors générées à l'aide de l'option -d. Toutes les commandes shell exécutées par le script seront également générées. Pour pouvoir utiliser less ici, vous devez combiner la sortie standard (STDOUT) et le canal d'erreur avec 2>&1 :

Si l'enregistrement d'un hôte échoue avant même qu'un certificat ne soit présenté, la connaissance des modes de communication peut aider à identifier le problème — et bien sûr à le résoudre.

Après avoir saisi la commande « cmk-agent-ctl register », le contrôleur d’agent demande d’abord au serveur Checkmk le port du récepteur d’agent à l’aide de l’API REST. Dans un deuxième temps, une connexion au récepteur d’agent est établie pour demander le certificat. Vous pouvez simuler la première requête sur l’hôte à l’aide d’un programme tel que curl :

Le paramètre --insecure indique à curl d'ignorer la vérification du certificat. Ce comportement reflète celui du contrôleur d'agent à cette étape. La réponse ne comporte que quelques octets et contient le numéro de port de l'Agent Receiver. Pour le premier site, il s'agit généralement de 8000, pour le deuxième de 8001, et ainsi de suite.

Les problèmes courants liés à cette requête sont les suivants :

Si la requête ci-dessus échoue, vous pouvez modifier les paramètres de routage ou de pare-feu pour permettre l'accès.

Si l'hôte que vous essayez d'enregistrer utilise un proxy HTTP, curl l'utilisera, mais cmk-agent-ctl ne le fera pas avec les paramètres par défaut. Utilisez l'option supplémentaire --detect-proxy pour indiquer à cmk-agent-ctl d'utiliser un proxy configuré via les paramètres système.

Cependant, il est souvent plus simple de déterminer le port de l'Agent Receiver et de le noter. Pour ce faire, sur le serveur Checkmk, connectez-vous en tant qu'utilisateur du site :

Vous pouvez désormais spécifier le port lors de la saisie de la commande d'enregistrement. Cela permet d'éviter la première requête vers l'API REST. La communication s'effectue alors directement avec l'Agent Receiver, sans détours :

Le port 8000 doit également être accessible depuis l'hôte. Si ce n'est pas le cas, vous obtiendrez ce message d'erreur :

À l'instar du port 443 (ou 80) mentionné ci-dessus, vous pouvez désormais ajuster les paramètres de routage ou de pare-feu afin que l'hôte à enregistrer puisse atteindre le serveur Checkmk sur le port de l'Agent Receiver (8000 ou 8001…​)

Dans le cas d'un enregistrement en mode push, les règles suivantes s'appliquent : Si l'enregistrement a fonctionné, le transfert minute par minute de la sortie de l'agent sera également réussi.

Si les politiques de sécurité de votre environnement ne permettent pas l'accès à l'Agent Receiver, il est toujours possible d'utiliser l'enregistrement par proxy sur le serveur Checkmk.

L'Agent Controller fournit sa propre sous-commande « dump » qui affiche la sortie complète de l'agent au fur et à mesure de son arrivée dans la surveillance :

Cela vous permet de vérifier que les données provenant du script de l'agent sont bien parvenues au contrôleur d'agent. Cette sortie ne prouve pas encore que l'agent est également accessible via le réseau.

Dans certains cas, la sortie ressemblera à ceci :

Ce serait le cas lorsque le socket de l'agent ne s'exécute pas en arrière-plan — immédiatement après une mise à jour, par exemple. Redémarrez ce processus d'arrière-plan :

Si l'cmk-agent-ctl dumpation échoue à nouveau, vérifiez si un programme écoute sur le port 6556 et, le cas échéant, lequel :

Si la sortie est vide ou si une commande autre que cmk-agent-ctl figure entre parenthèses, les conditions système requises pour l'utilisation de l'Agent Controller ne sont pas remplies. Dans ce cas, effectuez la configuration comme décrit dans l'article Surveiller Linux en mode hérité.

Si, en mode pull, il a été vérifié que le script de l'agent et ses plug-ins installés s'exécutent correctement, vous pouvez ensuite vérifier via netcat (ou nc) si le port 6556 est accessible via l'adresse IP externe de l'hôte :

La sortie 16 indique que la connexion a été établie avec succès et que la négociation TLS peut désormais avoir lieu. Étant donné que tout le reste est ici chiffré par TLS, aucune vérification plus détaillée n'est possible.

Si un test de connexion à distance échoue, cela est généralement dû au paramétrage du pare-feu. Dans ce cas, configurez iptables ou nftables pour autoriser l'accès au port TCP 6556 depuis le serveur Checkmk.

Si la communication entre l'agent et le serveur Checkmk n'est toujours pas chiffrée (comme en mode pull hérité), ou si elle ne l'est pas et ne le sera pas (comme en mode hérité), cette commande vous fournira la sortie complète non chiffrée de l'agent au lieu de l'16.

Remarque : pour effectuer d'autres diagnostics sur le serveur Checkmk, consultez l'article général sur les agents de surveillance.

Dans le dossier « ~/var/agent-receiver/received-outputs/ » de votre site Checkmk, vous trouverez, pour chaque hôte enregistré, un lien symbolique dont le nom correspond à l'UUID de l'hôte. Pour les hôtes en mode push, ce lien symbolique pointe vers le dossier contenant la sortie de l'agent ; pour les hôtes en mode pull, il pointe vers un fichier inexistant portant le nom de l'hôte tel qu'il est utilisé dans la surveillance.

En fonction de l'ancienneté de la sortie de l'agent mise en cache, vous pouvez déterminer si la transmission régulière a abouti ou si elle est interrompue, par exemple par des problèmes réseau sporadiques.

De plus, vous pouvez afficher l'état des dernières transmissions et tentatives de transmission sur l'hôte à l'aide de la commande `systemctl status cmk-agent-ctl-daemon`. Des lignes telles que celles ci-dessous indiquent des problèmes de connexion :

Si un hôte a été configuré pour l’enregistrement automatique avec le jeu de règles Agent controller auto-registration et que l’option Keep existing connections est définie sur no, chaque fois que le service cmk-agent-ctl-daemon est redémarré (par exemple, lors du redémarrage d’un hôte), toutes les autres connexions seront supprimées — à l’exception de la connexion configurée pour l’enregistrement automatique. Cela affecte, par exemple, les hôtes sur lesquels des connexions vers plusieurs sites ont été configurées avant l’installation du paquet d’agent précompilé, ou sur lesquels des connexions ont été ajoutées manuellement après l’installation du paquet d’agent.

Vous pouvez temporairement contourner ce comportement en définissant la variable keep_existing_connections sur true dans le fichier C:\ProgramData\checkmk\agent\pre_configured_connections.json sur l’hôte. Vous pouvez effectuer une modification permanente lors d’une mise à jour du paquet d’agent en définissant Keep existing connections sur yes dans le jeu de règles ci-dessus.

Lors de l'enregistrement automatique d'un hôte, il faut généralement compter environ deux minutes avant que l'hôte n'apparaisse dans la surveillance.

Si une connexion en mode pull vers un autre site a été ajoutée ultérieurement à un hôte initialement configuré en mode push, il faudra attendre jusqu'à cinq minutes avant que le port 6556 ne s'ouvre. Vous pouvez ouvrir le port immédiatement en redémarrant le service cmk-agent-ctl-daemon.

La sécurité est un critère important pour tout logiciel, et la surveillance ne fait pas exception. Étant donné que l’agent de surveillance est installé sur chaque serveur surveillé, un problème de sécurité aurait ici des conséquences particulièrement graves.

C'est pourquoi la sécurité a été mise en avant lors de la conception de Checkmk et constitue un principe absolu depuis les tout débuts de Checkmk : l'agent ne lit pas les données du réseau. Point final. Cela signifie qu'il est impossible pour un attaquant d'injecter des commandes ou des composants de script via le port de surveillance 6556.

Pour un attaquant, cependant, même une liste de processus peut constituer un premier indice permettant de tirer des conclusions sur des cibles intéressantes. Par conséquent, le chiffrement de la couche de transport entre l’agent et le serveur Checkmk à l’aide du protocole Transport Layer Security (TLS) est obligatoire à partir de la version 2.1.0 de Checkmk. Ici, le serveur Checkmk « ping » l’hôte surveillé, qui établit alors la connexion TLS avec le serveur Checkmk et transmet la sortie de l’agent par ce biais. Étant donné que seuls les serveurs Checkmk avec lesquels une relation de confiance existe peuvent initier ce transfert de données, il n’y a aucun risque que les données tombent entre de mauvaises mains.

Pour sécuriser la connexion TLS, Checkmk utilise un certificat auto-signé qui est automatiquement remplacé peu avant l’expiration de sa validité. L’Agent Controller se charge de renouveler le certificat à temps avant son expiration. Seuls les agents qui sont restés inactifs pendant une longue période, c’est-à-dire sans Agent Controller en cours d’exécution, peuvent perdre leur enregistrement à l’expiration et doivent alors être réenregistrés. La durée de vie du certificat peut être spécifiée via le paramètre global Agent Certificates > Lifetime of certificates.

Étant donné que seuls les serveurs Checkmk autorisés peuvent récupérer des données et que les serveurs non autorisés échouent après quelques octets d’échange d’informations d’identification, le risque d’une attaque par déni de service (DoS) est très faible. Pour cette raison, aucune restriction d'accès supplémentaire n'est actuellement prévue. Vous pouvez bien sûr bloquer le port 6556 contre tout accès non autorisé via iptables. Toute règle existante qui a été transférée aux clients via l'Agent Bakery afin de restreindre l'accès à certaines adresses IP est ignorée par l'Agent Controller.

En particulier lors de la mise à jour de l'agent, il se peut que le chiffrement intégré (symétrique) soit actif, lequel est effectué par le script de l'agent lui-même. Si le chiffrement TLS et le chiffrement intégré sont actifs simultanément, l’entropie des données transmises est si élevée que la compression, active à partir de la version 2.1.0, ne permettra pas de réduire le volume des données transmises — et imposera aux processeurs de l’hôte et du serveur Checkmk des processus supplémentaires de chiffrement et de déchiffrement.

C'est pourquoi vous devez désactiver le chiffrement intégré dès que possible après être passé à TLS.

Dans un premier temps, désactivez le chiffrement dans la règle existante sous Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows).

Dans un deuxième temps, renommez le fichier de configuration /etc/check_mk/encryption.cfg sur l’hôte de l’agent.

Dans la troisième et dernière étape, utilisez la règle « Enforce agent data encryption » pour spécifier que le serveur Checkmk n'accepte que les données chiffrées via TLS. Pour ce faire, sélectionnez la valeur « Accept TLS encrypted connections only » dans la règle.

La désactivation du chiffrement avec Agent Bakery se déroule comme suit : Avec la première étape, qui consiste à modifier la règle « Symmetric encryption (Linux, Windows) », vous avez presque terminé. Il ne vous reste plus qu’à créer les paquets et à distribuer les nouveaux agents. Le fichier de configuration /etc/check_mk/encryption.cfg sera automatiquement modifié pour vous et inclus dans les paquets d’agent. Il ne reste plus que la troisième étape, à savoir la modification de la règle « Enforce agent data encryption ».

Après la prochaine mise à jour automatique de l'agent, le chiffrement du script de l'agent sera désactivé, mais le chiffrement sera assuré par l'Agent Controller. Veuillez noter qu'après la mise à jour automatique de l'agent, seuls les hôtes enregistrés pourront fournir des données de surveillance.

Le script de l'agent /usr/bin/check_mk_agent contient un ensemble complet de sections qui fournissent des données de surveillance pour divers plug-ins de vérification, lesquels sont ensuite automatiquement détectés par la découverte de services. Cela inclut toutes les surveillances importantes pour le système d'exploitation.

De plus, il est possible d’étendre l’agent à l’aide de plug-ins d’agent. Il s’agit de petits scripts ou programmes appelés par l’agent et qui l’étendent avec des sections supplémentaires contenant des données de surveillance complémentaires. Le projet Checkmk fournit toute une série de tels plug-ins qui, s’ils sont correctement installés et configurés, fournissent automatiquement de nouveaux services via la découverte de services.

Pourquoi ces plug-ins ne sont-ils pas simplement intégrés en dur dans l’agent ? Pour chacun des plug-ins, l’une des raisons suivantes s’applique :

Les plug-ins fournis avec Linux et Unix sont tous disponibles sur la page de téléchargement des agents, dans le menu Configuration (comme décrit dans le chapitre consacré à l'installation), dans la section Plugins :

Pour tous les plug-ins d'agent que nous fournissons, il existe des plug-ins de vérification correspondants qui permettent d'évaluer les données de l'agent et de créer des services. Ceux-ci sont déjà installés, de sorte que les nouveaux services détectés peuvent être immédiatement identifiés et configurés.

Remarque : avant d'installer un plug-in sur un hôte, consultez le fichier correspondant. Vous y trouverez souvent des informations importantes sur l'utilisation correcte du plug-in.

L'installation proprement dite est ensuite simple : Copiez le fichier dans /usr/lib/check_mk_agent/plugins. Assurez-vous qu'il est exécutable. Si ce n'est pas le cas, utilisez un chmod 755, sinon l'agent n'exécutera pas le plug-in. Notez que, en particulier si vous ne transférez pas les fichiers via scp mais que vous les récupérez via HTTP depuis la page de téléchargement, l'autorisation d'exécution sera perdue.

Une fois que le plug-in est exécutable et se trouve dans le répertoire approprié, il sera automatiquement invoqué par l'agent et une nouvelle section sera créée dans la sortie de l'agent. Cette section porte généralement le même nom que le plug-in. Les plug-ins complexes, tels que mk_oracle par exemple, créent même toute une série de nouvelles sections.

Certains plug-ins nécessitent un fichier de configuration dans /etc/check_mk/ pour fonctionner. Pour d’autres, la configuration est facultative et permet d’activer des fonctionnalités spéciales ou des personnalisations. D’autres encore fonctionneront tels quels. Il existe plusieurs sources d’informations sur un plug-in :

Les plug-ins d'agent sont généralement exécutés en séquence. Vous pouvez également choisir de faire exécuter les plug-ins de manière asynchrone. Ceci est très utile si les plug-ins ont une durée d'exécution longue et que les données d'état collectées n'ont de toute façon pas besoin d'être régénérées toutes les minutes.

L'exécution asynchrone ne se configure pas via un fichier ; vous devez plutôt créer un sous-répertoire dans /usr/lib/check_mk_agent/plugins dont le nom correspond à un nombre : un nombre de secondes. Les plug-ins de ce répertoire sont non seulement exécutés de manière asynchrone, mais vous spécifiez également un temps d'attente minimum en secondes avant que le plug-in ne soit à nouveau exécuté. Si l'agent est interrogé à nouveau avant l'expiration de ce délai, il utilise les données mises en cache lors de la dernière exécution du plug-in. Cela vous permet de configurer un intervalle plus long que la durée habituelle d'une minute pour le plug-in.

L'exemple suivant montre comment faire passer le plug-in « my_foo_plugin » d'une exécution synchrone à une exécution asynchrone avec un intervalle de 5 minutes (ou 300 secondes) :

Remarque : certains plug-ins implémentent automatiquement l'exécution asynchrone. C'est le cas notamment d'mk_oracle. Installez ces plug-ins directement dans l'/usr/lib/check_mk_agent/plugins.

Dans les éditions commerciales, les plug-ins inclus peuvent être configurés via Agent Bakery. Cela prend en charge à la fois l'installation du plug-in proprement dit et la création correcte de son fichier de configuration, si nécessaire.

Chaque plug-in est configuré via une règle d'agent. Vous trouverez les ensembles de règles appropriés dans Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins :

Les plug-ins d'agent étant des programmes exécutables, vous pouvez également les lancer manuellement à des fins de test et de diagnostic. Cependant, certains plug-ins nécessitent que l'agent définisse certaines variables d'environnement pour trouver leur fichier de configuration, par exemple. Définissez ces variables manuellement avant l'exécution :

Certains plug-ins utilisent également des options d'appel spéciales pour le débogage. Il vous suffit de consulter le fichier du plug-in.

Il existe deux bonnes raisons de continuer à utiliser les plug-ins Nagios sur Checkmk. Si vous avez migré votre surveillance d’une solution basée sur Nagios vers Checkmk, vous pouvez continuer à utiliser d’anciens plug-ins de vérification pour lesquels il n’existe pas encore d’équivalent Checkmk. Dans de nombreux cas, il s’agit de plug-ins développés en interne en Perl ou en shell.

La deuxième raison est la véritable surveillance de bout en bout. Supposons que vous disposiez d’un serveur Checkmk, d’un serveur web et d’un serveur de base de données répartis dans un grand centre de données. Dans un tel cas, les temps de réponse du serveur de base de données mesurés depuis le serveur Checkmk ne sont pas très significatifs. Il est bien plus important de connaître ces valeurs pour la connexion entre le serveur web et le serveur de base de données.

L'agent Checkmk fournit un mécanisme simple pour répondre à ces deux exigences : le Remote Plugin Executor de Checkmk, ou MRPE en abrégé. Ce nom est délibérément une analogie avec le NRPE de Nagios, qui y remplit la même fonction.

Le MRPE est intégré à l’agent et se configure à l’aide d’un simple fichier texte, que vous créez sous le nom /etc/check_mk/mrpe.cfg. Vous y spécifiez un appel de plugin par ligne, ainsi que le nom que vous souhaitez que Checkmk utilise pour le service qu’il crée automatiquement à cet effet. Voici un exemple :

Remarque : les plug-ins Nagios ne doivent pas être placés dans le répertoire /usr/lib/check_mk_agent/plugins. Ce répertoire est réservé aux plug-ins de l'agent. En dehors de ce répertoire, vous êtes libre de choisir l'emplacement de votre choix, à condition que l'agent puisse y trouver et y exécuter les plug-ins.

Si vous exécutez maintenant l'agent localement, vous trouverez une nouvelle section pour chaque plugin intitulée « <<mrpe>> », qui contient le nom, le code de sortie et la sortie du plugin. Vous pouvez vérifier cela à l'aide de la commande pratique suivante : grep

Les codes « 0 » et « 1 » dans la sortie correspondent aux codes de sortie des plug-ins et suivent le schéma conventionnel : 0 = OK, 1 = WARN, 2 = CRIT et 3 = UNKNOWN.

Le reste sera désormais effectué automatiquement par Checkmk. Une fois que vous aurez lancé une détection de services pour l'hôte, les deux nouveaux services apparaîtront comme disponibles. Cela ressemblera à ceci :

À propos, en raison de la syntaxe du fichier, le nom ne peut pas contenir d'espaces. Cependant, vous pouvez remplacer un espace par %20 en utilisant la même syntaxe que dans les URL (le code ASCII 32 pour l'espace correspond à l'hexadécimal 20) :

Notez que tous les plug-ins que vous répertoriez dans mrpe.cfg seront exécutés de manière synchrone, dans l'ordre. Pour cette raison, les plug-ins ne doivent pas avoir un temps d'exécution trop long. Si un plug-in prend trop de temps, l'exécution de tous les autres sera retardée. Cela peut entraîner un dépassement du délai d'attente pour l'exécution complète du script de l'agent et empêcher la surveillance fiable de l'hôte.

Si vous avez vraiment besoin de plug-ins dont l'exécution est plus longue, vous devriez les faire passer en exécution asynchrone, comme pour les plug-ins d'agent classiques, et ainsi éviter de tels problèmes. Pour ce faire, il suffit de spécifier une durée en secondes pendant laquelle un résultat calculé doit rester valide. Pour configurer un délai d'expiration de cinq minutes, définissez l'expression « (interval=300) » après le nom du service dans « mrpe.cfg » :

Cette fonctionnalité présente plusieurs avantages :

Cela vous permet donc d'exécuter des tests qui nécessitent un peu plus de temps de calcul ainsi que sur des intervalles plus longs, sans avoir à configurer quoi que ce soit sur le serveur Checkmk.

Les utilisateurs des éditions commerciales peuvent également configurer MRPE avec l'Agent Bakery. C'est l'ensemble de règles « Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks » qui s'en charge. Vous pouvez y configurer les mêmes éléments que ceux décrits ci-dessus. Le fichier « mrpe.cfg » sera alors généré automatiquement par l'Agent Bakery.

Les disques durs modernes sont presque toujours équipés de la technologie S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Ce système enregistre en continu des données sur l'état du disque dur ou du SSD, et Checkmk peut récupérer ces valeurs à l'aide du plug-in smart et en évaluer les plus importantes. Pour que le plug-in fonctionne après son installation, les conditions suivantes doivent être remplies :

Si ces conditions sont remplies et que le plug-in est installé, les données sont automatiquement récupérées et ajoutées à la sortie de l'agent. Dans Checkmk, vous pouvez ensuite activer directement les nouveaux services :

Comme le montre la capture d'écran, si cmd_timeout se produit occasionnellement, basculez le plug-in en exécution asynchrone à des intervalles de quelques minutes.

IPMI (Intelligent Platform Management Interface) est une interface de gestion du matériel qui permet également de surveiller le matériel. Checkmk utilise freeipmi à cette fin pour accéder directement au matériel sans passer par le réseau. freeipmi s’installe à partir des sources de paquets et est alors immédiatement prêt à l’emploi, de sorte que les données seront transmises dès le prochain appel de Checkmk.

Si l'freeipmi n'est pas disponible ou s'il existe d'autres raisons de ne pas l'installer, ipmitool peut également être utilisé. ipmitool est souvent déjà présent sur le système et il suffit de lui fournir un pilote de périphérique IPMI, tel que celui fourni par le paquet openipmi. Là encore, vous n'avez rien d'autre à faire après l'installation, et les données seront collectées automatiquement par Checkmk.

Pour le diagnostic des erreurs, vous pouvez également exécuter les outils manuellement dans un shell hôte. Une fois que vous avez installé le paquet freeipmi, vous pouvez vérifier ses fonctions à l'aide de la commande suivante :

Si ipmitool a été installé, vous pouvez vérifier la sortie de ses données à l'aide de la commande suivante :

De nombreux grands fabricants de serveurs proposent également leurs propres outils pour collecter les informations matérielles et les rendre disponibles via SNMP. Les conditions préalables suivantes doivent être remplies afin de récupérer ces données et de les fournir à Checkmk :

Les nouveaux services de surveillance matérielle pris en charge sont alors automatiquement détectés et aucun autre plug-in n’est nécessaire.

Une carte de gestion peut être configurée pour chaque hôte et des données supplémentaires peuvent être récupérées via SNMP. Les services ainsi détectés sont alors également attribués à l’hôte.

La configuration de la carte de gestion est très simple. Il suffit de saisir le protocole, l'adresse IP et les données d'accès pour SNMP dans les propriétés de l'hôte, puis d'enregistrer ces nouveaux paramètres :

Lors d’une découverte de services, les services nouvellement détectés seront ensuite activés comme d’habitude.

Lorsque l'agent est désinstallé, l'utilisateur cmk-agent créé par le script d'installation est conservé. Cela sert d'indicateur au script post-installation pour lui signaler que l'agent était déjà installé sur ce système. Si tel est le cas, le mode pull hérité ne sera pas activé lors d'une réinstallation ultérieure. Par conséquent, après avoir exécuté cmk-agent-ctl delete-all puis réinstallé l'agent, aucune connexion ne sera possible sur le port 6556.

Si vous souhaitez réactiver le mode pull hérité non chiffré, vous devrez activer explicitement ce mode.