Monitoring : Graylog, Uptime Kuma et Prometheus

Sans supervision, les pannes sont découvertes par les utilisateurs, les dégradations passent inaperçues, et le diagnostic après incident devient une devinette. Trois outils couvrent ici trois questions distinctes — et c'est cette séparation, plus que les outils eux-mêmes, qui fait tenir l'ensemble.

Trois questions différentes, trois outils

C'est le point de départ, et celui qu'on oublie le plus vite en empilant des tableaux de bord :

Question	Outil
« est-ce que ça marche ? »	les sondes de disponibilité
« comment ça se comporte ? »	les métriques
« que s'est-il passé ? »	les journaux centralisés

Demander à un collecteur de journaux de faire de la disponibilité, ou à une base de métriques d'analyser du texte, produit un outil médiocre sur les deux tableaux. Chacun garde son rôle.

flowchart LR
    subgraph Sources["Services sources"]
        FW["Pare-feu"]
        DNS["DNS"]
        Proxy["Proxy et ICAP"]
        Web["Web et WAF"]
        IPS["IPS"]
        Nodes["Hotes et VMs"]
    end
    subgraph Piliers["Supervision"]
        Graylog["Journaux<br/>centralises"]
        Kuma["Sondes de<br/>disponibilite"]
        Prom["Metriques"]
    end
    subgraph Sorties["Restitution"]
        GrayUI["Recherche<br/>et tableaux de bord"]
        Notif["Notifications"]
        HA["Cartes<br/>domotique"]
    end
    FW --> Graylog
    DNS --> Graylog
    Proxy --> Graylog
    Web --> Graylog
    IPS --> Graylog
    FW --> Kuma
    DNS --> Kuma
    Web --> Kuma
    Nodes --> Prom
    Graylog --> GrayUI
    Kuma --> Notif
    Prom --> HA

Centraliser les journaux, et surtout les structurer

Tous les composants envoient leurs journaux vers un collecteur unique : le pare-feu, le résolveur DNS, le proxy et sa chaîne antivirus, le serveur web et son pare-feu applicatif, l'IPS.

Recevoir les journaux ne sert à rien s'ils restent du texte. Quatre chaînes de traitement en extraient des champs exploitables :

pare-feu : adresses et ports source et destination, règle qui a filtré, action, plus un enrichissement géographique sur les adresses publiques ;
DNS : client, domaine demandé, type de requête, et la vue qui a répondu — indispensable dans une architecture à vues multiples ;
web : méthode, URI, code de statut, agent utilisateur, temps de réponse ;
proxy : client, URL complète, résultat de cache, latence, et le verdict de l'analyse antivirus.

Le nom du programme est absent en syslog historique

Un piège qui coûte systématiquement une première chaîne de traitement inactive.

Quand les messages arrivent au format syslog historique — le plus répandu — le champ « nom d'application » n'est pas peuplé. Le programme émetteur est bien présent, mais noyé dans le message brut, sous la forme HOTE PROGRAMME[PID]: ….

Filtrer sur le champ structuré ne matche donc jamais rien. Il faut chercher dans le texte du message. Et comme une règle qui ne matche rien ne produit aucune erreur, la chaîne reste silencieusement inactive — elle a l'air installée, elle ne traite rien.

Surveiller la disponibilité

Une trentaine de sondes couvrent les services exposés : réponse HTTP et validité du certificat, ouverture de port, résolution DNS, et expiration des noms de domaine.

Une sonde qui prouve qu'une protection refuse

C'est le type de sonde le plus utile de tout ce montage, et le moins évident.

Une sonde classique vérifie qu'un service répond. Pour une couche de sécurité, c'est exactement la mauvaise question : un pare-feu applicatif désarmé répond parfaitement bien. Ce qu'on veut prouver, c'est qu'il refuse.

La parade est une sonde inversée : envoyer une charge que la protection doit rejeter, et n'accepter que le rejet. Le moniteur est configuré pour considérer un 403 comme le seul état sain — un 200 le fait passer au rouge.

Deux usages en production :

une charge d'attaque envoyée sur chaque domaine protégé, qui doit être refusée par le pare-feu applicatif ;
un fichier de test antivirus inoffensif servi à travers le proxy, qui doit être bloqué par la chaîne d'analyse.

Ces sondes ont une propriété que n'a aucune lecture de configuration : elles échouent quand la protection tombe, y compris quand rien d'autre ne change. L'une d'elles a ainsi rattrapé un déploiement dont le travail avait pourtant réussi — tâche verte, conteneur recréé, configuration inchangée.

Prévoir des témoins. Une sonde inversée sur un service connu pour être armé depuis longtemps sert de référence : si tout tombe ensemble, la panne est dans la couche commune ; si une seule tombe, c'est ce service qui a dérivé. Sans témoin, un rouge ne dit pas laquelle des deux causes.

Le proxy se surveille en HTTP, pas en TCP

Une sonde TCP ouvre une connexion et n'envoie rien. Le proxy attend des données HTTP, ne les reçoit pas, et journalise une erreur à chaque passage. À une sonde par minute, cela finit par représenter l'essentiel de ses journaux.

La bonne sonde est une requête HTTP, dont la réponse d'erreur est un indicateur de santé parfaitement valable : elle prouve que le proxy a lu, compris et répondu.

Une expiration de domaine qui s'affiche toujours invalide

Les sondes d'expiration sur les domaines en .fr renvoient systématiquement une date invalide : le format de date du registre ne correspond pas à celui attendu. C'est bénin, et il vaut mieux le documenter que de le rechercher deux fois — la surveillance HTTP du domaine, elle, fonctionne normalement.

Collecter les métriques

Les métriques sont récupérées par interrogation périodique des services.

Sur chaque machine, un agent expose l'utilisation processeur, la mémoire, les entrées-sorties disque et la santé des supports, le trafic réseau par interface, et les sondes de température.

Dans les pods applicatifs, deux agents en sidecar exposent l'état du pool d'exécution PHP — processus actifs, requêtes lentes, et surtout la file d'attente, qui est l'indicateur de saturation réel — et celui du serveur web, avec la distribution des codes de statut.

L'hyperviseur ajoute ce qu'il est seul à connaître : la consommation électrique mesurée par les compteurs intégrés au processeur, les températures détaillées, et l'état du GPU utilisé pour le transcodage.

Ces données sont restituées dans l'interface domotique, ce qui les met sous les yeux tous les jours plutôt que dans un onglet qu'on ouvre après la panne.

Rétention : tout ne se garde pas au même prix

journaux : rotation par taille et rétention d'un mois, avec un index séparé et bien plus court pour le pare-feu, de loin le plus volumineux ;
métriques : une quinzaine de jours, suffisant pour du diagnostic à chaud ;
disponibilité : conservée intégralement, le volume étant négligeable.

Alerter sans épuiser

Le piège classique est la fatigue d'alerte : trop de notifications non actionnables finissent ignorées, et celle qui comptait passe avec les autres.

Quatre règles tiennent l'ensemble :

n'alerter que sur des conditions sur lesquelles on peut agir immédiatement ;
caler les seuils sur le comportement réel et non sur des valeurs rondes — un processeur à 80 % pendant les sauvegardes nocturnes n'est pas un incident ;
grouper les notifications d'événements corrélés, pour qu'une panne unique ne produise pas quinze messages ;
relire périodiquement ce qui s'est déclenché, et ajuster.

La dernière est celle qu'on saute, et c'est celle qui garde le système utile.