Bonnes pratiques d'alerting : Prometheus, Alertmanager et astreinte

1. Concevoir les alertes #

Moins, mais mieux.

Principes #

• Alerter sur les symptômes vus par l'utilisateur (erreurs, latence, saturation), idéalement à partir des SLO.
• Trois sévérités maximum : critical (réveille), warning (heures ouvrées), info (pas de notification).
• Un label team sur chaque alerte, un runbook_url sur chaque alerte critique.
• Un for d'au moins quelques minutes pour éviter le bruit.
• Des règles testées avec promtool test rules en CI.

2. Router et réduire le bruit #

Le bon message à la bonne personne.

Réglages #

• group_by sur alertname et cluster (ou service), jamais sur instance pour les alertes de parc.
• Inhibitions pour les pannes en cascade (cluster injoignable, nœud down).
• mute_time_intervals pour les warnings la nuit et le week-end.
• Silences courts, ciblés et commentés.
• Secrets dans des fichiers (*_file), configuration validée par amtool check-config en CI.

3. Fiabilité de l'alerting #

L'alerting est un service critique.

Check-list #

• Cluster de 2 ou 3 Alertmanager, Prometheus configuré vers tous les membres.
• Watchdog vers un dead man's switch externe.
• Alerte sur alertmanager_notifications_failed_total.
• Revue hebdomadaire : taux d'alertes actionnables, alertes les plus bruyantes, alertes jamais déclenchées.

Schéma de référence et vérification rapide #

Avant la mise en production.

Vérification #

1. Chaque équipe a sa route et son récepteur
2. Les critiques vont vers l'outil d'astreinte
3. Les warnings sont coupés la nuit
4. Watchdog en place
5. Règles et routes testées en CI
6. Runbooks accessibles depuis la notification