Supervision de fichiers de journalisation (logs)

Le package d'installation de l'agent Windows de Checkmk Community ne contient pas d'environnement Python. Cependant, un fichier cabinet correspondant est déjà disponible sur votre serveur Checkmk. Vous trouverez ce fichier, nommé python-3.cab, dans le répertoire ~/share/check_mk/agents/windows ou dans Checkmk via Setup > Agents > Windows > Windows Agent. Copiez ce fichier sur votre ordinateur hôte dans le répertoire C:\Program Files (x86)\checkmk\service\install. Il existe déjà un fichier portant ce nom et d'une taille de 0 octet. Vous devez remplacer ce fichier par la version provenant du serveur Checkmk. Redémarrez ensuite le service de l'agent Checkmk. Dans Windows PowerShell avec des droits d'administrateur, vous pouvez effectuer cette opération à l'aide de l'instruction suivante :

Une fois le service Windows redémarré, l'environnement Python virtuel aura été automatiquement installé.

Vous pouvez également télécharger et installer un package Python à jour depuis python.org. Veillez à activer les options suivantes lors de l'installation :

Si vous souhaitez commencer les tests immédiatement après l'installation de Python, il est essentiel de redémarrer le service « checkmkservice » soit via le Gestionnaire des tâches de Windows, soit à l'aide des instructions indiquées ci-dessus ; sinon, le service ne prendra pas en compte les nouvelles variables d'environnement.

Dans les éditions commerciales, commencez par ouvrir la règle du plugin d'agent « Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows) ». Le paramètre par défaut « Deploy the Logwatch plugin and its configuration » doit normalement être laissé tel quel. Toutefois, si vous souhaitez ou devez transférer le fichier de configuration « logwatch.cfg » vers l'ordinateur hôte d'une autre manière, l'option « Deploy the Logwatch plugin without configuration » est toujours disponible ici.

Poursuivez avec l’option Retention period. Le paramètre par défaut ici est d’une minute, ce qui correspond également à l’intervalle de vérification prédéfini dans Checkmk. Cette valeur doit toujours être au moins égale à l’intervalle de vérification. Cette option sert principalement à garantir qu’aucun message de journal ne soit perdu en raison d’une détection de service ou de l’exécution manuelle de cmk -d myhost. Vous trouverez plus de détails dans l’aide en ligne de l’option et dans le Werk #14451 avec lequel cette option a été introduite.

Nous arrivons maintenant à la section de la règle où les choses deviennent vraiment intéressantes : Configure a logfile section. Nous allons commencer directement par le plus grand obstacle de ces dernières années. Dans le champ Patterns for logfiles to monitor, vous devrez spécifier les fichiers journaux que vous souhaitez soumettre à la supervision. Vous pouvez le faire individuellement et explicitement ou à l’aide de ce que l’on appelle des modèles glob (glob en abrégé). Nous utilisons ici le module Python glob, pour lequel une documentation détaillée est disponible sur docs.python.org. Nous souhaitons toutefois vous fournir ici quelques exemples utiles.

Par exemple, si vous saisissez /var/log/my.log ici, logwatch effectuera la supervision uniquement sur ce fichier journal. Si vous saisissez plutôt /var/log/*log ici, logwatch effectuera la supervision sur tous les fichiers se terminant par la chaîne de caractères log et qui se trouvent directement dans le répertoire /var/log. Si vous souhaitez effectuer la supervision des fichiers journaux dans tous les répertoires directs de /var/, vous pouvez le faire à l'aide du glob suivant, par exemple : /var/*/*log. Nous ne proposons pas explicitement le glob ** pour effectuer une recherche récursive dans une structure de répertoires ici, car nous obtiendrions beaucoup trop rapidement une liste de résultats beaucoup trop longue et nous nous éloignerions de l'objectif réel de logwatch.

Le tableau suivant vous donne quelques exemples supplémentaires utiles de la manière dont vous pouvez utiliser les expressions globales pour effectuer la supervision des fichiers qui nécessitent une supervision sans avoir à les spécifier tous individuellement :

Ainsi, pour déterminer quels fichiers sont « saisis » lors de la première étape, nous n'utilisons aucune expression régulière, ce qui peut suffire pour vous permettre d'accéder à tous les fichiers souhaités.

Toutefois, si vous avez désormais besoin d'affiner le filtrage, vous pouvez utiliser l'option Regular expression for logfile filtering pour appliquer des expressions régulières aux résultats de l'étape 1 lors d'une deuxième étape.

Si vous avez effectué la collection de tous les fichiers de /var/log/ et de ses sous-répertoires directs lors de la première étape avec /var/log/ et /var/log/*/*, vous pourriez utiliser l'expression régulière error.log$|err$ pour réduire la liste des résultats à tous les fichiers se terminant par err.log ou err. Attention : le « point » (.) est à nouveau un caractère arbitraire. Cela pourrait, par exemple, laisser les fichiers /var/log/apache2/error.log, /var/log/mail.err et /var/log/cups/error_log.

Comme vous pouvez le constater, nous vous avons déjà fourni deux outils efficaces et performants pour sélectionner les fichiers à superviser, de sorte que logwatch puisse également vérifier très rapidement les autres paramètres et contenus à l'étape suivante à l'aide d'une liste de fichiers gérable. Vous pouvez approfondir vos connaissances sur ce dernier point dans l'article Expressions régulières dans Checkmk.

L'option Restrict the length of the lines vous permet de demander à logwatch de tronquer les lignes trop longues après le nombre de caractères spécifié.

L'option suivante, « Watch the total size of the log file », est utile pour détecter une rotation des journaux défectueuse. Si vous définissez ici 100 Mio, vous recevrez un avertissement chaque fois qu'un fichier journal particulier aura de nouveau dépassé la taille spécifiée.

Le nombre maximal de lignes que logwatch checke par exécution et par fichier peut être limité à l'aide de l'option « Restrict number of processed messages per cycle » ; quant à l'option « Restrict runtime of logfile parsing », elle vous permet de vous assurer que logwatch ne passe pas trop de temps sur un seul fichier qui aurait pu être inondé de milliers et de milliers de nouvelles entrées depuis la dernière vérification.

Si vous activez l'une des deux dernières options, vous devez également spécifier ce qui doit se passer si la limite spécifiée est dépassée. Avec notre paramètre par défaut, le service associé passe en état critique et vous recevez un message indiquant que des lignes ont été ignorées ou que la durée d'exécution maximale a été dépassée.

Handling of context messages est une option avec laquelle le volume de données transférées peut devenir très important très rapidement. Réfléchissez donc bien pour savoir si seules les messages de journal qui, selon vous, devraient générer une alerte (CRIT) ou une alerte de niveau 2 (WARN) sont importants pour vous, ou si toutes les lignes ajoutées depuis la dernière exécution de logwatch doivent être transférées vers le serveur Checkmk. Pour les petits fichiers journaux qui ne s'allongent que de quelques lignes par minute, le paramètre « Do transfer context » ne pose certainement aucun problème. Cependant, si 50 fichiers journaux sont surveillés sur un ordinateur hôte et qu’ils contiennent soudainement 100 000 nouvelles lignes d’une longueur de 500 caractères, nous sommes déjà dans l’ordre du gigaoctet. Dans un tel cas, il peut suffire de constater qu’un grand nombre de nouveaux messages ont été ajoutés depuis la dernière vérification pour lancer une vérification directement sur l’ordinateur hôte concerné.

Si vous avez besoin du contexte — c'est-à-dire des lignes avant et après le message de journal qui vous intéresse —, vous pouvez limiter cela à un certain nombre de lignes avant et après à l'aide de l'option Limit the amount of context data sent to the monitoring server.

L'option Limit the amount of data sent to the monitoring server vous permet de limiter la taille des données transférées de manière générale.

Process new logfiles from the beginning est désactivée par défaut. Cela suscite parfois de la surprise, car logwatch ne « reconnaît » pas les problèmes présents dans les fichiers journaux et ne les transmet pas au serveur Checkmk. À notre avis, rien n’est plus ancien que le journal d’hier, et il en va de même pour les messages de journal qui figuraient déjà dans un fichier journal avant la première exécution de logwatch. Lors de cette toute première exécution, logwatch se contente de noter le nombre de lignes déjà contenues dans le journal concerné. Ce n’est qu’au cours de la deuxième exécution que le contenu des fichiers est checké, c’est-à-dire les lignes nouvellement ajoutées.

Logwatch repose sur la capacité effective à lire les fichiers journaux. En arrière-plan, logwatch déploie des efforts considérables pour reconnaître le codage de chaque fichier journal. Cependant, des encodages de caractères trop inhabituels peuvent entraîner des problèmes. Si vous pouvez spécifier l’encodage des fichiers journaux soumis à la supervision, UTF-8 est un très bon choix. Si cela n’est pas possible et que logwatch ne parvient pas à déterminer l’encodage, vous pouvez effectuer une spécification explicite à l’aide de l’option `Codec that should be used to decode the matching files`.

Avec l'option « Duplicated messages management », si vous l'activez, vous pouvez à nouveau économiser un peu de bande passante, et la sortie ultérieure dans Checkmk sera également plus lisible. Si vous activez l'option « Filter out consecutive duplicated messages in the agent output », logwatch compte le nombre de fois qu'une ligne a été répétée et l'indique en conséquence dans la sortie au lieu de répéter les lignes.

Enfin, les lignes des fichiers journaux qui vous intéressent sont désormais décrites à l’aide d’une expression régulière et se voient attribuer un état. Si vous souhaitez que chaque ligne contenant le mot « panic » donne lieu à un « CRIT » dans Checkmk, il suffit de saisir « panic » dans le champ « Pattern(Regex) » après avoir cliqué sur « Add message pattern » sous « Regular expressions for message classification ». Les fonctions des autres options proposées sont déjà décrites en détail dans l’aide en ligne à cet endroit et ne sont pas reprises ici.

Remarque : l'état « OK » peut sembler déroutant à première vue. Il sert à transférer dans un premier temps les lignes d'un fichier journal vers le serveur Checkmk afin de procéder ensuite à la classification finale. Cela nous amène à un point important qui montre à quel point logwatch peut être flexible lorsqu'il est utilisé correctement.

Toutes les options expliquées dans cette section deviennent des entrées dans le fichier de configuration déjà mentionné, qui est stocké sur l'ordinateur hôte concerné. Si vous souhaitez désormais modifier la classification de certains messages, vous devrez peut-être d'abord modifier la règle, puis « cuire » l'agent et l'installer.

Vous pouvez également commencer par transférer tous les messages pertinents vers le serveur Checkmk (par exemple avec l’état « OK »), puis les (re)classer sur le serveur Checkmk à l’aide de la règle « Logfile patterns ». De cette manière, vous vous épargnez la peine de compiler et de déployer le nouvel agent ; après avoir personnalisé la règle susmentionnée en conséquence, il vous suffira — une seule fois — d’activer rapidement les modifications. Vous trouverez ci-dessous, dans le chapitre « Reclassification à l’aide de modèles de fichiers journaux », la procédure exacte à suivre.

Dans la communauté Checkmk , vous configurez le plugin d'agent comme d’habitude via un fichier texte. En règle générale, logwatch recherche un fichier nommé logwatch.cfg dans les répertoires /etc/check_mk (Linux) ou c:\ProgramData\checkmk\agent\config\ (Windows). Une configuration (presque) minimale pourrait ressembler à ceci :

Tout d’abord, entrez toujours ici un motif glob, suivi de toutes les options à appliquer. Vient ensuite — avec un retrait d’un espace — une lettre représentant l’état ou la fonction souhaitée, et enfin une expression régulière qui est comparée à chaque ligne du fichier journal. Avec la configuration ci-dessus, toutes les nouvelles lignes qui ont été ajoutées au fichier /var/log/my.log depuis la dernière exécution de logwatch seraient checkées par rapport aux deux motifs a critical message et something that should only trigger a warning.

Vous trouverez un exemple de configuration très complet applicable à un utilisateur de l'instance dans le fichier ~/share/check_mk/agents/cfg_examples/logwatch.cfg.

Comme toutes les options que vous pouvez spécifier dans un tel fichier de configuration ont déjà été expliquées dans la section « Configuration via la boulangerie d’agents », vous trouverez ici uniquement une liste et une brève description. Reportez-vous à la section ci-dessus pour une explication détaillée.