 |
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
Pour qu’un système de supervision puisse recevoir davantage d’informations d’une ressource, au-delà du simple fait qu’elle soit accessible, l’aide du système cible est nécessaire. Par exemple, comment Checkmk pourrait-il savoir dans quelle mesure le volume de stockage d’un serveur est plein sans que ce système ne fournisse d’une manière ou d’une autre cette information ? Le composant qui fournit ces informations est toujours un logiciel actif, à savoir un agent de supervision , généralement appelé simplement « agent ». Un agent collecte les données pertinentes pour la supervision à partir d’un ordinateur hôte à des intervalles spécifiés et transmet ces données au serveur de supervision.
Pour les serveurs et les postes de travail, Checkmk fournit ses propres agents, appelés agents Checkmk. Les agents Checkmk sont disponibles pour une grande variété de systèmes d’exploitation — des plus courants comme Windows et Linux aux plus exotiques comme OpenVMS. En mode Pull, les agents sont passifs et écoutent sur le port TCP 6556. Ce n’est qu’à la réception d’une requête du serveur Checkmk que ces agents sont activés et répondent avec les données requises. En mode Push, en revanche, l’agent Checkmk envoie périodiquement de lui-même les données de supervision au serveur Checkmk.
Tous les agents Checkmk sont accessibles via l’interface web dans le menu «Setup». De là, vous pouvez télécharger les agents et les installer sur le système cible. Vous apprendrez comment installer, configurer et étendre les agents Checkmk dans cet article.
Il existe toutefois des situations où il n’est pas nécessaire d’installer un agent de supervision, car un agent utilisable est déjà présent. Le meilleur exemple est le SNMP : Tous les périphériques réseau gérables disposent d’un agent SNMP intégré. Checkmk accède à cet agent SNMP et récupère des informations sur l’état du système à l’aide de requêtes actives (GET).
Certains systèmes, cependant, ne permettent ni l'installation d'un agent, ni la prise en charge de SNMP sous une forme utilisable. À la place, ils proposent des interfaces de programmation d'applications pour la gestion, appelées API, basées sur Telnet, SSH ou HTTP/XML. Checkmk interroge ces interfaces via ces agents spéciaux fonctionnant sur le serveur Checkmk.
Enfin, la supervision des services réseau tels que HTTP, SMTP ou IMAP constitue un cas à part.
Dans le cas d’un service réseau, la procédure évidente consiste à interroger et à surveiller le service via le réseau.
Pour cela, Checkmk utilise parfois ses propres plug-ins, parfois des plug-ins déjà existants.
On parle également de contrôles actifs.
Par exemple, check_http est très populaire pour interroger des sites web.
Mais même dans ce cas, un agent supplémentaire est généralement utilisé pour fournir des données de serveur complémentaires à la supervision.
L'image suivante illustre les différentes façons dont Checkmk peut accéder aux systèmes à superviser :
Jusqu’à présent, nous n’avons abordé que la supervision active — la discipline phare de Checkmk. Il existe également la méthode inverse : celle par laquelle le système cible envoie lui-même des messages à la supervision, par exemple via syslog ou des traps SNMP. Pour ces fonctions, Checkmk dispose de sa Event Console, qui est décrite dans un article dédié.
2. L'agent Checkmk
Pour surveiller un serveur ou un poste de travail, vous avez besoin d'un petit programme qui doit être installé sur l'ordinateur hôte : l'agent Checkmk.
Cet agent est un simple script shell minimaliste, sécurisé et facilement extensible. Dans la version 2.1.0 de Checkmk, un nouveau composant, l’Agent Controller, a été ajouté à ce script de l'agent. L’Agent Controller est connecté en amont du script de l'agent, interroge ce dernier et communique à sa place avec le serveur Checkmk. Pour ce faire, le contrôleur s’enregistre auprès de l’Agent Receiver, qui s’exécute sur le serveur Checkmk.
Cette architecture est identique dans l’agent Linux et l’agent Windows ; seule la mise en œuvre technique est spécifique à chaque système d’exploitation.
Le script de l'agent est chargé de collecter les données de supervision et de les mettre à la disposition de l'Agent Controller. Ce script est :
minimaliste, car il utilise un minimum de RAM, de CPU, d'espace disque et de ressources réseau.
sécurisé, car il n'autorise aucun accès depuis le réseau.
facilement extensible, car vous pouvez écrire des plugins dans n'importe quel langage de programmation ou de script et les faire exécuter par le script de l'agent.
Le Agent Controller est le composant de l'agent chargé de transporter les données collectées par le script de l'agent. En mode Pull, il écoute sur le port TCP 6556 les connexions entrantes provenant de l'instance Checkmk et interroge le script de l'agent.
L'architecture logicielle de l'agent avec l'Agent Controller est la condition préalable à l'offre de nouvelles fonctions, qui n'auraient pas pu être réalisées avec la conception minimaliste du script de l'agent, telles que le chiffrement de la communication via Transport Layer Security (TLS), la compression des données et l'inversion du sens de communication du mode Pull vers le mode Push.
En mode Pull, le serveur Checkmk initie la communication et demande les données à l’agent. En mode Push, l’initiative vient de l’agent. Le mode Push est requis pour une configuration basée sur le cloud et dans certains réseaux compartimentés. Dans les deux cas, le serveur Checkmk ne peut pas accéder au réseau où se trouvent les ordinateurs hôtes à surveiller. L’agent transmet donc automatiquement les données au serveur Checkmk à intervalles réguliers.
L'Agent Receiver est le composant du serveur Checkmk qui sert de ressource générale pour la communication avec l'Agent Controller, par exemple pour enregistrer la connexion et pour recevoir les données envoyées par l'Agent Controller en mode Push. En mode Push, les données reçues sont stockées par l’Agent Receiver dans le système de fichiers et sont ainsi mises à la disposition des fetchers du site. Dans les éditions commerciales, il s’agit des récupérateurs de données Checkmk. En revanche, en mode Pull, l’échange de données s’effectue directement entre les fetchers du site et l’Agent Controller sans nécessiter d’Agent Receiver.
Le chiffrement TLS et la compression des données sont assurés par l’Agent Controller et l’Agent Receiver. C’est pourquoi le serveur Checkmk et l’agent doivent être au moins en version 2.1.0. La première étape après l’installation consiste à enregistrer l’Agent Controller auprès de l’Agent Receiver de l’instance Checkmk, ce qui établit une relation de confiance entre ces deux composants. Le chiffrement TLS de la communication sera configuré lors de cet enregistrement. Pour le mode Push, le serveur Checkmk et l’agent doivent être au moins en version 2.2.0.
Le tableau suivant résume les différentes fonctions de l'agent Checkmk et indique dans quelles éditions de Checkmk ces fonctions sont disponibles :
| Fonction | Description | Disponibilité |
|---|---|---|
Enregistrement |
La relation de confiance entre l'Agent Controller sur l'ordinateur hôte et l'Agent Receiver sur l'instance Checkmk est établie. |
Toutes les éditions |
Cryptage TLS |
Une fois l'enregistrement effectué, les données sont échangées sous forme chiffrée à l'aide du protocole TLS. |
Toutes les éditions |
Compression |
Les données sont échangées sous forme compressée. |
|
Mode Pull |
L'agent envoie les données à la demande de l'instance Checkmk. |
|
Mode Push |
L'agent envoie les données à l'instance Checkmk de manière autonome. |
Checkmk Ultimate |
Configuration individuelle des agents |
Grâce à la boulangerie d’agents, les agents peuvent être configurés individuellement pour un ou plusieurs ordinateurs hôtes, et les paquets d'agents peuvent être créés en vue de leur installation. |
Éditions commerciales |
Le paquet provenant de la boulangerie d’agents est d’abord installé manuellement ou via un script, puis mis à jour automatiquement par la suite. |
||
L'enregistrement de l'agent Checkmk sur l'instance Checkmk et la création de l'ordinateur hôte s'effectuent automatiquement. |
Checkmk Ultimate |
3. Téléchargement de l'agent depuis la page de téléchargement
Le projet Checkmk prend actuellement en charge des agents pour onze familles de systèmes d'exploitation différentes. Tous ces agents sont des composants de Checkmk et peuvent être téléchargés via l'interface web du serveur Checkmk. Ces agents sont accessibles via Setup > Agents.
Dans 
Checkmk Community, les entrées « Linux », « Windows » et « Other operating systems » vous mènent directement aux pages de téléchargement où vous trouverez les agents préconfigurés et les plugins d’agent. Dans l’exemple suivant, cela vous redirige vers la page de téléchargement de Linux, Solaris, AIX :
Dans les éditions commerciales, l'entrée « Windows, Linux, Solaris, AIX » vous redirige vers une page qui vous donne également accès à la boulangerie d’agents. À partir de cette page, l'entrée « Related » vous redirigera vers les pages des fichiers d'agents, comme dans Checkmk Community.
Les agents packagés pour Linux (aux formats RPM et DEB) et pour Windows (au format MSI) se trouvent dès la première case de la page de téléchargement correspondante. Dans ces paquets logiciels, vous trouverez l’agent avec Agent Controller depuis la version 2.1.0. L’installation et la configuration sont décrites en détail dans les articles sur les agents Linux et les agents Windows.
Dans la section « Agents », vous trouverez les scripts de l'agent appropriés pour les différents systèmes d'exploitation. Pour les systèmes d'exploitation sur lesquels l'agent doit être configuré en mode legacy (c'est-à-dire sans Agent Controller), consultez les articles « Supervision de Linux en mode legacy » et « Supervision de FreeBSD ».
4. Boulangerie d’agents
4.1. Introduction
Si vous utilisez l'une des éditions commerciales, vous pouvez créer des agents personnalisés à l'aide de la boulangerie d’agents.
De cette manière, en plus des agents existants, vous pouvez également créer (ou « cuire ») des paquets d'agents contenant des configurations personnalisées et des plugins supplémentaires ou optionnels.
Vous pouvez installer ces paquets à l'aide d'une seule instruction.
Ces paquets sont parfaits pour la distribution et l'installation automatiques.
Vous pouvez même créer des agents personnalisés pour des dossiers ou des groupes spécifiques d'ordinateurs hôtes.
Cela offre une grande flexibilité grâce à l’utilisation des mises à jour automatiques des agents.
S’il est vrai que l’agent Checkmk peut fonctionner « tel quel » immédiatement — sans nécessiter de configuration et sans plugins —, il arrive néanmoins que l’agent doive être configuré. Quelques exemples :
Restriction de l'accès à des adresses IP spécifiques
Supervision des bases de données Oracle (un plugin et une configuration sont requis)
Supervision des fichiers journaux texte (un plugin, des noms de données et des modèles de texte sont requis)
Utilisation de l'inventaire matériel/logiciel (un plugin est requis)
 |
Une révision de « bake » consécutive peut être générée pour chaque processus de « bake » afin de distinguer les différents processus. Ceci n’est visible que dans les métadonnées du paquet « baked ». À partir de la version Checkmk 2.3.0, cette fonction est désactivée par défaut afin d’éviter que les agents « baked » ne perdent leur signature valide. Si vous souhaitez tout de même activer la révision de bake, par exemple pour un traitement unique dans un gestionnaire de packs, activez l’option « Setup > Global settings > Setup > Apply bake revision ». Et si cette option est activée : pour les agents bake automatiquement ultérieurement via la règle « Automatically create monitoring agents », la révision précédente est conservée dans tous les cas et n’est pas incrémentée davantage — là encore, afin de ne pas perdre la signature. Si vous avez besoin d’agents bake automatiquement avec des révisions consécutives, vous devriez utiliser l’API REST à la place de la règle, par exemple. |
4.2. Téléchargement de l'agent
Vous pouvez accéder à la boulangerie d’agents via Setup > Agents > Windows, Linux, Solaris, AIX :
Checkmk prend en charge les systèmes d'exploitation Windows, Linux, Solaris et AIX avec la boulangerie d’agents.
Pour Linux, vous avez le choix entre les formats de paquets RPM (pour les systèmes basés sur Red Hat Enterprise Linux (RHEL), SLES) et DEB (pour Debian, Ubuntu),
ainsi qu'un « tarball » au format de fichier TGZ qui se décompresse simplement à l'adresse root sous /.
De même, un fichier tarball est disponible pour AIX, mais celui-ci n’inclut pas l’intégration automatique dans l’inetd.
L’intégration doit être effectuée manuellement en une seule opération.
Pour Solaris, il existe à nouveau le fichier tarball et un paquet PKG.
Si vous n’avez encore défini aucun paramètre pour des ordinateurs hôtes spécifiques, il n’existe qu’une seule configuration d’agent par défaut. Une explication des différentes configurations d’agent possibles sera fournie dans les deux sections suivantes.
Chaque configuration d’agent possède un identifiant explicite : son hhash Les huit premiers caractères de ce hachage s’affichent dans l’interface graphique. Ce hachage fera partie de la version du paquet et sera intégré au nom du fichier du paquet. Chaque fois que vous modifiez la configuration d’un paquet ou que vous mettez à jour Checkmk, le hachage du paquet est également modifié. De cette manière, le gestionnaire de packs du système d’exploitation reconnaît qu’il s’agit d’un paquet différent et procède à une mise à jour. Le numéro de version de Checkmk ne suffirait pas à faire la distinction dans ce cas.
Les paquets précompilés pour Linux et Windows s’installent de la même manière que les paquets disponibles sur la page de téléchargement de Checkmk.
4.3. Configuration à l’aide de règles
La configuration de l’agent peut être modifiée — comme c’est souvent le cas dans Checkmk — via des règles. Celles-ci vous offrent la possibilité de doter différents ordinateurs hôtes de paramètres ou de plugins différents. Le bouton « Agent rules » vous mène à une page qui répertorie tous les jeux de règles affectant les agents :
Prenons l’exemple suivant : vous souhaitez limiter la liste des adresses IP autorisées à accéder à l’agent. Pour cela, sélectionnez le jeu de règles « Generic Options > Allowed agent access via IP address (Linux, Windows) ». Saisissez une ou plusieurs adresses IP comme valeur de la règle :
Laissez les valeurs par défaut dans la case « Conditions » inchangées afin que cette règle s'applique à tous les ordinateurs hôtes. Enregistrez la nouvelle règle.
4.4. Les configurations de l'agent
Après avoir enregistré, revenez à la page d’Windows, Linux, Solaris, AIX.
Le bouton « 
» garantit que l’agent sera entièrement réinitialisé.
Résultat : vous disposez désormais de deux configurations distinctes :
Dans la colonne « Agent type », vous pouvez voir à quels ordinateurs hôtes la configuration correspondante est attribuée. Pour des raisons d’espace, cette liste peut ne pas être exhaustive.
Vanilla (factory settings) |
Les paquets d'agents ne contiennent que la configuration par défaut et donc aucune règle d'agent individuelle. |
Folders |
Les paquets d’agents contiennent toutes les règles d’agent pour lesquelles aucune condition n’est définie pour les ordinateurs hôtes et qui s’appliquent aux dossiers répertoriés. |
Hosts |
Les paquets d'agents contiennent toutes les règles d'agent qui s'appliquent aux ordinateurs hôtes de la liste. |
Dans l'exemple ci-dessus, la règle « Allowed agent access via IP address (Linux, Windows) » a été créée sans conditions pour les ordinateurs hôtes.
La nouvelle configuration d'agent s'applique donc au dossier « Main » et à « localhost », qui est actuellement le seul ordinateur hôte de l'instance.
Plus vous déployez de règles spécifiques à un hôte, plus le nombre de variantes d’agents générées sera important. La boulangerie d’agents veille à ne générer que les configurations utilisées par au moins un des dossiers ou hôtes existants.
À ce propos, vous pouvez également accéder facilement aux paquets d’agents d’un ordinateur hôte via les propriétés de celui-ci en cliquant sur l’ordinateur hôte dans Setup > Hosts > Hosts et en sélectionnant Monitoring agent dans le menu Hosts :
Pourquoi des paquets pour tous les systèmes d'exploitation sont-ils fournis pour chaque ordinateur hôte ? La réponse est très simple : si aucun agent n'est installé sur un système, Checkmk ne peut bien sûr pas reconnaître le système d'exploitation. Dans tous les cas, une fois les mises à jour automatiques des agents activées, vous n'avez plus rien à faire.
4.5. Extension via des plugins
De nombreuses règles concernent l'installation de divers plugins. Ceux-ci étendent les capacités de l'agent pour la supervision de composants très spécifiques. La plupart d'entre eux sont des applications spécialisées, telles que des bases de données, par exemple. À côté de la règle qui active un plugin, vous trouverez également les paramètres permettant de configurer ce dernier. Voici, par exemple, la règle pour la supervision de MySQL :
4.6. Fichiers de configuration
Veillez à ne pas modifier manuellement les fichiers de configuration générés par la boulangerie d’agents sur le système cible. Bien que les modifications manuelles fonctionnent pour l'instant, elles seront perdues lors de la prochaine mise à jour de l'agent. Il est toutefois possible d'installer des plugins et des fichiers de configuration supplémentaires sans problème.
4.7. Activer la journalisation
Dans les paramètres globaux, vous pouvez activer la journalisation pour les processus de l'Agent Bakery sous « Agent bakery logging ».
Les résultats se trouvent dans le fichier « ~/var/log/agent_bakery.log ».
Si la journalisation n'est pas activée, vous ne verrez ces informations que si vous effectuez la « cuisson » des agents avec l'option « cmk --bake-agents -v » sur la ligne de commande.
5. Quand faut-il mettre à jour un agent ?
Que vous surveilliez seulement quelques ordinateurs hôtes — voire des milliers —, la mise à jour de l'agent Checkmk sur tous les ordinateurs hôtes constitue toujours une opération de grande envergure. La mise à jour automatique de l'agent dans les éditions commerciales est toutefois d'une grande aide. Néanmoins, vous ne devriez vraiment mettre à jour l'agent que lorsque :
la mise à jour résout un problème qui vous concerne, ou
la mise à jour inclut de nouvelles fonctionnalités indispensables.
Pour que cela soit possible, une règle générale s’applique dans Checkmk : les versions plus récentes de Checkmk peuvent en principe traiter les données de sortie des agents plus anciens.
Important : l'inverse n'est pas nécessairement vrai. Si la version Checkmk d'un agent est plus récente que celle du serveur de supervision, il est possible que les plugins de supervision ne puissent pas interpréter correctement les données de sortie de l'agent. Dans un tel cas, les services concernés passent à l'état UNKNOWN :
Même si la sortie illustrée dans l'image ci-dessus suggère le contraire, veuillez ne pas envoyer de rapport de plantage dans un tel cas.
6. Diagnostic des erreurs
6.1. Test de l'agent via la ligne de commande
Un agent correctement installé peut être très facilement interrogé depuis la ligne de commande.
La meilleure façon de procéder consiste à le faire directement depuis l’instance Checkmk qui surveille également activement l’agent.
De cette manière, vous pouvez être certain que l’adresse IP du serveur sera acceptée par l’agent.
Les instructions appropriées sont par exemple telnet et netcat (ou nc).
La sortie de la commande 16 indique que la connexion établie via le port TCP 6556 a abouti et que la négociation TLS peut désormais avoir lieu.
L'agent a été enregistré sur l'instance Checkmk via l'Agent Controller ; la communication est donc chiffrée par TLS et aucune sortie de l'agent ne s'affichera.
Pour plus de détails sur l'enregistrement, consultez les articles consacrés à l'agent Linux et à l'agent Windows.
Si la communication entre l'agent et le serveur Checkmk n'est toujours pas chiffrée (comme en mode legacy pull) ou si elle est et reste non chiffrée (comme en mode legacy) , cette instruction vous fournira la sortie complète non chiffrée de l'agent au lieu de l'16 (dont seules les premières lignes sont affichées ci-dessous) :
La sortie commence toujours par la ligne « <<<check_mk>>> ».
Les lignes figurant dans « <<< » et « >>> » sont appelées en-têtes de section.
Celles-ci divisent la sortie de l'agent en sections.
Chaque section contient des informations connexes et correspond généralement à la sortie d'une instruction de diagnostic.
La section « check_mk » joue un rôle particulier.
Elle contient des informations générales sur l'agent, telles que son numéro de version.
Si l'ordinateur hôte est déjà sous supervision, vous pouvez également récupérer les données à l'aide de l'instruction cmk -d.
Celle-ci utilise l'adresse IP configurée dans Setup, prend en compte un numéro de port éventuellement reconfiguré, ainsi que tout agent spécial éventuellement présent :
Avec les options --debug -v, vous pouvez en outre obtenir des informations de débogage.
Si la supervision est déjà en cours d'exécution régulière pour l'ordinateur hôte en question, une copie actuelle de la sortie est toujours disponible dans le répertoire d'instances ~/tmp/check_mk/cache :
|
Pour plus d'informations sur les autres instructions de diagnostic pouvant être exécutées sur l'ordinateur hôte de l'agent, consultez les articles consacrés à l'agent Linux et à l'agent Windows. |
6.2. Test de l'agent via l'interface web
Vous pouvez également effectuer un diagnostic de l'agent via l'interface web. Ce diagnostic prend en compte tous les paramètres et prend également en charge les périphériques SNMP ainsi que ceux interrogés à l'aide d'agents spéciaux. En effet, Checkmk tente toujours d'interroger simultanément via le port TCP 6556 et SNMP.
Vous pouvez accéder au test de connexion via les propriétés de l'ordinateur hôte : Sur la page « Properties of host », sélectionnez « Host > Connection tests » dans le menu, puis lancez le test en cliquant sur « Run tests » :
Vous pouvez tester immédiatement plusieurs de ces paramètres (par exemple, la communauté SNMP) et les enregistrer une fois qu’ils ont été validés.