Configurer la surveillance CloudWatch sur AWS pour attraper les vrais incidents (pas 400 alarmes jamais lues)

Une configuration de surveillance CloudWatch qui attrape les vrais incidents est plus petite que ce que la plupart des équipes imaginent : environ une douzaine d’alarmes sur des symptômes visibles par les clients — taux d’erreur, latence, saturation, sauvegardes échouées — acheminées via SNS vers un chemin qui réveille réellement quelqu’un, et tout ce sur quoi personne n’agit est supprimé. Quatre cents alarmes qui alimentent une boîte de réception jamais lue, ce n’est pas de la surveillance, c’est de la décoration, et ce sont les clients qui deviennent la couche de détection. La mise en place demande une journée concentrée; le plus difficile, c’est la discipline de garder chaque alarme actionnable.

Ce qui se passe

Aucun compte n’atteint 400 alarmes volontairement. On y arrive par les valeurs par défaut acceptées à la console, des modules Terraform copiés avec leurs blocs d’alarmes, des alarmes ponctuelles créées durant un vieil incident et jamais retirées, et chaque nouveau service qui ajoute des alarmes pendant que personne n’en supprime. Le résultat, c’est la fatigue d’alerte, et son mécanisme est bien documenté : dès qu’une fraction significative des notifications est du bruit, les humains cessent de toutes les lire, y compris celle qui comptait.

CloudWatch offre trois blocs de construction. Les alarmes métriques surveillent un seuil sur une métrique ou une expression mathématique. Les alarmes composites combinent plusieurs alarmes avec de la logique booléenne, utile pour supprimer le bruit en aval quand une dépendance en amont est déjà en alarme. La détection d’anomalies alerte sur l’écart par rapport à une bande apprise — le bon outil pour « le trafic a chuté de 40 % sous la normale », une panne qu’aucun seuil statique n’attrape. La référence complète est dans la documentation CloudWatch.

La chaîne de livraison est l’endroit où la plupart des configurations cassent en silence : alarme, puis sujet SNS, puis abonnement, puis un humain. Un sujet sans abonnés, un canal Slack que quelqu’un a mis en sourdine, le courriel d’une personne partie — chacun de ces cas produit un compte qui a l’air surveillé et ne l’est pas. L’autre défaut structurel : alerter sur des causes plutôt que sur des symptômes. Un CPU à 90 % est une cause et peut être parfaitement normal; un taux de 5xx à 2 % est un symptôme et ne l’est jamais.

Quoi vérifier en premier

• Combien d’alarmes sont en état ALARM ou INSUFFICIENT_DATA en ce moment, et depuis des semaines — c’est votre plancher de bruit, et tout le monde a déjà appris à l’ignorer.
• Où pointent les actions d’alarme. Les sujets SNS sans abonnés sont la trouvaille la plus fréquente lors des revues de comptes.
• Si quelque chose alerte sur des symptômes visibles par l’utilisateur (pourcentage de 5xx à l’ALB, latence p95, âge de la file) plutôt que seulement des métriques d’hôte.
• Si un chemin de livraison après les heures existe, ou si tout se termine dans un courriel.
• La dernière fois qu’une alarme a poussé un humain à agir. Si personne ne s’en souvient, la configuration a déjà échoué une fois, en silence.

Comment vérifier

Comptez le bruit et suivez le chemin de livraison :

# Combien d'alarmes sont déclenchées en ce moment?
aws cloudwatch describe-alarms --state-value ALARM \
  --query 'length(MetricAlarms)'

# Chaque alarme, son action et son état
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,AlarmActions[0],StateValue]' \
  --output table

# Le sujet visé par ces actions a-t-il des abonnés actifs?
aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:ca-central-1:123456789012:ops-alerts

Dans la console, CloudWatch > Alarms > All alarms, filtré par état, donne le même portrait. Ensuite, faites un exercice réel :

aws cloudwatch set-alarm-state --alarm-name prod-alb-5xx-rate \
  --state-value ALARM --state-reason "paging drill"

Si rien n’atteint un téléphone en quelques minutes, la surveillance n’existe pas de façon utile, peu importe le nombre d’alarmes.

Le plan d’exécution

1. Inventorier et couper. Exportez la liste des alarmes et supprimez tout ce qui n’a ni action, ni propriétaire, ni changement d’état suivi d’une action depuis 90 jours. Supprimer une alarme que personne ne lit ne perd rien et rachète de l’attention.
2. Alerter d’abord sur les symptômes. Pourcentage de 5xx à l’ALB (un taux, pas un compte absolu), latence p95 des cibles, hôtes en mauvaise santé, âge des files, retard de réplica, échecs de sauvegarde, expiration de certificat, disque qui se remplit. La base de onze alarmes CloudWatch est un point de départ prêt à copier, avec des seuils défendus.
3. Séparer les sévérités en deux chemins. Deux sujets SNS : un qui téléavertit (PagerDuty, Opsgenie ou un chemin SMS/appel), un qui crée des billets. Une alarme qui ne justifie pas de réveiller quelqu’un à 2 h du matin n’a pas sa place sur le sujet de garde.
4. Éliminer le clignotement. Utilisez DatapointsToAlarm à 3 sur 5 périodes d’évaluation pour tout ce qui téléavertit, pour qu’un seul point aberrant ne déclenche rien. Réglez TreatMissingData délibérément par alarme au lieu d’accepter le défaut.
5. Couvrir les pannes silencieuses. Pour les métriques de type battement de cœur (résultats de cron, compte de sauvegardes), traitez les données manquantes comme une violation — un pipeline mort doit téléavertir, pas disparaître. Ajoutez une alarme de détection d’anomalies sur le compte de requêtes pour attraper « le trafic est tombé à zéro ».
6. Exercer le chemin de livraison chaque trimestre. set-alarm-state durant une fenêtre de maintenance, en chronométrant le temps jusqu’à la prise en charge par un humain.
7. Réviser chaque semaine, quinze minutes. Pour chaque alarme déclenchée : était-elle actionnable? Sinon, on la règle ou on la supprime le jour même. Cette seule habitude sépare les comptes qui restent propres de ceux qui redérivent vers 400.

Quand c’est la mauvaise approche

Si personne ne répondra à l’appel — pas de rotation, pas d’attente de réponse convenue, pas de couverture après les heures — de meilleures alarmes ne font que documenter les pannes en temps réel. Réglez la question de la responsabilité avant d’ajuster des seuils. À l’autre extrême, un simple site à faible enjeu n’a pas besoin de cette machinerie; une vérification de disponibilité externe suffit honnêtement. Et les alarmes CloudWatch disent que quelque chose a cassé, pas quel appel en aval est lent — si c’est la question récurrente, vous magasinez du traçage (X-Ray ou un APM), pas plus d’alarmes.

Erreurs fréquentes

• Alerter sur des causes (CPU, mémoire) pendant que rien ne surveille les symptômes que les clients ressentent.
• Un seul sujet SNS pour tout, de sorte qu’un avertissement cosmétique et une panne de production reçoivent le même traitement.
• TreatMissingData laissé au défaut, si bien qu’un pipeline de métriques mort ressemble à un compte sans problèmes.
• Le courriel comme seul chemin après les heures — un délai de lecture médian qui se mesure en heures, pas en minutes.

Garder le contrôle

• Chaque alarme a un propriétaire nommé et une ligne de procédure : quoi faire quand elle sonne.
• Mettre un service en production inclut ses alarmes dans le même changement, via la même infrastructure en code.
• Des exercices de garde trimestriels, avec le temps de prise en charge consigné.
• Une règle permanente : toute alarme jugée non actionnable à la revue hebdomadaire est corrigée ou supprimée le jour même.
• Suivre le nombre d’appels par semaine comme métrique de santé; une tendance à la hausse signale des seuils qui dérivent, ou une fiabilité qui dérive.

Une douzaine d’alarmes bien acheminées battent quatre cents alarmes ignorées à tout coup, mais elles supposent encore que quelqu’un décroche. Si les alertes sonnent dans une pièce vide après les heures, c’est exactement l’écart que ferme la Surveillance et intervention 24/7 — planifiez une revue de surveillance.