Développement de plugins pour l'inventaire matériel/logiciel

L'API Inventory fait partie de l'API Check. Pour accéder à la documentation, suivez les mêmes étapes que pour les plugins de supervision basés sur des agents.

Vous pouvez accéder à la documentation fournie avec votre instance Checkmk. Pour ce faire, rendez-vous sur Help > Developer resources > Plug-in API references dans l'interface graphique de Checkmk. Dans la nouvelle fenêtre de navigateur, sélectionnez « Agent based ("Check API") > Version 2 » dans la barre de navigation de gauche. Même si vous ne disposez pas actuellement d'une instance Checkmk en cours d'exécution, vous pouvez consulter une copie de la documentation de l'API des plugins à l'adresse docs.checkmk.com/plugin-api.

Étant donné que Checkmk handle bien les sorties ligne par ligne, trois lignes suffisent pour le plugin de supervision requis :

N'oubliez pas de rendre le plugin exécutable :

Si l'ordinateur hôte sur lequel vous testez le plugin d'agent est une machine virtuelle, ou si vous ne souhaitez pas avoir à déconnecter et reconnecter continuellement des périphériques, enregistrez simplement l'exemple suivant dans un fichier situé dans le répertoire spool. Les fichiers spool sont inclus dans la sortie de l'agent et sont transférés avec celle-ci, veillez donc à ce que le fichier se termine par un saut de ligne.

Vous pouvez ensuite simuler la connexion et le retrait de périphériques USB en ajoutant ou en supprimant des lignes dans le fichier texte.

Testez la sortie de l'agent localement à l'aide de l'instruction suivante :

En fonction du nombre de périphériques USB en connexion (ou du nombre de lignes dans le fichier spool), vous devriez maintenant voir la sortie de `lsusb` et quelques lignes de la section suivante de l'agent. Assurez-vous que le saut de ligne à la fin de la section de l'agent est correct.

Vous pouvez désormais créer un plugin d'inventaire de base, que vous pouvez modifier à l'aide de n'importe quel éditeur de texte :

La structure est similaire à celle des plugins de supervision. Le plugin d'inventaire importe également depuis l'espace de nommage cmk.agent_based.v2. Un objet CheckPlugin instancié est lié à une fonction de supervision spécifique qui renvoie un ou plusieurs objets Result via yield. De même, un objet InventoryPlugin instancié est lié à une fonction d'inventaire spécifique qui renvoie un objet Attributes via yield.

L'Attributes renvoyé par yield implémente la feuille minimale significative d'un arbre d'inventaire :

Commencez par vérifier que le plugin est syntaxiquement correct et qu'il peut être lancé pendant l'inventaire :

Si tel est le cas, mettez à jour la configuration du noyau de supervision, puis redémarrez votre instance :

Un coup d'œil à l'inventaire de l'ordinateur hôte de test montre désormais — dès que la prochaine vérification régulière a été effectuée — une nouvelle feuille dans l'arborescence de l'inventaire.

Les sections d’agent sans séparateur spécifié sont converties en une liste bidimensionnelle de tokens à l’aide du séparateur par défaut (espace) avant d’être transmises à la fonction d’inventaire : Une liste de tokens est créée pour chaque ligne. Chacune de ces listes est à son tour un élément d’une liste de lignes. Si un séparateur est spécifié, il définit la limite entre les tokens. Cela facilite le traitement des données au format CSV, par exemple.

Une fonction d'analyse telle que celle destinée aux plugins de supervision basés sur des agents n'est pas absolument nécessaire. Cependant, l'utilisation d'une fonction d'analyse distincte peut présenter certains avantages. Par exemple, elle améliore la clarté et l'extensibilité. Et si un plugin de supervision existant doit être réutilisé, la question ne se pose même pas : il suffit de continuer à utiliser la fonction d'analyse existante.

Dans notre exemple, l'emplacement de connexion d'un périphérique USB n'a pas d'importance. Pour le plugin, il faut déterminer les identifiants du fabricant et du périphérique (sixième élément de la liste) ainsi que la description (du septième élément jusqu'à la fin de la liste).

Alors que la version USB maximale prise en charge était simplement codée en dur dans l'exemple simple ci-dessus, n'hésitez pas à réfléchir à la manière dont vous pourriez déterminer cela à moyen terme à l'aide d'expressions régulières à partir de la description. Pour ce faire, la description complète est requise, c'est-à-dire tout ce qui se trouve du septième au dernier mot de la liste :

Vous pouvez ici prendre un raccourci : contrairement aux plugins de supervision basés sur un agent, la fonction d'analyse n'est pas intégrée par la création d'un objet `AgentSection`, mais doit être appelée depuis la fonction d'inventaire elle-même. Vous connaissez le principe de l'yielde pour le transfert continu d'éléments depuis les plugins de supervision basés sur un agent :

Ici, un objet de type TableRow est renvoyé pour chaque ligne de la sortie de lsusb. Celui-ci contient trois colonnes : le fournisseur et l'ID de l'appareil servent ensemble de clés. La troisième colonne, qui est purement informative, contient la description.

Les colonnes clés ont la particularité d'être utilisées pour détecter les modifications, ce qui peut entraîner un changement de statut du service HW/SW Inventory dans la supervision. De plus, les clés doivent être uniques. Les lignes supplémentaires présentant la même combinaison d'identifiants de fournisseur et d'appareil sont donc ignorées.

Outre les colonnes de clé et d’inventaire, vous pouvez également décrire les entrées du tableau à l’aide d’status_columns et d’status_attributess analogues, qui représentent l’état d’un objet. Les types de données simples (int, float, str, bool ou None) sont disponibles pour la valeur de l’état. Par exemple, si vous souhaitez créer un tableau répertoriant les connexions (Bus/Device) occupées, vous pouvez utiliser key_columns (Bus et Device) et status_columns (ici : bool).

Le plugin final rassemble tous les éléments. La classe TableRow est également importée ici :

La sortie de l'lsusbe comprend plusieurs lignes pour les hubs (hubs externes et hubs racines). Ces appareils, qui ne possèdent aucune fonctionnalité propre, rendent difficile l'aperçu.

Les utilisateurs doivent donc pouvoir décider eux-mêmes si les concentrateurs doivent être inclus ou non. Ils doivent pouvoir configurer ce paramètre à l'aide d'une case à cocher dans une règle.

Pour ce faire, créez le dossier « rulesets » pour la famille de plugins :

Créez maintenant le jeu de règles dans ce dossier :

Une fois que vous avez enregistré le script du jeu de règles, validez-le à l'aide de cmk-validate-plugins, puis redémarrez l'instance avec omd restart. À ce stade, vous pouvez ignorer les messages d'erreur provenant de cmk-validate-plugins concernant les jeux de règles existants mais non liés. La liaison s'effectue dans la section suivante.

Vous pouvez désormais consulter et personnaliser la règle dans l'interface graphique à l'adresse Setup > Hosts > HW/SW inventory rules. Si vous connaissez le nom d'une règle (ici : Lsusb inventory demo), vous pouvez le saisir directement dans le champ de recherche. À l'aide de Add rule, vous pouvez créer la règle que vous venez de préparer et l'appliquer comme d'habitude aux dossiers ou aux ordinateurs hôtes présentant les propriétés que vous avez sélectionnées.

Le jeu de règles n'a pas encore été lié. Pour l'appliquer, ajoutez deux autres named arguments lors de la création de la classe InventoryPlugin.

De plus, le dictionnaire de paramètres doit être transmis à la fonction inventory en tant que premier argument. Ici, vous ajoutez également une expression régulière pour identifier les descriptions de périphériques se terminant par « hub ». Notez que vous devez ajouter une autre ligne import au début du script pour cela :

Dans l'exemple, vous avez suivi la procédure standard jusqu'à présent : Un plugin d'inventaire s'abonne à une section d'agent qui porte le même nom que le plugin d'inventaire. Mais que faire si vous souhaitez utiliser des sections d'agent existantes qui sont déjà évaluées par un plugin d'inventaire existant ? Dans ce cas, il y a de fortes chances qu'un plugin d'inventaire utilisant le même nom que la section d'agent existe déjà. La sortie suivante fournit un aperçu des sections existantes :

Dans ce cas, et dans les cas où un plugin d'inventaire doit évaluer plusieurs sections d'agent, vous pouvez spécifier les sections souscrites sous forme de liste. Par exemple, supposons que vous souhaitiez évaluer deux sections d'agent faisant référence à des éléments fictifs :

Dans ce cas, les sections d'agent souscrites doivent être explicitement spécifiées. Le nom du plugin d'agent ne doit plus correspondre aux sections d'agent :

La fonction d'inventaire reçoit ensuite les tables de chaînes sous forme de variables selon le modèle section_sectionname :

Le plugin complet, qui inclut les versions de Yoyodyne Gnomovision et Zorg ZF1 dans l'arborescence de l'inventaire, peut alors se présenter comme suit :