Le mécanisme de Piggyback

Tout d'abord, la bonne nouvelle : le mécanisme de ferroutage fonctionne souvent de manière entièrement automatique :

Cependant — comme d’habitude dans Checkmk — tout est configurable. Plus précisément, dans les propriétés d’un ordinateur hôte (tel que l’ordinateur hôte B), dans la case « Monitoring agents », vous pouvez définir comment il doit réagir face à des données ferroutées existantes ou manquantes :

La valeur par défaut est « Use piggyback data from other hosts if present ». Si elles sont disponibles, les données ferroutées sont utilisées ; s’il n’y en a pas, l’ordinateur hôte utilise simplement ses « propres » données de supervision.

Avec le paramètre « Always use and expect piggyback data », vous forcez le traitement des données ferroutées. Si les données sont manquantes ou obsolètes, le service d’Check_MK émettra un avertissement.

Et avec l’option « Never use piggyback data », toutes les données ferroutées trouvées sont simplement ignorées — un paramètre dont vous n’aurez besoin que dans des cas exceptionnels.

Bien entendu, pour qu’un ordinateur hôte puisse traiter des données ferroutées, l’ordinateur hôte lui-même doit être présent dans la supervision. Dans l’exemple d’ESX, cela signifie que vous devez également avoir vos machines virtuelles en tant qu’hôtes dans Checkmk afin qu’elles soient effectivement surveillées.

Dans les éditions commerciales, vous pouvez automatiser cette opération à l’aide de la gestion dynamique des hôtes et créer automatiquement des hôtes pour lesquels des données ferroutées sont disponibles.

Dans les schémas ci-dessus, il était en quelque sorte logique que les données concernant l'objet B soient attribuées à l'ordinateur hôte B dans la supervision. Mais comment cela fonctionne-t-il exactement ?

Avec le mécanisme de ferroutage, l’affectation utilise toujours un nom. L’agent spécial écrit un nom d’objet pour chaque ensemble de données ferroutées. Dans le cas d’ESX, par exemple, le nom de la machine virtuelle. Certains plugins — tels que Docker — proposent également plusieurs options quant à ce qui doit être utilisé comme nom.

Pour que l'affectation fonctionne correctement, le nom de l'ordinateur hôte correspondant dans Checkmk doit bien sûr être identique, y compris les majuscules et les minuscules.

Mais que se passe-t-il si les noms des objets dans les données ferroutées sont inappropriés ou indésirables pour la supervision ? Sont par exemple inappropriés les noms d’hôtes ferroutés qui se composent uniquement d’un point ou qui commencent par un point, tels que .myhostname, car ceux-ci ne sont pas traités dans Checkmk. Il existe un jeu de règles spécial Host name translation for piggybacked hosts, que vous trouverez dans le menu de configuration sous Setup > Agents > Agent access rules.

Pour configurer un changement de nom, vous devez effectuer deux opérations :

Voici un exemple de valeur dans une règle. Tout d’abord, la partie « domaine » des noms de domaine est supprimée avec Convert FQHN. Ensuite, tous les noms de domaine issus des données ferroutées sont convertis en minuscules. Enfin, les deux hôtes vm0815 et vm081 sont convertis en hôtes Checkmk mylnxserver07 et mylnxserver08 :

La méthode utilisant des expressions régulières, disponible sous Multiple regular expressions, offre davantage de flexibilité. Elle est utile si le renommage de nombreux ordinateurs hôtes est nécessaire et s’effectue selon un schéma spécifique. Procédez comme suit :

Un exemple d’expression régulière serait, par exemple, vm(.*)-local. La valeur de substitution myvm\1 traduirait alors le nom vmharri-local en myvmharri.

Si votre réseau change, les données ferroutées peuvent également changer. Cela soulève de nouvelles questions. Comment la supervision réagit-elle si un ordinateur hôte n'est pas accessible ? Que se passe-t-il si les données ferroutées deviennent obsolètes, par exemple parce que l'objet n'est plus disponible, temporairement ou même définitivement ? Toutes les données ferroutées sont-elles traitées de la même manière ou existe-t-il des différences ? Comme pour de nombreux autres thèmes dans Checkmk, le comportement ici dépend également des paramètres et donc des règles. Avec la règle Processing of piggybacked host data, que vous trouverez sous Setup > Agents > Agent access rules, vous pouvez définir diverses options.

Dans la section « Processing of piggybacked host data », vous saisissez les détails pertinents pour le traitement des données ferroutées.

Checkmk vous facilite la tâche lors de la gestion des données ferroutées. Entre autres, il supprime automatiquement tous les hôtes/objets pour lesquels aucune donnée ferroutée n’est (ou n’est plus) fournie par un hôte ferrouté. Avec l’option « Keep hosts while piggyback source sends piggyback data only for other hosts », vous spécifiez le délai après lequel les fichiers concernés contenant des données ferroutées sont supprimés. Assurez-vous que cette période soit au moins aussi longue que la période de check pour les hôtes ferroutés.

Utilisez les deux options de « Set period how long outdated piggyback data is treated as valid » pour définir pendant combien de temps les données ferroutées existantes doivent encore être considérées comme valides si l’ordinateur hôte ne fournit plus de nouvelles données. Une fois la période définie écoulée, les services basés sur les données ferroutées sont affichés comme obsolètes. Vous définissez également le statut du service « Check_MK » pendant cette période. Vous pouvez utiliser cette option pour éviter des avertissements inutiles, en particulier en cas d’interruptions de connexion répétées et de courte durée.

Une fois que vous avez défini le traitement des données ferroutées de manière générale, vous pouvez définir un traitement distinct (selon le même schéma) pour des ordinateurs hôtes sous Exceptions for piggybacked hosts à l'aide des options décrites.

Enfin, vous devez toujours spécifier le nom de l'hôte ferrouté dans l'option « Explicit hosts » de l'Conditions.

Comme décrit ci-dessus, les données ferroutées sont également transmises à d'autres ordinateurs hôtes via la sortie de l'agent du serveur ferrouté. La sortie de l'agent Checkmk est au format texte simple.

La nouveauté réside dans le fait qu’une ligne commençant par <<<< et se terminant par >>>> est autorisée dans la sortie. Entre ces deux éléments se trouve un nom de domaine. Toutes les données de supervision suivantes à partir de cette ligne sont alors attribuées à cet ordinateur hôte. Voici un exemple d’extrait qui attribue la section <<<esx_vsphere_vm>>> à l’ordinateur hôte 316-VM-MGM :

Une ligne contenant <<<<>>>> doit être utilisée pour mettre fin à cette attribution. Toute sortie ultérieure appartient alors à nouveau à l'hôte ferrouté.

Lors du traitement de la sortie de l’agent Checkmk, Checkmk extrait les parties destinées à d’autres hôtes et les place dans des fichiers sous ~/tmp/check_mk/piggyback. En dessous se trouve un sous-répertoire pour chaque hôte ferrouté (par exemple, pour chaque VM) — c’est-à-dire si nous nous en tenons à notre exemple avec le nom B. Dans ce sous-répertoire, il y aura alors un fichier distinct contenant les données réelles de chaque hôte ferrouté. Leurs noms seraient A dans notre exemple. Pourquoi est-ce si compliqué ? Eh bien, un ordinateur hôte peut en effet recevoir des données ferroutées provenant de plusieurs ordinateurs hôtes, de sorte qu’un seul fichier ne suffirait pas.

L’instruction `cmk-piggyback list sources` renvoie une liste de tous les hôtes ferroutés ayant fourni des données pour d’autres hôtes. Son équivalent est l’instruction `cmk-piggyback list piggybacked`, qui affiche une liste de tous les hôtes ferroutés (qu’ils soient déjà inclus ou non dans la supervision).

L'instruction cmk-piggyback offre également des options supplémentaires permettant d'observer le traitement des données ferroutées dans la supervision. Par exemple, avec cmk-piggyback track, vous pouvez consulter toutes les données ferroutées entrantes. Vous pouvez utiliser cmk-piggyback create-sections pour créer des exemples de données ferroutées.

Si vous travaillez dans un environnement où les hôtes changent automatiquement en hôtes ferroutés, nous vous recommandons d’utiliser la gestion dynamique des hôtes. Si vous ne pouvez pas ou ne souhaitez pas utiliser la gestion dynamique des hôtes, par exemple parce que les machines virtuelles sont déplacées manuellement, vous pouvez recevoir des données ferroutées provenant d’un hôte que vous n’avez même pas créé dans Checkmk. Cela peut être intentionnel, mais il peut également s’agir d’une erreur — par exemple parce qu’un nom ne présente pas une correspondance exacte.

L'instruction cmk-piggyback list orphans vous montre tous les objets pour lesquels des données ferroutées sont disponibles, mais pour lesquels aucun ordinateur hôte n'existe dans la supervision. Elle affiche une liste comportant une ligne pour chaque hôte ferrouté non surveillé trouvé :

Cette sortie est « propre » et peut, par exemple, être traitée dans un script.

Dans la supervision distribuée, vous pouvez organiser vos données ferroutées en fonction de vos structures opérationnelles. Cela signifie que les données ferroutées qui parviennent à la supervision via un ordinateur hôte peuvent être attribuées à un autre ordinateur hôte pour évaluation, même entre différents sites. Les données ferroutées sont transmises via l’instance centrale.

Par défaut, les données ferroutées sont toujours traitées sur l’instance où elles sont détectées, et les données sont automatiquement attribuées à l’ordinateur hôte sur lequel elles arrivent. Vous pouvez modifier ce comportement via les propriétés de l’ordinateur hôte.

Sélectionnez ici le site alternatif souhaité — qu’il s’agisse de l’instance centrale ou d’une instance distante sur laquelle vous souhaitez effectuer la supervision des données ferroutées. Ce qui suit s’applique également aux ordinateurs hôtes du « nouveau » site : les ordinateurs hôtes doivent être présents.

Pour réduire la charge sur votre instance centrale, vous pouvez également transférer les données ferroutées d’une instance distante à une autre directement — c’est-à-dire sans passer par l’instance centrale. Vous trouverez de plus amples informations sur cette connexion peer-to-peer dans l’article Supervision distribuée.