POC Enrichissement des alertes de supervision Prometheus - Etape 1

🔧 Dans ce POC, j'ai choisi d'améliorer la gestion des alertes issues de mon infrastructure, actuellement supervisée via Grafana, Prometheus, Loki et Alertmanager pour la gestion des notifications email. ⚠️ Plusieurs limites sont rapidement apparues, tant sur le fond que sur la forme. En particulier, le format des emails était peu exploitable, et les informations transmises manquaient de clarté et de hiérarchisation. Un point problématique notable concernait la distinction entre une alerte active et une alerte résolue : dans les deux cas, l'email reçu était strictement identique, avec simplement un attribut "resolved" présent dans les détails, peu visible et facilement manqué. 📧 Dans un premier temps, j'ai donc retravaillé la présentation des notifications. Pour cela, j'ai modifié la configuration d'Alertmanager afin d'envoyer les événements vers un webhook, traité par un workflow n8n. Ce premier niveau d'amélioration a permis d'obtenir un gain immédiat en lisibilité et en ergonomie. 📊 L'étape suivante consiste à enrichir le contenu des alertes en utilisant les informations de Prometheus et de Loki. 🎯 Enfin, dans un prochain article, j'aborderai la question de l'enrichissement via IA (MVP) afin de rendre l'analyse la plus pertinente possible. 🔍 Concrètement, lors du déclenchement d'une alerte, le système interroge Loki puis Prometheus afin d'identifier des signaux corrélés, puis utilisera un module d'analyse (basé sur l'IA) pour : - proposer une cause probable de l'incident, - suggérer des pistes de résolution, - contextualiser l'alerte avec des éléments techniques pertinents. ✅ Ainsi, le message d'alerte ne se limite plus à un simple signal brut : il devient un point d'entrée directement exploitable pour le diagnostic et la remédiation.

Architecture technique du POC

Prometheus (LAN) : collecte les métriques système via node_exporter sur l'ensemble du parc (CPU, RAM, disque, réseau, SMART).
Grafana (LAN) : visualisation, dashboards et gestion des alertes.
Loki (LAN) : agrégation centralisée des logs via Promtail, indexés par labels (instance, job, level, log_type, service_name, filename).
Alertmanager (LAN) : réception des alertes Prometheus, déduplication, routage vers le webhook n8n.
n8n (DMZ) : orchestration du workflow d'enrichissement et envoi des emails.

18 règles d'alerte Prometheus sont définies, organisées en fichiers thématiques couvrant les métriques système (CPU, mémoire, disque, filesystem), les services applicatifs, les sondes blackbox, le réseau et la santé SMART des disques. Ce sont les règles du groupe node (CPUHigh, MemHigh, FSDanger, FilesystemReadOnly) qui bénéficient directement de l'enrichissement Loki dans ce POC.

Première étape : reprise en main de la présentation des emails

Avant même de travailler sur l'enrichissement du contenu, un premier chantier a porté sur la mise en forme des notifications. Le format natif d'Alertmanager produit des emails fonctionnels mais austères : texte brut, aucune hiérarchie visuelle, et surtout aucune distinction entre une alerte active et sa résolution.

Un workflow n8n initial a donc été mis en place pour intercepter les événements via webhook et reconstruire entièrement l'email. Le code JavaScript en entrée du workflow parse le payload Alertmanager, extrait les champs utiles (nom de l'alerte, instance, sévérité, durée du downtime) et les transmet à un nœud de mise en forme HTML. Ce dernier génère un email structuré avec un code couleur immédiatement lisible : rouge pour une alerte active, vert pour une résolution, avec un sujet d'email conditionnel permettant le tri en boîte de réception d'un simple coup d'œil. Ce premier palier, relativement simple à mettre en œuvre, a suffi à transformer l'expérience utilisateur côté notification. C'est sur cette base que s'appuie l'étape suivante.

Workflow n8n : de l'alerte brute au diagnostic enrichi

Chaîne de traitement initiale

Le workflow recevait les alertes Alertmanager via webhook POST, extrayait les champs clés (alertname, instance, severity, status, durée), formatait un email HTML et l'envoyait. Fonctionnel, mais limité : aucun contexte, aucune aide au diagnostic.

Chaîne enrichie

Quatre nœuds ont été insérés entre le parsing de l'alerte et la mise en forme de l'email :

1. Build Queries (Code JavaScript) — Construit dynamiquement les requêtes Loki et Prometheus selon le type d'alerte. Par exemple, pour une alerte CPUHigh, la requête Prometheus calculera le pourcentage CPU réel via rate(node_cpu_seconds_total) ; pour FSDanger, elle cartographiera l'occupation de chaque point de montage.

2. Query Loki (HTTP Request) — Interroge l'API Loki sur une fenêtre de 15 minutes en filtrant les logs de l'instance concernée avec un pattern regex ciblant les niveaux error, critical, warn, fail, panic, oom et killed. Le label instance sert de clé de corrélation entre l'alerte Prometheus et les logs Loki.

3. Query Prometheus (HTTP Request) — Récupère la valeur en temps réel de la métrique en alerte. Le technicien voit immédiatement si le problème est toujours actif au moment de la lecture de l'email.

4. Analyse et Suggestions (Code JavaScript) — Compile les données et génère trois éléments à partir de règles déterministes (switch/case selon le type d'alerte) :

Un niveau de criticité calculé dynamiquement (pas seulement la severity de l'alerte, mais aussi le volume de logs d'erreur détectés).
La valeur temps réel de la métrique (ex : « 87.3% CPU »).
Des commandes de remédiation directement exécutables, adaptées au type d'incident. Par exemple, pour un disque plein : identification des répertoires volumineux, purge des anciens logs journald, nettoyage des paquets obsolètes.

L'email final intègre désormais un tableau de synthèse, les dernières lignes de logs Loki pertinentes, et une liste de commandes prêtes à l'emploi. La distinction visuelle entre alerte active et résolue est appliquée dès le sujet de l'email.

Bénéfices pour les équipes techniques

Même si l'analyse reste à affiner — notamment sur la pertinence des requêtes Loki selon les types d'incidents et la profondeur des suggestions — le gain est déjà perceptible dès ce premier niveau d'intégration. Les logs corrélés et la valeur temps réel réduisent la phase initiale d'investigation manuelle. Le technicien dispose de commandes de remédiation directement exploitables depuis l'email. Le niveau de criticité calculé automatiquement (intégrant le volume de logs d'erreur) offre une meilleure priorisation que la severity statique de l'alerte. La fenêtre de 15 minutes montre ce qui s'est passé juste avant le déclenchement — souvent plus révélateur que l'alerte elle-même. La chaîne est fonctionnelle de bout en bout ; il s'agit maintenant de l'enrichir itérativement pour gagner en précision.

Bénéfices pour les décideurs

Au-delà de l'aspect technique, ce POC démontre plusieurs points à valeur business. Le MTTR (Mean Time To Resolve) devrait diminuer quand le diagnostic arrive avec l'alerte, même si ce gain reste à mesurer sur la durée. Les suggestions de remédiation codifient le savoir-faire de l'équipe : même un junior ou un prestataire reçoit les bonnes commandes sans dépendre d'un expert disponible. L'ensemble repose sur des briques open source (Grafana, Prometheus, Loki, n8n, VyOS) — le surcoût est uniquement du temps d'intégration, pas de licences.

Perspectives

Ce POC constitue une première brique. Les évolutions envisagées, l'intégration d'un LLM pour compléter les suggestions statiques actuelles par un diagnostic en langage naturel adapté à chaque situation (objet du prochain article), l'extension aux alertes applicatives via les labels Loki dédiés aux services, une escalade intelligente vers un canal de communication d'équipe ou un runbook automatisé en cas de pattern critique détecté (OOM killer, I/O errors), et un feedback loop permettant aux techniciens de valider ou corriger les diagnostics pour améliorer les suggestions futures.

Je serai intéressé par vos retours et ouvert à toute remarque ou discussion sur le sujet.

Pierre-Marie Esposito