Supervision système, processus, journaux et dossiers

Le Discovery Agent surveille un hôte sous quatre angles : le système entier, les processus individuels, les fichiers journaux et les répertoires. Chacun se définit par un ensemble de règles avec seuils de gravité, évaluées selon une planification, et transformées en statut Mineur / Majeur / Critique.

Les quatre types de supervision sont stockés en JSON dans l’agent et s’exécutent comme des tâches cron indépendantes. Vous les définissez de deux façons :

• Page Paramètres du Discovery Agent — éditez les moniteurs de façon interactive dans l’interface Web de l’agent.
• Assistant de configuration des composants — le flux Discovery Agent en mode Custom vous guide à travers les moniteurs de journaux, les moniteurs de dossiers et le reste, puis écrit un discovery_agent.json prêt à l’emploi.

Quand une règle franchit son seuil, l’agent déclenche une alerte à la gravité de la règle et la route via les canaux de notification configurés.

Les quatre types de supervision

Les planifications utilisent les libellés 1MIN, 5MIN, 10MIN, 15MIN, 30MIN, 60MIN. Chaque moniteur s’exécute comme une tâche indépendante ; si un scan dépasse son intervalle, le passage qui chevauche est ignoré plutôt qu’exécuté en parallèle, de sorte qu’un disque lent ou un gros répertoire ne peut jamais empiler des scans qui se chevauchent.

Supervision système globale

L’agent échantillonne les métriques de l’hôte et compare chacune à ses seuils. Sont couverts : CPU, mémoire, charge moyenne (1/5/15 min), swap (taux entrée/sortie et utilisation), utilisation des systèmes de fichiers et inodes, E/S disque (taux lecture/écriture, file d’attente, utilisation), trafic réseau entrant/sortant, sockets TCP, temps d’attente E/S CPU et connexions de base de données.

Chaque métrique a des seuils Mineur / Majeur / Critique, définis en valeurs fixes ou calculés automatiquement à partir d’une baseline historique (moyenne + écart-type). Les seuils de trafic réseau portent en plus un opérateur (> ou <).

Pour la référence complète des champs, voir Seuils des métriques système et Configuration des seuils.

Supervision des processus

Les processus sont supervisés soit par déclaration manuelle (une liste de processus), soit par scan de port (le processus lié à un port). Pour chaque processus supervisé, l’agent suit le CPU, la mémoire, le nombre de threads, le nombre de descripteurs de fichiers et le trafic réseau, chacun avec ses propres seuils de gravité.

Pour la référence complète des champs, voir Seuils des métriques par processus.

Supervision des fichiers journaux

Un moniteur de journal surveille un fichier — ou un motif glob comme /var/log/app-*.log — et évalue une liste de règles sur les nouvelles lignes ajoutées depuis le dernier passage. L’agent suit un décalage (offset) en octets par fichier, de sorte que chaque scan ne lit que ce qui a été ajouté ; les motifs glob prennent en compte les nouveaux fichiers automatiquement.

La rotation des journaux est gérée automatiquement. Que le fichier soit tourné par renommage-et-recréation (un nouveau fichier reprend l’ancien nom) ou par copie-et-troncature (le fichier est vidé sur place), l’agent le détecte et reprend depuis le début du nouveau fichier, de sorte qu’aucune ligne n’est ni ignorée silencieusement ni comptée deux fois. Les offsets en octets sont persistés, donc un scan reprend proprement aussi après un redémarrage de l’agent.

Définir un moniteur de journal

Chaque règle fait correspondre des lignes et alerte selon le nombre de correspondances :

L’opérateur first se déclenche à la première occurrence quel que soit le nombre — utile pour « alerter dès que ceci apparaît » sur des motifs comme FATAL ou panic.

captureLines — ce qui apparaît dans l’alerte

captureLines modifie uniquement ce que l’alerte affiche, jamais ce qu’elle compte. La règle compte toujours toutes les correspondances ; la capture en conserve les N premières, dans l’ordre du fichier, et les ajoute à la cause racine de l’alerte après un marqueur | samples:, séparées par ; :

log /var/log/app.log rule 'errors': 47 occurrence(s) of 'ERROR' > 10 | samples: ERROR db timeout on tenant 12 ; ERROR db timeout on tenant 44

À retenir :

• Les N premières, pas les N dernières. Les correspondances 1…N sont conservées et les suivantes écartées au fil du scan : vous obtenez les plus anciennes du tick, pas les plus récentes.
• Les échantillons n’apparaissent que si la règle se déclenche. Une règle restée OK ne produit aucune cause racine, donc rien n’est affiché.
• Une seule ligne par échantillon. Si joinLines est également défini, seule la première ligne de chaque bloc correspondant est capturée — l’échantillon désigne l’entrée, il ne la reproduit pas.
• Gardez N petit (2 à 5). Les lignes capturées sont insérées telles quelles dans le corps de l’alerte, et une ligne de log peut être longue.

joinLines — comment les entrées multi-lignes sont évaluées

joinLines n’est pas un réglage de « N lignes de contexte avant la correspondance ». Il change l’unité à laquelle la regex s’applique : au lieu de tester une ligne à la fois, l’agent remplit un tampon de N lignes consécutives, les joint par des retours à la ligne, et teste le motif sur ce bloc entier. Un bloc correspondant compte pour une correspondance.

Avec joinLines = 3, une trace d’exécution comme celle-ci est évaluée en deux blocs :

Exception: boom       ┐
  at foo              ├─ bloc 1 → testé comme « Exception: boom\n  at foo\n  at bar »
  at bar              ┘
Exception: bang       ┐
  at baz              ├─ bloc 2
  at qux              ┘

Une règle de motif (?s)Exception.*at bar ne correspond qu’au bloc 1 : matchCount vaut donc 1.

En fin de tick, un bloc partiel (moins de N lignes) est tout de même évalué plutôt que reporté au tick suivant. L’alerte reste ainsi réactive, mais l’alignement des blocs recommence à chaque scan.

Contrôles au niveau fichier

Indépendamment des règles regex, un moniteur de journal peut aussi surveiller le comportement du fichier :

Mettez l’un de ces champs à 0 pour le désactiver.

Volume lu et plafond de lignes par passage

Les nouvelles lignes sont traitées en flux, une à la fois, plutôt que mises en tampon : la mémoire reste stable quelle que soit la taille du fichier ou le nombre de règles. Une seule lecture alimente toutes les règles du fichier — ajouter des règles coûte du temps de correspondance, pas d’E/S.

Chaque scan plafonne aussi le nombre de nouvelles lignes lues, via le réglage global de l’agent logMaxLinesPerTick (défaut 100000). Ce plafond s’applique par fichier et par passage : avec un chemin glob, chaque fichier développé dispose de son propre budget.

logMaxLinesPerTick est une soupape de sécurité, pas un objectif de débit. Il ne signifie pas « lire 100 000 lignes chaque minute », et l’agent ne cherche pas à occuper tout l’intervalle à lire. À chaque passage il lit ce qui a été ajouté depuis le dernier offset ; si cet arriéré dépasse le plafond, les N premières lignes sont évaluées, l’offset saute en fin de fichier, le reste de l’arriéré est ignoré, et un avertissement est écrit dans le journal de l’agent :

WARN log monitor: [/var/log/app.log] line cap 100000 reached between ticks, advancing offset to EOF

Les lignes ignorées ne sont jamais relues au passage suivant — elles disparaissent des compteurs de règles. Le plafond sert donc à empêcher un écrivain emballé de bloquer l’agent, et l’atteindre signale soit un intervalle de scan trop long pour le débit du fichier, soit un plafond trop bas.

Combien de temps dure réellement un scan ?

Le temps de scan est dominé par la mise en correspondance des expressions régulières, pas par le disque ni par le nombre de lignes : lire et découper les lignes est presque gratuit face au coût d’exécution de chaque motif sur chaque ligne. La réponse dépend donc du matériel, mais bien davantage du motif.

Les chiffres de référence ci-dessous ont été mesurés sur un AMD Ryzen 9 8940HX (Windows 11, Go 1.25) sur un journal applicatif de 100 000 lignes / 13,3 Mo présent dans le cache de pages du système. Considérez-les comme des ordres de grandeur, non comme des garanties.

Ce qu’il faut en retenir en pratique :

• Un passage à vide est gratuit. Un moniteur dont le fichier n’a pas grossi coûte environ 50 microsecondes. Scanner de nombreux fichiers calmes sur un rythme 1MIN ne pose aucun problème.
• Le plafond par défaut est confortable sur un rythme d’une minute. Même un moniteur volontairement coûteux à 8 règles épuise le budget complet de 100 000 lignes en moins de deux secondes — quelques pour cent d’un intervalle de 60 secondes, sur un seul cœur. Comptez environ 0,5 à 2 secondes pour 100 000 lignes par fichier pour un moniteur typique.
• Le nombre de règles et la qualité des motifs sont les leviers. Privilégiez un littéral ou un préfixe ancré ; évitez (?i) sur une alternance quand vous pouvez écrire explicitement les variantes de casse, et évitez un .* en tête. Utilisez excludePattern pour écarter le bruit, plutôt que des règles supplémentaires.
• Surveillez l’avertissement de plafond. S’il apparaît, raccourcissez le rythme de ce fichier (un scan 1MIN avec un budget de 100 000 lignes tolère ~1 600 lignes/seconde en régime soutenu), augmentez logMaxLinesPerTick, ou éclatez le glob pour que chaque fichier ait son propre budget.

Supervision des répertoires (dossiers)

Un moniteur de répertoire scanne un dossier et évalue des règles sur son contenu. Utilisez-le pour détecter une file d’attente qui cesse de se vider, un répertoire qui se remplit, ou un dossier de dépôt qui ne reçoit jamais de fichiers.

Définir un moniteur de répertoire

Chaque règle mesure une propriété du dossier :

Comment un statut est produit

Pour chaque type, le flux est identique à chaque passage :

1. L’agent collecte la valeur (échantillon de métrique, nombre de correspondances, taille de fichier…).
2. Il applique l’opérateur et le seuil de la règle.
3. En cas de franchissement, le résultat porte la gravité de la règle (MINOR, MAJOR ou CRITICAL) ; sinon OK.
4. Les résultats sont stockés pour les tableaux de bord et, s’ils sont non-OK, déclenchent des alertes via les canaux de notification de l’agent (e-mail, Slack, Teams, PagerDuty) selon les paramètres de temporisation des alertes.

Voir aussi

• Composant Discovery Agent — mécanismes de découverte, métriques collectées, flux d’exécution
• Configuration du Discovery Agent — référence complète des paramètres et seuils
• Seuils — comment ces métriques sont évaluées en statut, et comment les ajuster
• API HTTP du Discovery Agent — accès programmatique
• Opérations sur les moniteurs — moniteurs côté sonde (URL, API, SNMP, WMI, …)

Traductions

• en: System, process, log & folder monitoring