Récupération des données de statut via Livestatus

L'accès à Livestatus s'effectue via un socket Unix à l'aide du langage de requête Livestatus (LQL). Sa syntaxe est basée sur HTTP.

Depuis la ligne de commande, il existe plusieurs façons d'accéder à l'interface. Une possibilité consiste à utiliser les commandes printf et unixcat pour envoyer une instruction au socket. L'outil unixcat est déjà inclus dans Checkmk pour l'utilisateur de l'instance. Important : toutes les entrées vers le socket sont sensibles à la casse, il faut donc toujours en tenir compte :

L'interface attend que toutes les instructions et tous les en-têtes soient sur une ligne distincte. Vous pouvez marquer un tel saut de ligne avec \n. Comme alternative à l'instruction ci-dessus, vous pouvez également utiliser l'instruction de script lq, qui vous épargne un peu de travail en complétant automatiquement certains champs lors de la saisie :

Vous pouvez également lancer le flux de saisie interactif et saisir l'instruction suivie de l'en-tête. Une ligne vide permet d'exécuter l'instruction avec son en-tête, et une ligne supplémentaire met fin à l'accès au socket. Notez que dans l'exemple, tout ce qui précède la ligne vide fait partie de l'instruction, et tout ce qui se trouve entre la première et la deuxième ligne vide constitue la réponse :

Les exemples suivants sont toujours exécutés avec l’instruction lq – sous forme directe lorsque la requête est courte, et sous forme de flux de saisie pour les requêtes plus longues.

Étant donné que Checkmk repose en grande partie sur Python, les scripts dans ce langage sont pratiques. Le script suivant peut servir de base pour accéder au socket Livestatus :

Checkmk fournit également une API pour les langages de programmation Python, qui simplifie l'accès à Livestatus. Un exemple de code est disponible pour cette API, qui explique son utilisation. Vous trouverez cette API sur GitHub.

Dans les exemples que nous avons vus jusqu’à présent, TOUTES les informations concernant TOUS les ordinateurs hôtes ont été interrogées. Dans la pratique, cependant, on n’aura probablement besoin que de colonnes spécifiques. Grâce à l’en-tête Columns déjà mentionné, le résultat peut être limité à cette colonne. Les noms des colonnes individuelles seront séparés par un simple espace.

Comme on peut le voir, dans une ligne, les valeurs individuelles sont séparées par un point-virgule.

Pour limiter la requête à des lignes spécifiques, les colonnes peuvent être filtrées en fonction d'un contenu donné. Si vous souhaitez rechercher uniquement les services présentant un statut spécifique, vous pouvez le faire à l'aide d'un filtre :

Dans l'exemple, tous les services ayant le statut « CRIT » seront recherchés, et le nom de domaine, la description du service et son statut seront affichés. De tels filtres peuvent bien sûr être combinés, et limités aux services ayant le statut « CRIT » et qui n'ont pas encore fait l'objet d'une confirmation :

Comme on peut le voir, il est également possible de filtrer par des colonnes qui ne figurent pas sur la liste de Columns.

Vous pouvez utiliser l'en-tête OrderBy pour trier la sortie en fonction du contenu de n'importe quelle colonne ou même des valeurs de n'importe quelle clé de dictionnaire. Cela vous permet de créer une liste alphabétique de tous les ordinateurs hôtes, par exemple :

Par défaut, la sortie est triée par ordre croissant (asc), comme prévu. Cependant, vous pouvez également spécifier explicitement le tri souhaité et l'inverser en indiquant desc` :

Avec des requêtes légèrement plus longues et un tri par, par exemple, les données de performance, il est possible de créer des listes intéressantes. Dans l'exemple suivant, les ordinateurs hôtes sont affichés par ordre décroissant de leur durée de fonctionnement :

Certaines colonnes d'un tableau ne renvoient pas une seule valeur, mais toute une liste de valeurs. Afin de permettre une recherche efficace dans une telle liste, les opérateurs ont dans ces cas-là une autre fonction. Vous trouverez la liste complète des opérateurs dans la section Opérateurs pour les listes. Ainsi, par exemple, l'opérateur >= a la fonction « contient ». Grâce à cela, vous pourriez, par exemple, rechercher des contacts spécifiques :

Comme le montre l’exemple ci-dessus, les contacts seront répertoriés, séparés par des virgules, dans la colonne « contacts ». Cela permet de les distinguer clairement et de ne pas les confondre avec le début d’une autre colonne. Une particularité de l’opérateur d’égalité est qu’il checke si une liste est vide :

Plusieurs filtres ont déjà été combinés précédemment. Il semblerait intuitif que les données doivent passer par tous les filtres pour être affichées. Les filtres seront donc reliés par l'opération logique « et ». Pour relier certains filtres par une opération logique « ou », à la fin de la chaîne de code du filtre, insérez « or: » suivi d'un nombre entier. Ce nombre indique combien des dernières lignes peuvent être combinées par une opération « ou ». De cette manière, des groupes peuvent être formés et combinés selon les besoins. Voici un exemple simple. Ici, deux filtres sont combinés de sorte que tous les services ayant le statut « WARN» ou « UNKNOWN » s'affichent :

Le résultat d'une combinaison peut également être inversé, ou les groupes peuvent à leur tour être combinés en d'autres groupes. Dans l'exemple, tous les services sont affichés dont le statut n'est pas « OK », et dont la description commence par « Filesystem », ou qui ont un statut autre que « UNKNOWN » :

Le format de sortie peut être spécifié de deux manières. Une méthode consiste à redéfinir les séparateurs utilisés dans la sortie standard. L'autre méthode consiste à générer une sortie conforme aux formats Python ou JSON.

Il existe des situations dans lesquelles vous ne vous intéressez pas à l'état d'un service unique ou d'un groupe de services. Ce qui importe bien davantage, c'est le nombre de services dont l'état est actuellement « WARN », ou le nombre de bases de données sous supervision. Livestatus est capable de générer et d'afficher des statistiques à l'aide de l'option « Stats ».

L’Overviewe reçoit ses données en récupérant les statistiques relatives aux ordinateurs hôtes, aux services et aux événements via Livestatus, puis en les affichant dans l’interface de Checkmk. Grâce à un accès direct à Livestatus, vous pouvez créer votre propre résumé :

À noter que ces statistiques peuvent être combinées avec tous les filtres.

Les statistiques peuvent également être combinées avec l'and/or. Les en-têtes sont alors appelés « StatsAnd » ou « StatsOr ». Utilisez « StatsNegate » si la sortie doit être inversée. Dans l'exemple, le nombre total d'ordinateurs hôtes sera affiché (Stats initiale), et la sortie inclura en outre le nombre d'ordinateurs hôtes marqués comme « stale » et qui ne figurent pas non plus dans une liste de période de maintenance (les statistiques 2 et 3 sont liées par un « ET » logique) :

Ne vous laissez pas dérouter par les différentes options permettant de combiner les résultats des filtres et des statistiques. Alors que tous les ordinateurs hôtes répondant aux conditions seront affichés avec l'en-tête « Filter», avec les statistiques, le résultat sera la somme du nombre de fois où le filtre « Stats » s'applique.

Il est également possible d'effectuer des calculs sur les valeurs et, par exemple, d'afficher une valeur moyenne ou une valeur maximale. Une liste complète de tous les opérateurs possibles est disponible ici.

Dans l’exemple suivant, la liste indiquera la moyenne, le minimum et le maximum des temps nécessaires aux plugins de supervision d’un ordinateur hôte pour calculer un état :

Les calculs avec les métriques sont traités d’une manière quelque peu particulière. Ici aussi, toutes les fonctions de l’en-tête Stats sont disponibles. Celles-ci s’appliquent toutefois individuellement à toutes les métriques d’un service. À titre d’exemple, dans l’exemple suivant, les métriques relatives à la charge de travail du processeur d’un groupe d’hôtes seront additionnées :

La table « log » de Livestatus vous offre un accès direct à l'historique de supervision du noyau du processeur, ce qui vous permet, à l'aide du LQL, de filtrer facilement des événements particuliers. Les tables de disponibilité, par exemple, seront générées à l'aide de ces tables. Afin d'améliorer l'aperçu et de restreindre une requête par thème, vous avez accès aux classes de journaux suivantes :

Le simple fait d'utiliser ces classes de journaux vous permet déjà de limiter très efficacement le type d'entrée de journal à afficher. La période prise en compte dans la requête sera en outre restreinte. Ceci est important, car sinon, l'historique complet de l'instance serait exploré – ce qui pourrait logiquement ralentir considérablement le système en raison du flux massif d'informations.

Une autre restriction judicieuse de la sortie concerne les (Columns) qui doivent être affichées pour une entrée. Dans l'exemple ci-dessous, nous rechercherons toutes les notifications qui ont été enregistrées au cours de la dernière heure :

Il est possible d’influencer la rotation des fichiers et leur taille maximale. Vous pouvez en outre spécifier le nombre de lignes d’un fichier qui doivent être lues avant que Checkmk n’interrompe le processus. Tout cela peut affecter les performances de vos requêtes, en fonction de la configuration de l’instance. Les trois paramètres suivants sont disponibles ; vous pouvez les trouver et les personnaliser dans Setup > General > Global Settings > Monitoring Core :

Pour accéder à Livestatus via le réseau, vous pouvez établir une connexion entre le socket Unix du processus Livestatus et un port TCP. De cette manière, vous pouvez exécuter des scripts sur des machines distantes et collecter les données directement à l'endroit où elles doivent être traitées.

Lorsqu'une instance est désactivée, l'accès via TCP peut être activé à l'aide de l'instruction « omd» :

Une fois l'instance démarrée, Livestatus via TCP est généralement actif sur le port par défaut 6557. Pour les serveurs Checkmk comportant plusieurs instances utilisant Livestatus via TCP, le port inutilisé immédiatement supérieur est sélectionné.

Tous les paramètres, tels que le port et les adresses IP autorisées, peuvent être configurés via omd config. Ces paramètres peuvent également être définis dans la Configuration. Dans Checkmk, le chiffrement SSL de la communication Livestatus est activé par défaut :

Si un accès à Livestatus depuis l'extérieur de votre réseau local est nécessaire, une protection d'accès basée uniquement sur les adresses IP peut s'avérer peu pratique. Le moyen le plus simple d'obtenir un accès authentifié dans ce cas est d'utiliser Secure Shell.

Avec SSH, vous avez la possibilité de transmettre une instruction qui sera exécutée sur le serveur distant :

Vous pouvez également rediriger le port Livestatus vers l'ordinateur hôte sur lequel vous travaillez actuellement via un tunnel SSH :

Si la connexion a été établie, vous pouvez tester dans une deuxième session de console si l'accès avec openssl s_client est possible :

Si ce test est concluant, tout script que vous avez écrit pour un accès direct au réseau Livestatus peut être utilisé sur localhost.

Livestatus ne sert pas uniquement à interroger des données, mais également à envoyer des instructions directement au noyau du processeur (CMC ou Nagios). Une instruction correcte comprend toujours un horodatage – celui-ci peut en fait être n'importe quoi. Cependant, comme elle sera également utilisée dans les journaux pour suivre l' heure du processus, il est judicieux d'indiquer l'heure aussi précisément que possible. Les instructions dont l'horodatage est manquant seront ignorées, sans générer de message d'erreur , et ne feront l'objet que d'une simple entrée dans l'cmc.log !

Afin que l'horodatage soit aussi précis que possible, il est recommandé de ne pas définir l'instruction dans le flux d'entrée, mais plutôt de l'exécuter directement. Dans ce cas, vous avez également accès aux variables et l'heure actuelle peut être fournie :

Ce format fonctionne à la fois avec le Nagios-Core dans Checkmk Community et avec le CMC dans les éditions commerciales. Dans les deux cœurs, les instructions ne se recoupent toutefois que partiellement. Une liste complète des instructions pour le Nagios-Core est disponible directement sur le site web de Nagios. Les instructions disponibles pour le CMC se trouvent dans la référence des instructions.

Dans la liste des instructions, la syntaxe se présente sous la forme suivante :

Comme vous l'avez appris, Checkmk utilise un format beaucoup plus simple pour l'exécution des instructions. Pour rendre le format Nagios compatible avec Checkmk, il vous suffit d'indiquer l'instruction, l'horodatage et, le cas échéant, les variables :