Le monitoring avait des angles morts (dont mon canal d'alerte)

J’avais la triptyque complète : métriques (Prometheus), logs (Loki) et traces (Tempo), reliées dans Grafana. De quoi se sentir tranquille. Sauf qu’« avoir Prometheus » ne veut pas dire « tout est surveillé ». En listant les cibles réellement scrapées, le constat piquait : quatre briques importantes n’envoyaient rien.

Angle mort	Pourquoi ça fait mal
Postgres (×6 instances)	0 visibilité : connexions, taille, locks, lag de réplication
cloudflared	c’est le tunnel d’ingress — le SPOF par excellence
n8n	il pilote le déploiement et les sauvegardes
ntfy	mon canal de notifications… donc mes alertes

Le plus gros trou : Postgres

Six bases applicatives, et aucune métrique. C’était l’angle mort le plus béant — d’autant qu’un projet de réplica streaming se profile. La solution colle au pattern déjà en place : chaque stack a déjà un sidecar pg-dump qui parle à sa base ; j’ai ajouté à côté un postgres-exporter, branché sur le même réseau interne. Un seul job Prometheus agrège les quatre, chacun étiqueté app=<nom> — ce label pilote la variable du dashboard.

Bonus involontaire : pg_replication_lag_seconds est déjà exposé. Il vaut 0 sur un primaire, donc l’alerte de lag est écrite mais dormante — elle se réveillera toute seule le jour où le second nœud hébergera un réplica. Le futur est déjà câblé.

Le piège : un nom de service ne traverse pas les stacks

Premier exporter déployé, Prometheus le voit DOWN. Pourtant le conteneur tourne. Le détail qui tue, sur Docker Swarm : le nom court d’un service n’est résolvable que dans sa propre stack. Prometheus vit dans la stack observability, l’exporter dans la stack de l’app — sur l’overlay partagé, le DNS ne connaît pas mon-exporter.

La parade n’est pas un hack, c’est l’API prévue pour ça : un alias réseau explicite sur l’overlay partagé.

networks:
  traefik-public:
    aliases:
      - stickers-pg-exporter   # désormais résolvable cross-stack

Leçon retenue, gravée dans les notes : on construit les dashboards à partir du /metrics réel (un curl jetable sur l’overlay), jamais à partir de noms de métriques devinés.

cloudflared : surveiller le SPOF

Tout le trafic entrant passe par un seul tunnel. S’il tombe, le site entier disparaît — et pourtant je ne le regardais pas. Un flag --metrics plus tard, je suis la métrique qui compte vraiment : cloudflared_tunnel_ha_connections. ≥ 1 = une connexion saine vers le edge Cloudflare. Le démon peut très bien tourner sans connexion : deux alertes distinctes, donc — processus mort, et processus vivant mais coupé du edge.

ntfy : exposer `/metrics` sans l’exposer

ntfy est public (l’app mobile s’y connecte). Activer les métriques sur son port principal, c’était les offrir à Internet. La bonne porte : un listener dédié sur un port séparé, joignable seulement depuis l’intérieur du cluster. /metrics existe, mais pas pour le monde.

La vérité gênante : on ne s’alerte pas de sa propre panne

Restait à câbler les alertes Grafana. Tunnel mort, base injoignable, n8n à terre : tout part en notification push sur ntfy. Logique. Et puis cette évidence : « alerte : ntfy est down ».

Comment cette alerte voyagerait-elle ? Par ntfy. Si ntfy est tombé, l’alerte qui le signale… ne part jamais. C’est le paradoxe du veilleur : un système ne peut pas surveiller son propre canal d’alerte. J’ai donc délibérément omis cette règle — mieux vaut pas d’alerte qu’une fausse assurance.

La vraie réponse est un dead-man’s-switch externe : un service hors du cluster qui attend un battement de cœur régulier et hurle (par un autre canal) s’il n’arrive plus. C’est la prochaine brique. En attendant, l’honnêteté : je sais ce qui n’est pas couvert.

Tester pour de vrai

Une alerte jamais déclenchée est une alerte qu’on croit fonctionnelle. J’ai baissé un seuil le temps d’un déploiement, regardé la règle passer en firing, la notification arriver sur le téléphone, puis le resolved la suivre — avant de tout remettre. Le chemin Grafana → relais → ntfy est confirmé de bout en bout, pas juste « probablement bon ».

Quatre cibles de plus, deux dashboards par service, six règles d’alerte — et surtout une carte plus honnête de ce que je vois et de ce qui m’échappe encore. Le code est public.