Contexte et limitation d'Alertmanager

Alertmanager génère les notifications à partir de modèles Go. Le modèle ne peut exploiter que les labels et les annotations que Prometheus a attachés lors du déclenchement de la règle. Aucun appel HTTP n’est possible au moment de l’envoi, ce qui empêche d’interroger directement Elasticsearch, Loki ou tout autre magasin de logs. Ainsi, les alertes ne contiennent aucune information de diagnostic supplémentaire, ce qui oblige les ingénieurs à ouvrir manuellement Kibana ou Loki, à ajuster la fenêtre temporelle et à filtrer par service.

Architecture du sidecar d'enrichissement

Le contournement repose sur un petit service autonome placé à côté d’Alertmanager. La configuration d’Alertmanager duplique chaque alerte vers un webhook supplémentaire ; ce webhook pointe vers le sidecar. Le service agit comme un récepteur secondaire : si le sidecar tombe, la page initiale continue d’être livrée par Alertmanager, mais sans enrichissement. Le sidecar ne modifie jamais le flux de pagination principal.

Mécanisme de corrélation et d'envoi

Lorsqu’une alerte arrive, le sidecar interroge les dernières minutes d’historique du canal Slack pour identifier le message correspondant. La correspondance s’appuie sur un empreinte (fingerprint) injectée dans le modèle Slack d’Alertmanager ; avant l’ajout du fingerprint, la recherche utilisait l’ensemble des labels affichés dans le texte. Une fois le message trouvé, le sidecar effectue un unique appel API thread_ts pour publier une réponse dans le même fil. La recherche est limitée à environ deux minutes afin d’éviter les faux positifs avec des alertes anciennes portant les mêmes labels.

Le sidecar construit ensuite une requête vers le magasin de logs (Loki ou Elasticsearch) à partir des labels service, namespace et severity. La requête récupère les dernières dix lignes d’erreur (ou moins) sur la période de cinq minutes précédant l’alerte. Si aucun résultat n’est trouvé, le sidecar publie tout de même un message indiquant l’absence de logs, ce qui oriente l’ingénieur vers d’autres investigations (infrastructure ou règle d’alerte).

Pour éviter les doublons lors du repeat_interval d’Alertmanager, le sidecar conserve en mémoire les empreintes déjà enrichies. Ainsi, une alerte ré‑émise ne génère pas de seconde réponse dans le même fil.

Impact opérationnel

Le service compte quelques centaines de lignes de code et se comporte de façon « boring », c’est‑à‑dire sans impact visible sur la chaîne de pagination. En pratique, l’ingénieur qui ouvre Slack voit immédiatement sous le message d’alerte les logs pertinents, éliminant la phase de recherche de tableau de bord, d’index ou de fenêtre temporelle. Cette proximité réduit le temps de diagnostic pour chaque incident contenant des logs, sans modification des services surveillés. Le même mécanisme peut être réutilisé pour injecter d’autres artefacts non disponibles à la compilation du modèle : liens de runbook, marqueur du dernier déploiement, URL de tableau de bord pré‑filtré. La solution repose sur trois principes clés : séparation du chemin de pagination, enrichissement via un fil de discussion Slack, et gestion stricte de l’idempotence.