 |
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
La supervision des tâches traitées régulièrement ou à la demande, ainsi que des processus fonctionnant en permanence, peut s’effectuer, par exemple, en analysant des fichiers journaux ou d’état. Cependant, cela implique souvent un surcroît de travail, car il est fréquemment nécessaire de lire de grands volumes de données pour en extraire de petites quantités d’informations.
Pour réduire cet effort, Checkmk offre la possibilité à un programme d'écrire directement ses résultats dans un fichier au format de l'agent Checkmk. Stockés dans ce qu'on appelle le répertoire spool, l'agent collecte tous ces fichiers et intègre leur contenu dans la sortie de l'agent. La méthode utilisant le répertoire spool est utile, par exemple, pour
l'analyse régulière des fichiers journaux,
la supervision des sauvegardes automatiques,
la création et la vérification de statistiques de charge de travail à partir d'une base de données,
lorsque le plugin «
mk-job» ne suffit pas pour contrôler les tâches cron,le développement de vos propres checks pour tester des exemples de sortie.
Dans Checkmk, le répertoire spool est pris en charge par les agents sur les systèmes d'exploitation suivants : Windows, Linux, AIX, FreeBSD, OpenWrt et Solaris.
Pour vous assurer de pouvoir utiliser cette fonctionnalité sans problème, il convient de garder à l’esprit quelques points.
2. Chemins d'accès aux répertoires de fichiers
Le chemin d'accès par défaut au répertoire de spool est /var/lib/check_mk_agent/spool/ sous Linux et sur les autres systèmes Unix, et C:\ProgramData\checkmk\agent\spool\ sous Windows.
Sous Linux et Unix, vous pouvez personnaliser le chemin d'accès au répertoire parent à l'aide de la règle Agent rules > Installation paths for agent files (Linux, UNIX) et de l'option Base directory for variable data (caches, state files) qui y est disponible.
Si vous travaillez sur un ordinateur hôte en cours de supervision, vous pouvez filtrer le répertoire de spool qui y est configuré à partir de la sortie de l'agent :
Checkmk utilise un seul répertoire de spool, qui appartient par défaut à root.
Il n'existe pas de répertoires multiples avec des propriétaires différents.
Cependant, vous pouvez bien sûr créer des fichiers (initialement vides) dans le répertoire de spool et en attribuer la propriété à un autre utilisateur, qui pourra alors écraser le contenu de son fichier.
|
Notez que l'agent n'effectue aucune vérification du contenu des fichiers spool ! Des fichiers spool manipulés peuvent écraser des sections normales de l'agent et donner ainsi l'illusion d'un fonctionnement sans problème. Même sans intention malveillante, il existe un risque potentiel qu'un fichier spool contienne une sortie d'agent corrompue, ce qui entraînerait l'ignorance totale des parties suivantes de la sortie de l'agent. |
3. Noms et contenu des fichiers
Les fichiers spool peuvent contenir des sorties textuelles dans n'importe quel format pris en charge par Checkmk. Les fichiers sont ajoutés les uns aux autres dans l'ordre dans lequel ils se trouvent dans le répertoire de spool. L'extension de fichier utilisée n'a pas d'importance.
Si vous souhaitez utiliser un système de numérotation pour le tri, faites précéder le nom de fichier d'un trait de soulignement (_), car les noms de fichiers commençant par des chiffres servent à vérifier l'ancienneté.
Les fichiers commençant par un point sont ignorés.
Pour éviter toute confusion dans le contenu des fichiers concaténés, chaque fichier spool doit
commencer par un en-tête de section, c'est-à-dire une ligne encadrée par
<<<et>>>— même si seul le format de check local est utilisé dans le fichier,se terminer par un saut de ligne.
Ainsi, un check local fournissant un service immédiatement peut se présenter comme suit :
<<<local>>>
0 "Spool Test Dummy" - This static service is always OKDe même, vous pouvez placer les sorties nécessitant un plugin de supervision du côté de Checkmk :
<<<waterlevels>>>
rainbarrel 376
pond 15212
pool 1237323.1. Fin de section de ferroutage
Si vous utilisez des sections de ferroutage dans un fichier, terminez ce fichier par la ligne « <<<<>>>> ».
C'est le seul moyen de garantir que, si l'ordre de lecture change, la sortie suivant la sortie de ferroutage soit réattribuée à l'ordinateur hôte lui-même.
4. Check de l'intégrité des fichiers
Si un programme parvient à écrire correctement dans son fichier de sortie, tout va bien, qu’il ait été exécuté avec succès ou non. Mais que se passe-t-il si un programme s’interrompt avant d’avoir écrit sur le disque, ou si une erreur du système de fichiers empêche l’écriture de nouveaux fichiers ?
Dans ce cas, vous avez la possibilité de faire précéder le nom du fichier d’un nombre entier, par exemple 600MyCronjob.
Dans ce cas, le nombre sera interprété comme l'âge maximal du fichier en secondes.
Si le fichier est plus ancien, il sera ignoré par l'agent et le service associé dans Checkmk passera à l'état UNKNOWN en raison de la sortie manquante.
Dans l'exemple d'un fichier nommé 3900_hourly_cleaner.txt, le nombre est donc choisi de manière appropriée pour une tâche cron s'exécutant toutes les heures, pour laquelle un temps d'exécution inférieur à cinq minutes est prévu.
5. Un exemple concret
Supposons que vous exploitiez un service sur lequel les utilisateurs se connectent et se déconnectent. Dans les fichiers journaux de ce service, vous trouverez des lignes correspondant aux trois types suivants :
21/Oct/2022:12:42:09 User harrihirsch logged in from 12.34.56.78
21/Oct/2022:12:42:23 User zoezhang logged out after 10 min idle
21/Oct/2022:13:00:00 Current user count: 739Le processus n'écrit pas la ligne contenant « Current user count » après chaque login/déconnexion, mais à intervalles réguliers.
Si le nombre de lignes dans le fichier journal est suffisamment faible pour permettre une lecture rapide, vous pouvez programmer un check local.
Cette check lit l'intégralité du fichier journal ligne par ligne à chaque fois et définit toujours le nombre d'utilisateurs sur la valeur affichée lorsque la ligne Current user count apparaît.
Lorsque les lignes logged in et logged out apparaissent, elle augmente ou diminue le nombre d'utilisateurs.
À la fin, votre check affiche une ligne similaire à celle-ci :
1 "Frobolator User Count" count=1023 Watch out! Limit nearly used up.À mesure que votre service gagne en popularité, le check local s'exécute de plus en plus longtemps, jusqu'à ce qu'à un certain moment, cette solution, et même son exécution en tant que plugin d'agent asynchrone, ne soit plus pratique. C'est là qu'une utilisation appropriée du répertoire de spool peut considérablement augmenter l'efficacité de l'exécution du check. Dans les paragraphes suivants, nous vous montrerons comment modifier le programme qui assure votre check local afin qu'il utilise efficacement le répertoire de spool.
Tout d'abord, le programme ne doit pas se fermer lorsqu'il atteint la fin du fichier, mais écrire un fichier spool contenant l'état actuel du service tel qu'il a été déterminé une fois le fichier journal entièrement évalué :
<<<local>>>
2 "Frobolator User Count" count=1200 Maximum number of users reached!Ensuite, laissez votre programme attendre une certaine période de temps — que ce soit quelques secondes ou plusieurs minutes dépendra de la fréquence des nouvelles entrées de journal. Il ne devra alors évaluer que les lignes nouvellement ajoutées et recalculer l'état. Si les chiffres ont changé, il réécrira le fichier spool.
Vous programmez cette procédure sous forme de boucle sans fin.
Pour détecter un éventuel plantage de ce programme, vous devriez nommer le fichier spool en conséquence, par exemple 1800_frobolator.txt — si 30 minutes sans mise à jour du fichier spool indiquent des problèmes avec le service ou le programme d’évaluation.
Au lieu du répertoire des plugins de l’agent, lancez désormais le programme en tant que daemon à l’aide des options de votre système d’exploitation. Veillez ici à activer le redémarrage automatique si le programme connaît un plantage ou est arrêté. De nombreuses applications serveur offrent également la possibilité de rediriger la sortie du journal vers un autre programme, à la place ou en plus de l’écriture de fichiers journaux normaux. Il est également judicieux d’utiliser ce mécanisme pour un script d’évaluation qui écrit des fichiers spool.
6. Quelques points à prendre en compte
La lecture de fichiers peut présenter d'autres écueils par rapport au lancement classique de processus par l'agent. Veuillez tenir compte des points suivants pour garantir un fonctionnement sans problème.
6.1. Jeu de caractères
Checkmk s'attend à ce que la sortie de l'agent soit exclusivement encodée en UTF-8 (sans Byte Order Mark / BOM) avec un simple saut de ligne (0x0A ou \n) comme fin de ligne.
Dans le pire des cas, tout écart peut entraîner une sortie de l'agent qui ne peut être lue au-delà du premier caractère d'un fichier spool mal formaté.
Concrètement, cela signifie :
Veillez tout particulièrement, sur les anciens systèmes Windows et Linux, à ce que les fichiers spool ne soient pas écrits dans les encodages Windows 1250 à 1258 ou ISO 8859. Si cela est inévitable, assurez-vous que seule l’intersection avec l’UTF-8 — de facto l’ASCII 7 bits — soit utilisée.
En particulier sur les systèmes Windows plus récents, assurez-vous que les fichiers spool ne sont pas écrits dans l'encodage UTF-16 utilisé comme norme sur ces systèmes.
N’utilisez pas de BOM. En particulier, les langages de script sous Windows écrivent souvent automatiquement cette séquence de caractères, qui indique l’encodage utilisé, dans les fichiers de sortie. Dans la sortie de l’agent, cela empêche l’
<<<e d’apparaître au début d’une ligne.Utilisez le saut de ligne Unix « newline » (
0x0Aou\n). Là encore, Windows utilise souvent la chaîne «CRLF» (0x0D 0x0Aou\r\n).
Si un fichier spool provoque un comportement indésirable, examinez ses premières lignes à l'aide d'un éditeur hexadécimal :
0xFF 0xFEindique un fichier encodé en UTF-16 : Dans ce cas, modifiez vos scripts pour qu'ils génèrent une sortie en UTF-8.0xEF 0xBB 0xBFaffiche UTF-8 avec BOM. Il suffit généralement d'écrire le fichier sans BOM à l'avenir.
6.2. Liens symboliques et tubes nommés
En principe, les fichiers du répertoire de spool peuvent également être des liens symboliques ou des tubes nommés. Il convient de noter que la vérification de l'âge via les noms de fichiers ne fonctionne pas ici, car c'est l'âge du lien symbolique ou du tube nommé lui-même qui est évalué, et non l'âge des données écrites. Pour les tubes nommés, vous devez également vous assurer que le processus écrivant dans le tube fournit toujours des données. Si aucune donnée n'est fournie, l'agent Checkmk attendra indéfiniment et finira par effectuer un timeout.
Si vous devez autoriser des utilisateurs non privilégiés à écrire dans les fichiers spool, créez des fichiers vides pour ces utilisateurs et définissez leur propriété en conséquence. Ces utilisateurs peuvent alors créer eux-mêmes un lien symbolique ou écrire directement dans le fichier spool.
6.3. Verrouillage et mise en mémoire tampon
Lors de l'écriture de programmes plus longs qui écrivent plusieurs lignes d'état dans un fichier spool, il est tentant d'ouvrir le fichier de sortie en écriture dès le démarrage du programme. Cependant, dans ce cas, le fichier restera complètement vide jusqu'à ce que le tampon d'écriture soit d'abord vidé et écrit vers la destination, et il sera incomplet jusqu'à ce que le programme d'écriture ait fermé le fichier. Il en va de même si un fichier est verrouillé en exclusivité pendant toute la durée d'une longue opération d'écriture.
C'est pourquoi vous devriez soit n'écrire dans le fichier de sortie que lorsque l'intégralité du contenu à écrire est disponible, soit écrire dans un fichier temporaire que vous copierez ensuite dans le répertoire de spool — ou, respectivement, utiliser la commande « cat » pour transférer le contenu d'un fichier temporaire vers un fichier existant dans le répertoire de spool.
6.4. Garder un aperçu
Un autre problème peut survenir lorsque différents programmes tentent d’écrire dans des fichiers portant le même nom. Avec de nombreux fichiers spool, il est facile de perdre la trace du programme qui écrit réellement dans quel fichier spool. En particulier, si un fichier spool mal formaté rend une partie de la sortie de l’agent inutilisable, cela est très gênant et peut entraîner une recherche fastidieuse.
Vous pouvez maintenir l'ordre en créant, pour chaque fichier spool, un fichier portant le même nom — précédé d'un point — qui contient des informations sur le travail et, le cas échéant, sur une personne de contact. Le contenu de ce fichier caché n'est pas transféré avec celui-ci.