Hygiène d'alerting — refonte ntfy en quatre canaux
Contexte
Toutes les notifications de la grappe (santé, supervision, incidents, alertes bus, dashboards) passaient par un canal ntfy unique. Une nuit, une rafale liée à un service flapping a envoyé plusieurs dizaines de notifications en quelques minutes. Le téléphone vibrant en boucle, impossible de distinguer le signal du bruit.
Contrainte
Trois exigences :
- Ne plus jamais subir de rafale liée à un message identique répété.
- Pouvoir distinguer au son de la notification le registre du message — infra qui tousse, base qui flanche, IA qui se réveille, dashboard qui s'anime.
- Garder une seule pile ntfy : pas question d'empiler des outils.
Décision
Quatre topics sémantiques, un seul moteur ntfy :
dashboard— événements user-facing, intéressants à voir mais sans urgence.mln-infra— état des nœuds, restarts, healthchecks.mln-db— bases de données, intégrité, latences.mln-ia— pipelines vision, Ollama, queues.
Côté serveur : un utilisateur dédié mln-services
avec un token par registre, chaque service ne peut publier que
sur son canal autorisé.
Côté déduplication : un cache persisté côté producteur. Avant
publication, le service calcule un hash
(topic, titre, body, fenêtre 5 min). Si le hash a
déjà été publié dans la fenêtre, l'envoi est suppressed.
Persisté car les services redémarrent et perdaient leur cache
en RAM — c'est précisément ce qui avait causé la rafale
initiale.
Mesure
Avant : pic mesuré à 47 notifications en 12 minutes pour un seul incident. Après : maximum observé 3 notifications distinctes pour un incident comparable, suivies d'un silence tant que la cause n'évolue pas.
Ce qu'il en reste
L'astreinte n'est plus réveillée par du bruit. La distinction sonore par canal permet de jauger en deux secondes si on doit se lever ou pas. Le pattern de déduplication persistée a essaimé sur d'autres services qui parlent à des webhooks externes — même bénéfice partout.