 |
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 les environnements cloud et de conteneurs, il est de plus en plus courant que les ordinateurs hôtes surveillés apparaissent et disparaissent automatiquement. Maintenir la configuration de supervision à jour manuellement n’est plus une option viable. Cependant, même les infrastructures classiques telles que les clusters VMware peuvent être très dynamiques, et même si la maintenance manuelle n’est pas envisageable dans ce cas, il est toujours possible de maintenir la configuration à jour manuellement.
Les éditions commerciales de Checkmk vous assistent
grâce à un outil intelligent : la gestion dynamique des hôtes.
La gestion dynamique des hôtes utilise les informations issues de la supervision d’Amazon Web Services (AWS), de Microsoft Azure, de Kubernetes, de VMware ESXi et d’autres sources pour ajouter automatiquement des hôtes à la supervision — ainsi que pour les supprimer lorsqu’ils ne sont plus nécessaires.
La gestion dynamique des hôtes est générique et ne se limite pas à la création d’hôtes. Elle constitue la base des futures extensions de Checkmk qui permettront d’ajuster dynamiquement la configuration. À cette fin, la gestion dynamique des hôtes fonctionne avec des connexions. Chaque connexion peut récupérer des informations à partir d’un type de source spécifique et dispose de sa propre configuration dédiée à cet effet.
Le Dynamic Configuration Daemon (DCD) est le composant logiciel qui assure la gestion dynamique des hôtes. L'architecture logicielle du DCD a été entièrement repensée dans la version 2.4.0 de Checkmk afin de répondre aux exigences des environnements de grande envergure et hautement dynamiques, et de garantir un traitement stable et sécurisé. La collecte d'informations à partir des connexions configurées est désormais dissociée des modifications de configuration qui en résultent dans Checkmk. Les modifications de configuration en attente sont organisées en files d'attente et traitées séquentiellement par cycles, ce qui garantit un traitement stable et sécurisé. Les paramètres du gestionnaire de gestion des hôtes vous offrent des options pour personnaliser les cycles de traitement. Pour plus d'informations, consultez le chapitre Configuration.
2. Types de connexion
En configurant une connexion dans la gestion dynamique des hôtes, vous pouvez ajouter automatiquement des hôtes à la supervision et les supprimer tout aussi automatiquement, de sorte à disposer en permanence d’une vue d’ensemble en temps réel de la situation. Pour ce faire, la gestion dynamique des hôtes analyse les données existantes, compare les hôtes déjà présents dans l’environnement de configuration et crée les hôtes manquants ou supprime ceux qui ne sont plus présents. Par la suite, une reconnaissance du service est (facultativement) effectuée sur les ordinateurs hôtes, puis les modifications sont activées afin que l'état actuel puisse être visualisé dans l'environnement de supervision.
2.1. Connexion ferroutage
La connexion Piggyback sert à évaluer — sans surprise — les données ferroutées. Ce type de connexion peut être utilisé de manière universelle dans Checkmk, car le mécanisme de ferroutage est utilisé par Checkmk dans toutes les situations où une requête adressée à un ordinateur hôte (généralement via un agent spécial) fournit des données sur d’autres ordinateurs hôtes (généralement des machines virtuelles ou des objets cloud).
Checkmk utilise le ferroutage, par exemple, pour surveiller Proxmox, Docker, VMware ESXi et les hyperscalers AWS, Azure et GCP. Dans tous ces cas, la supervision récupère automatiquement des données provenant d’autres hôtes, tels que des machines virtuelles (VM), qui ne sont pas directement accessibles via le réseau et sur lesquels aucun agent Checkmk n’a besoin d’être exécuté. Vous pouvez inclure automatiquement ces hôtes dans la supervision et les supprimer à nouveau. Les ordinateurs hôtes créés automatiquement peuvent toujours être édités manuellement dans l'interface graphique d'Setup.
La seule condition requise pour utiliser une connexion de ferroutage est la présence de données ferroutées. Vous en disposerez toujours si vous avez configuré la supervision pour AWS, Azure et d’autres plateformes comme décrit dans ce guide de l’utilisateur.
Vous pouvez également vérifier facilement la présence de données ferroutées depuis la ligne de commande, car ces données sont créées par Checkmk dans le répertoire ~/tmp/check_mk/piggyback/ :
Si ce répertoire n'est pas vide, des données ferroutées ont été générées sur ce site.
2.2. Connexion OpenTelemetry
L'2.4.0 Checkmk propose, dans la version 
Checkmk Ultimate, une prise en charge expérimentale du traitement des métriques OpenTelemetry.
Pour ce faire, un collecteur OpenTelemetry dans Checkmk recueille les données métriques que le collecteur reçoit via le protocole OpenTelemetry (OTLP) ou récupère via une ressource Prometheus.
Lors de la configuration du collecteur, des règles sont également définies pour générer des noms de domaine pour Checkmk à partir des données.
Une fois configuré, le collecteur commence à collecter les données et les stocke sur l'instance Checkmk avec des noms de fichiers correspondant aux noms de domaine.
La configuration d'OpenTelemetry, y compris le collecteur OpenTelemetry, est décrite dans l'article « Supervision des métriques OpenTelemetry ».
Les données OpenTelemetry sont toujours disponibles sur l'instance si le collecteur OpenTelemetry a été correctement configuré. Vous pouvez le vérifier via la ligne de commande, car les données OpenTelemetry sont stockées dans le répertoire ~/tmp/check_mk/otel_collector/ :
Si ce répertoire n'est pas vide, cela signifie que des données OpenTelemetry ont été générées sur cette instance.
3. Configuration d'une connexion
Ouvrez la page de gestion dynamique des hôtes à l'adresse Setup > Hosts > Dynamic host management :
Créez une nouvelle connexion à l'aide de Add connection.
3.1. Propriétés générales
La première partie de la configuration concerne l'General properties :
Comme c'est souvent le cas, vous attribuez ici un identifiant unique et un titre à cette connexion.
Sous « Site », vous devez sélectionner l'instance Checkmk sur laquelle les données sont générées.
Le terme « générées » fait ici référence à l'instance sur laquelle les données sont stockées dans le répertoire ~/tmp/check_mk/ pour le type de connexion concerné.
Dans la plupart des cas, un agent spécial se charge du stockage des données.
Étant donné que les données ne peuvent être traitées que localement sur une instance spécifique, la connexion doit être attribuée à cette instance. Dans le cadre d’une supervision distribuée avec configuration centralisée, vous devez donc spécifier le site sur lequel les données — qu’il s’agisse de données ferroutées ou de données provenant d’autres sources — doivent être collectées puis traitées. Ici, vous ne déterminez pas sur quel site les ordinateurs hôtes doivent être créés. Vous spécifiez cela dans l’Host attributes to set à l’aide de l’attribut d’hôte Basic settings: Monitored on site. La connexion est ensuite attribuée à l’hôte.
3.2. Propriétés d’une connexion de ferroutage
La deuxième partie concerne les propriétés de la connexion (Connection properties). Comme il y a beaucoup de paramètres à configurer ici, nous allons passer en revue les options une par une.
Pour une connexion de ferroutage, sélectionnez Piggyback data comme Connector type.
Avec la gestion dynamique des hôtes, vous pouvez limiter cette connexion à des hôtes spécifiques en tant que sources. Il s'agit généralement des hôtes pour lesquels un agent spécial a été configuré. La gestion dynamique des hôtes n'est active que pour ces hôtes. La restriction s'effectue dans le champ de saisie correspondant, dont le contenu est interprété comme une expression régulière. Une fois que vous avez modifié le premier champ de saisie, le suivant s'ouvre automatiquement, ce qui signifie que vous pouvez spécifier plusieurs expressions régulières.
Avec l'Sync interval, vous pouvez déterminer la fréquence à laquelle la connexion doit rechercher de nouveaux ordinateurs hôtes. Si vous avez conservé l'intervalle de vérification standard d'une minute, il est inutile de le faire beaucoup plus fréquemment, car les données ne peuvent changer qu'une fois par minute au maximum. Dans des environnements plus dynamiques, vous pouvez définir à la fois l'intervalle de vérification et l'intervalle de connexion sur des valeurs nettement plus faibles. Cependant, cela entraîne également une charge de travail plus importante sur le serveur Checkmk.
Au moins une entrée doit exister sous Piggyback creation options. Vous pouvez également en ajouter d'autres à l'aide de Add new entry :
Cette section traite des propriétés des ordinateurs hôtes générés automatiquement, pour lesquels vous pouvez spécifier deux éléments importants : Le dossier dans lequel les ordinateurs hôtes doivent être créés (Create hosts in) et les attributs d'ordinateur hôte à définir. Quatre attributs importants sont prédéfinis, qui sont généralement utiles pour les hôtes ferroutés :
Pas de supervision via SNMP.
Pas d'agent Checkmk sur l'ordinateur hôte lui-même (les données proviennent du ferroutage).
Les données ferroutées sont toujours attendues (et une erreur se produit si elles manquent).
Les ordinateurs hôtes n'ont pas d'adresse IP.
Si vous souhaitez utiliser les données ferroutées sur une autre instance, activez l'option « Add attribute », puis l'option « Basic settings: Monitored on site » et spécifiez l'instance souhaitée.
Ce n'est que si vous cochez la case à cocher « Delete vanished hosts » que les ordinateurs hôtes seront à nouveau supprimés s'ils ont disparu de votre environnement dynamique. Si vous ne souhaitez pas créer automatiquement tous les ordinateurs hôtes ferroutés, vous pouvez limiter cette opération à l'aide de l'option « Only add matching hosts » en utilisant une expression régulière.
Dans la troisième et dernière partie des propriétés de connexion, vous pouvez spécifier qu’une reconnaissance du service soit effectuée sur les ordinateurs hôtes générés automatiquement en cochant la case à cocher « Service discovery » :
Les trois options restantes concernent la suppression des ordinateurs hôtes créés automatiquement, un thème qui est expliqué en détail dans un chapitre séparé.
L'option « Prevent host deletion after initialization » entraîne un redémarrage complet du serveur Checkmk lui-même. Dans ce cas, les données de tous les ordinateurs hôtes seront initialement manquantes jusqu’à ce qu’elles aient été interrogées pour la première fois. Afin d’éviter la suppression et la réapparition inutiles d’ordinateurs hôtes (qui s’accompagnent également de notifications répétées de problèmes déjà connus), la suppression n’est généralement pas effectuée pendant les 10 premières minutes par défaut. Vous pouvez définir cette durée ici.
L'option « Validity of missing data » traite le cas où un hôte, à partir des données de supervision duquel plusieurs hôtes ont été créés automatiquement, ne fournit plus de données ferroutées. Cela peut être le cas, par exemple, si l'accès à AWS et autres ne fonctionne plus. Ou, bien sûr, si vous avez supprimé l'agent spécial de la configuration. Les hôtes générés automatiquement resteront alors dans le système pendant la durée définie avant d'être supprimés de l'interface graphique d'Setup.
L'option « Validity of outdated data » (Supprimer les objets après 30 jours) est similaire, mais concerne le cas où les données continuent d'arriver, mais plus pour certains ordinateurs hôtes. C'est le cas habituel lorsque, par exemple, des machines virtuelles ou des services cloud ne sont plus disponibles. Si vous souhaitez que les objets correspondants disparaissent rapidement de Checkmk, définissez ici une période de temps suffisamment courte.
3.3. Propriétés d'une connexion OpenTelemetry
Les options de création d’une connexion de ferroutage et d’une connexion OpenTelemetry, qui peuvent être configurées dans Checkmk Ultimate, sont presque identiques. Nous vous proposons donc un bref aperçu des propriétés d’une connexion OpenTelemetry.
Pour une connexion OpenTelemetry, sélectionnez « Opentelemetry collector data » comme « Connector type ».
Utilisez « Sync interval » pour déterminer la fréquence à laquelle la connexion doit rechercher de nouveaux ordinateurs hôtes.
Sous « Open telemetry hosts creation options », indiquez le dossier dans lequel les ordinateurs hôtes doivent être créés (Create hosts in) et les attributs d’ordinateur hôte à définir. Deux attributs sont prédéfinis :
Seules les données fournies via les intégrations API sont utilisées pour la supervision.
Les ordinateurs hôtes ne disposent pas d’adresse IP.
Ce n’est que si vous cochez la case à cocher sous « Delete vanished hosts » que les ordinateurs hôtes seront supprimés s’ils ont disparu de votre environnement dynamique. Si vous ne souhaitez pas que tous les ordinateurs hôtes soient créés automatiquement, vous pouvez limiter cette opération à l’aide de l’option « Only add matching hosts » en utilisant une expression régulière.
En cochant la case sous « Service discovery », vous spécifiez que la reconnaissance du service est effectuée sur les ordinateurs hôtes générés automatiquement. Toutefois, cela ne donne le résultat souhaité que si un agent spécial pour OpenTelemetry est configuré.
Les deux dernières options, « Prevent host deletion after initialization » et « Validity of outdated data », ont une incidence sur la suppression des ordinateurs hôtes créés automatiquement. Ces options fonctionnent comme décrit dans la section consacrée au ferroutage. La suppression des ordinateurs hôtes créés automatiquement est expliquée en détail dans un chapitre distinct.
3.4. Enregistrement de la connexion
Une fois enregistrée, la connexion apparaîtra dans la liste des connexions. Cependant, elle ne peut être exécutée qu’après l’activation des modifications. Ce n’est qu’alors que la connexion commencera à fonctionner.
Ne vous laissez donc pas induire en erreur par le message qui s'affiche initialement dans la colonne «Status
» après l'enregistrement : «
Connection 'my_connection' isn’t found: consider activating changes
»
3.5. Activation de la connexion
Après avoir enregistré les propriétés de la connexion et activé les modifications, la connexion commencera automatiquement à fonctionner. Si des données sont déjà disponibles pour cette connexion et que vous attendez que les ordinateurs hôtes correspondants soient générés, vous verrez bientôt une entrée correspondante dans la liste sous « Recent processing cycles », qui pourrait ressembler à ceci :
Dans l'image d'exemple, vous pouvez voir que cette exécution est presque terminée et qu'au moins 50 ordinateurs hôtes seront créés à la fin. Si vous actualisez cette page peu après, ces modifications auront probablement déjà été automatiquement activées par la gestion dynamique des hôtes. Le résultat du traitement de l'exemple ci-dessus ressemblera alors à ceci :
Les nouveaux ordinateurs hôtes seront alors déjà sous supervision et feront l'objet d'un suivi régulier.
La liste « Recent processing cycles » (Cycles en cours) affichera les cycles sur une période de temps plus longue qui ont effectivement entraîné des modifications.
Les cycles de la connexion qui n’ont entraîné aucune modification seront masqués après quelques secondes.
Pour les consulter malgré tout, cliquez sur le symbole de l’horloge 
dans la colonne « Actions » (Historique des cycles), ce qui vous mènera à l’« Execution history of this connection » (Historique d’exécution).
3.6. Actions pour une connexion
Pour chaque connexion, la liste des connexions dans la colonne « Actions » affiche des icônes permettant d'effectuer des actions :
Certaines des icônes suivantes ne s’affichent que pour une connexion activée :
| Icône | Action |
|---|---|
|
Ouvre la connexion pour l'édition. |
|
Clone la connexion et l'ouvre pour édition. |
|
Affiche la liste des ordinateurs hôtes créés par cette connexion. |
|
Affiche l'historique d'exécution de la connexion. |
|
Affiche l'état de la gestion dynamique des hôtes, c'est-à-dire les cycles de traitement en cours. |
|
Exécute la connexion sans attendre le prochain cycle de traitement. |
|
Montre comment la connexion peut être créée à l'aide de l'API REST Checkmk. |
|
Supprime la connexion après confirmation. |
4. Suppression automatique des ordinateurs hôtes
Comme mentionné ci-dessus, les ordinateurs hôtes qui « n'existent plus » peuvent être automatiquement supprimés de la supervision grâce à la gestion dynamique des hôtes. À première vue, cela semble très logique ; cependant, la signification exacte de « n'existent plus » est un peu plus complexe lorsqu'on y réfléchit, car il existe divers cas de figure à prendre en compte.
Dans l'aperçu suivant, nous partons du principe que vous avez activé l'option sous Delete vanished hosts pour la connexion. Sinon, les ordinateurs hôtes ne seront jamais supprimés automatiquement.
| Situation | Que se passe-t-il ? |
|---|---|
Une connexion est supprimée. |
Si vous désactivez une connexion (via do not activate this connection dans l’General properties) ou si vous la supprimez complètement, tous les ordinateurs hôtes créés par cette connexion sont conservés. Si nécessaire, vous devez les supprimer manuellement. |
Un hôte ferrouté n'est plus supervisé. |
Si vous supprimez un hôte ferrouté que vous utilisez pour surveiller votre environnement cloud ou de conteneurs, celui-ci ne générera bien sûr plus de données ferroutées. Dans ce cas, les hôtes ferroutés générés automatiquement sont, par défaut, supprimés automatiquement au bout d’une heure. Vous pouvez ajuster cette durée à l’aide de l’option « Validity of missing data ». |
Un hôte ferrouté n'est pas accessible. |
Si votre environnement cloud est indisponible et que le service Check_MK qui l'interroge renvoie la réponse « CRIT », les ordinateurs hôtes générés automatiquement restent sous supervision indéfiniment. Il n'y a pas de timeout d'une heure dans ce cas ! |
Un ordinateur hôte créé automatiquement n'est plus inclus dans les données. |
C'est pratiquement la norme dans un environnement cloud/conteneur. Dans ce cas, par défaut, l'ordinateur hôte est automatiquement supprimé après une minute. Vous pouvez ajuster la période de temps à l'aide de l'option Validity of outdated data. |
Le serveur Checkmk lui-même est arrêté. |
L'arrêt de toute la supervision entraîne certes une obsolescence des données, mais les ordinateurs hôtes existants ne sont bien sûr pas supprimés pour autant. Il en va de même lors du redémarrage du serveur Checkmk (ce qui entraîne temporairement la perte de toutes les données, celles-ci étant stockées sur le disque RAM). |
Notez qu’avec la règle « Automatic host removal », il est possible que tous les ordinateurs hôtes soient automatiquement supprimés. Les deux options de lifecycle management fonctionnent indépendamment l’une de l’autre, c’est-à-dire qu’un ordinateur hôte est supprimé si l’une des deux conditions est remplie.
5. Configuration
Les paramètres du gestionnaire d'hôtes vous permettent de personnaliser les cycles de traitement de la gestion dynamique des hôtes. Vous pouvez accéder au dialogue via Setup > Hosts > Dynamic host management > Host manager settings :
Les paramètres par défaut sont déjà sélectionnés ici de manière à fonctionner correctement, même dans des environnements de grande taille et extrêmement dynamiques. Toutefois, si votre environnement subit de nombreux changements à chaque minute, ceux-ci créeront une certaine charge sur votre serveur Checkmk. Afin de mieux contrôler cette charge, les paramètres de gestion des hôtes ont été introduits avec la version 2.4.0 de Checkmk.
Le fonctionnement précis de chaque option est déjà décrit en détail dans l’aide en ligne et ne sera donc pas répété ici. Dans ce qui suit, nous décrivons les trois domaines et leurs fonctions.
Host processing Il s'agit de rechercher et d'attribuer des données spécifiques à un ordinateur hôte à partir des données disponibles. Cela permet de répondre à des questions telles que : de nouvelles données ont-elles été trouvées et faut-il créer des ordinateurs hôtes pour ces données ? Si un grand nombre de décisions de ce type doit être pris régulièrement, il peut être utile d'augmenter les pauses entre les exécutions afin de laisser suffisamment de temps pour le traitement des files.
En tant qu’administrateur Checkmk, vous connaissez probablement déjà très bien la fonction « Activate changes ». Cette action détermine comment et quand la gestion dynamique des hôtes doit activer les modifications, ainsi que le temps que cela peut prendre.
Même la fonction « Service discovery » elle-même ne sera plus un grand mystère pour vous. Cependant, selon l’environnement de supervision, quelques ordinateurs hôtes supplémentaires peuvent être en attente d’une identification groupée dans la gestion dynamique des hôtes. Reportez-vous à l’aide en ligne détaillée dans une telle situation afin de pouvoir intervenir de manière opportune et ciblée en cas de retard dans le processus de gestion dynamique des hôtes.
La dernière option du groupe (Do not monitor hosts without discovered services) a été introduite pour gérer une situation particulière. Elle n’est en principe nécessaire que si des modifications en attente sont fréquemment forcées sans reconnaissance préalable du service. Cette option doit être activée avec prudence. Toutefois, si cela s’avère nécessaire, cela peut indiquer que les options précédentes n’ont pas été configurées de manière optimale, ou que le serveur Checkmk n’est plus en mesure de faire face à la charge générée par la gestion dynamique des hôtes.
6. Diagnostic
6.1. Historique d'exécution
Si vous souhaitez observer le fonctionnement du DCD, vous trouverez l'icône en forme d'horloge dans la liste des connexions de chaque entrée,
qui vous mènera à l'historique d'exécution :
Si, pour une raison quelconque, la création d'un ordinateur hôte échoue, cela apparaîtra dans l'historique d'exécution.
6.2. Le fichier journal du DCD
Le fichier journal du DCD est ~/var/log/dcd.log.
Voici un exemple correspondant à l'illustration précédente :
2025-08-21 11:46:18,962 [20] [cmk.dcd.Manager] 1 batches arrived 50, last activated is reset
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Batches: {281} = Create: 0 Edit: 0 Delete: 0 Discover: 0
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Skip batches {281}7. Fichiers et répertoires
| Chemin d'accès au fichier | Fonction |
|---|---|
|
C'est ici que les données ferroutées sont générées. Un sous-répertoire est créé pour chaque hôte ferrouté contenu dans les données ferroutées. |
|
C'est ici que les données OpenTelemetry sont générées. Un sous-répertoire est créé pour chaque ordinateur hôte. Les fichiers qui y sont créés sont au format JSON. |
|
Fichier journal du daemon de configuration dynamique (DCD). |