Les fondamentaux des alarmes CloudWatch

Deux alarmes, même nuit, même compte. La première ne s'est jamais déclenchée pendant que la file de paiement accumulait 40 minutes de retard. La seconde s'est déclenchée 14 fois entre 02h00 et 03h00 alors que rien n'allait mal. Les deux ont été construites par des ingénieurs qui savaient exactement ce que veulent dire CPUUtilization et ApproximateAgeOfOldestMessage. Aucun des deux ne savait comment CloudWatch décide qu'une alarme change d'état.

Cette décision, c'est là que les alarmes se gagnent et se perdent. Une métrique n'est qu'une liste de nombres, et vous savez déjà comment CloudWatch les stocke. Une alarme est une petite machine à états posée sur cette liste, et presque toutes les plaintes sur les alarmes en production remontent à l'un des quatre réglages qu'elle contient.

De quoi une alarme est faite

Une alarme métrique surveille une métrique (ou une expression metric math) et occupe l'un de trois états. Pour décider lequel, elle a besoin de réponses à six questions :

Un septième réglage, le traitement des données manquantes, ne compte que lorsque les données se taisent. Il a sa propre section plus bas parce qu'il cause plus de surprises que les six autres réunis.

Voici une alarme avec de vraies valeurs : surveiller CPUUtilization pour l'instance i-0a1b2c3d4e5f67890, prendre la moyenne (Average) sur chaque période de 60 secondes, déclarer une période mauvaise quand la moyenne dépasse 80, et passer en ALARM quand 3 des 5 dernières périodes étaient mauvaises.

aws cloudwatch put-metric-alarm \
  --alarm-name "checkout-api-cpu-high" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f67890 \
  --statistic Average \
  --period 60 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --treat-missing-data missing \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:ops-critical

Trois états, et la règle que presque tout le monde rate

Une alarme est toujours dans exactement l'un de ces états :

• OK : la métrique est dans le seuil.
• ALARM : la métrique est hors du seuil.
• INSUFFICIENT_DATA : l'alarme vient de démarrer, la métrique n'est pas disponible, ou il n'y a pas assez de données pour trancher.

INSUFFICIENT_DATA n'est pas une erreur. Une alarme neuve y démarre par conception, et un volume EBS disponible mais attaché à aucune instance cesse de publier des métriques, ce qui est une raison parfaitement saine pour que son alarme reste dans cet état.

Maintenant la règle : une alarme déclenche ses actions uniquement quand elle change d'état. Pas à chaque période. Pas à chaque minute. Une fois, sur la transition.

Il est tentant de croire qu'une alarme bloquée en ALARM continue de vous appeler, et qu'un téléphone silencieux veut dire que le problème est réglé. Les deux sont faux. L'alarme a envoyé une notification quand elle est passée en ALARM et attend tranquillement depuis. Si votre processus a besoin de rappels tant qu'un incident est ouvert, cette répétition vient de votre outil d'astreinte, pas de CloudWatch.

Il existe exactement une exception, et l'examen l'aime bien : pour les actions Auto Scaling, l'alarme continue d'invoquer l'action une fois par minute tant qu'elle reste dans le nouvel état. C'est volontaire, parce qu'une scaling policy qui se déclencherait une fois puis se tairait ne finirait jamais de scaler un groupe très surchargé.

Period, Evaluation Periods et Datapoints to Alarm

Ces trois réglages sont l'origine des alarmes qui « ne se déclenchent jamais » et de celles qui « se déclenchent 14 fois ». Travaillez-les avec des chiffres plutôt qu'avec des définitions.

Period est la durée couverte par chaque datapoint. Les valeurs valides sont 10, 20, 30, ou n'importe quel multiple de 60 secondes.

Evaluation Periods (N) est le nombre de datapoints les plus récents que l'alarme regarde.

Datapoints to Alarm (M) est le nombre de ces N qui doivent être en dépassement pour que l'alarme passe en ALARM. Les points en dépassement n'ont pas besoin d'être consécutifs. Ils doivent seulement tomber dans la fenêtre des N derniers.

Quand M est égal à N, vous avez une alarme « périodes consécutives » : chaque point de la fenêtre doit dépasser le seuil. Quand M est plus petit que N, vous avez une alarme M sur N, qui tolère un point sain au milieu d'une mauvaise série.

L'intervalle d'évaluation est simplement N multiplié par la period. Quatre datapoints sur cinq avec une period d'une minute donnent un intervalle de 5 minutes. Trois sur trois avec une period de 10 minutes donnent 30 minutes.

Pour toute period d'une minute ou plus, l'alarme est évaluée chaque minute, et la fenêtre glisse. Avec une period de 5 minutes et 1 evaluation period, la fin de la minute 5 évalue les minutes 1 à 5, et la fin de la minute 6 évalue les minutes 2 à 6. Si la period est de 10, 20 ou 30 secondes, l'alarme est évaluée toutes les 10 secondes.

Deux quotas bornent la profondeur de vue d'une alarme. Period multiplié par Evaluation Periods vaut au maximum 604 800 secondes (sept jours) pour les alarmes dont la period est d'au moins une heure, et 86 400 secondes (un jour) pour tout ce qui est plus court. Et une alarme dont la fenêtre dépasse une journée devient une alarme multi-jours, évaluée seulement une fois par heure et ne prenant en compte que les métriques jusqu'à l'heure courante à la minute :00. Un job qui échoue à 10h02 ne fera pas bouger une telle alarme à 10h03 ; elle réagira à 11h03.

Données manquantes : ce que le silence veut dire

Chaque datapoint de la fenêtre est l'une de trois choses : dans le seuil, en dépassement, ou manquant. Les deux premières sont évidentes. La troisième est un jugement que vous seul pouvez porter, parce que CloudWatch n'a aucun moyen de savoir si une métrique devenue silencieuse veut dire « tout va bien » ou « ce qui publie cette métrique est mort ».

Vous le lui dites donc, avec l'un de ces quatre réglages :

Le défaut est missing. Deux exceptions valent la peine d'être mémorisées. Les alarmes sur les métriques du namespace AWS/DynamoDB prennent toujours ignore par défaut. Et AWS recommande explicitement missing pour les alarmes qui arrêtent, terminent, redémarrent ou récupèrent des instances EC2, parce que la remontée des métriques EC2 peut être brièvement interrompue sur une instance en parfaite santé, et vous ne voulez pas qu'un trou de reporting termine un serveur de production.

Deux choix concrets : ThrottledRequests sur DynamoDB ne publie un datapoint que lorsqu'une requête est throttlée, donc notBreaching est le bon réglage. Une alarme qui déclenche un rollback de déploiement surveille une métrique qui remonte en continu, donc un trou signifie probablement que l'application ne répond plus, et breaching est le bon réglage.

La plage d'évaluation, et pourquoi votre réglage est souvent ignoré

Voici la partie qui fait que les alarmes se comportent d'une façon que les réglages ne prédisent pas de manière évidente.

À chaque évaluation, CloudWatch récupère plus de datapoints que Evaluation Periods. La fenêtre temporelle de ces points supplémentaires s'appelle la plage d'évaluation. Pour une alarme avec 3 evaluation periods, la plage d'évaluation est de 5 datapoints.

Ensuite il applique trois règles, dans cet ordre :

1. Si aucun point de la plage d'évaluation ne manque, il évalue les N plus récents et ignore les points supplémentaires.
2. S'il en manque mais que le nombre total de points réels récupérés atteint au moins N, il évalue les N points réels les plus récents, en remontant dans les points supplémentaires. Votre réglage des données manquantes n'est pas utilisé du tout.
3. Seulement si les points réels restent moins nombreux que N, CloudWatch comble les trous avec votre réglage, et encore, il utilise le moins de points substitués possible.

Voyez cela comme un professeur qui note vos 3 derniers devoirs. Si deux des trois derniers n'ont jamais été rendus, le professeur remonte au 4e et au 5e devoir au lieu de compter zéro pour les manquants. L'analogie casse sur un point : le professeur remonterait indéfiniment, alors que CloudWatch ne remonte que jusqu'à la limite de la plage d'évaluation avant de retomber sur votre réglage.

C'est pour cela que deux ingénieurs peuvent régler breaching et notBreaching sur la même métrique intermittente et voir les deux alarmes se comporter à l'identique pendant des semaines.

Une dernière pièce de logique s'appelle l'évitement d'un état d'alarme prématuré. Avec Datapoints to Alarm à 3, une série - - - - X (quatre manquants puis un dépassement) ne passe pas immédiatement en ALARM, parce que le point suivant peut être sain. Mais une série - - X - - passe bien en ALARM même avec les données manquantes traitées comme missing, parce que le point en dépassement disponible le plus ancien est au moins aussi ancien que la valeur de M et que tout ce qui est plus récent est en dépassement ou manquant. N'attendez pas du seul tableau des données manquantes qu'il prédise ces cas limites.

Les alarmes haute résolution

Réglez la period sur 10, 20 ou 30 secondes et vous avez créé une alarme haute résolution, évaluée toutes les 10 secondes et facturée plus cher qu'une alarme normale.

N'utilisez ces periods que pour des métriques publiées avec une storage resolution de 1, c'est-à-dire vos propres métriques custom haute résolution. Pointez une alarme de 10 secondes vers une métrique en résolution standard et CloudWatch cherchera quand même des données toutes les 10 secondes, ne trouvera rien cinq fois sur six, et fera régulièrement retomber l'alarme en INSUFFICIENT_DATA. Vous obtenez une alarme peu fiable et le tarif premium en même temps.

Au-delà d'un nombre fixe

Toutes les questions n'ont pas un seuil fixe, et CloudWatch offre deux façons de dépasser cette limite.

Les alarmes metric math surveillent le résultat d'une expression plutôt qu'une métrique brute. Le cas classique est un taux d'erreur, parce que « 500 erreurs » ne veut pas dire la même chose sur 600 requêtes que sur 6 millions :

{
  "Metrics": [
    { "Id": "errors",   "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionsFailed" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "attempts", "MetricStat": { "Metric": { "Namespace": "MyService", "MetricName": "ConnectionAttempts" }, "Period": 60, "Stat": "Sum" }, "ReturnData": false },
    { "Id": "error_rate", "Expression": "(errors/attempts)*100", "ReturnData": true, "Label": "Taux d'erreur de connexion" }
  ],
  "Threshold": 40,
  "ComparisonOperator": "GreaterThanThreshold",
  "EvaluationPeriods": 3
}

Un seul élément du tableau Metrics porte ReturnData à true, et c'est l'expression que l'alarme surveille.

Les alarmes anomaly detection n'ont aucun seuil fixe. CloudWatch entraîne un modèle de machine learning sur jusqu'à deux semaines de données passées de la métrique, apprend ses motifs horaires, quotidiens et hebdomadaires ainsi que sa tendance de fond, et produit une bande de valeurs attendues. L'alarme se déclenche alors quand la métrique sort au-dessus de la bande, en dessous, ou des deux côtés.

{
  "Metrics": [
    { "Id": "m1", "ReturnData": true, "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization" }, "Stat": "Average", "Period": 60 } },
    { "Id": "t1", "Expression": "ANOMALY_DETECTION_BAND(m1, 3)" }
  ],
  "ThresholdMetricId": "t1",
  "ComparisonOperator": "LessThanLowerOrGreaterThanUpperThreshold",
  "EvaluationPeriods": 2
}

Le 3 est le seuil d'anomaly detection, et un nombre plus élevé produit une bande plus épaisse et moins d'alertes. Quatre détails décident si c'est le bon outil :

• Le modèle est propre à une métrique et à une statistique. Un modèle entraîné sur Average ne vous dit rien sur Maximum.
• Vous pouvez exclure des périodes de l'entraînement, ce qui évite que le test de charge du mois dernier apprenne au modèle qu'un pic multiplié par 10 est normal.
• Les alarmes basées sur un modèle d'anomaly detection ne peuvent pas porter d'actions Auto Scaling.
• Chaque alarme anomaly detection est facturée comme trois métriques d'alarme en résolution standard (la métrique plus les bornes haute et basse), soit environ 0,30 $ par mois contre 0,10 $ pour une alarme métrique simple.

L'anomaly detection mérite sa place sur des métriques avec une forme quotidienne marquée, comme le nombre de requêtes d'une application grand public. C'est le mauvais outil pour une métrique dont toute valeur non nulle est mauvaise.

Diagnostiquer une alarme qui ne quitte pas INSUFFICIENT_DATA

C'est le ticket d'alarme le plus fréquent, et la liste des causes est courte :

• La period est plus courte que la résolution de la métrique. Le monitoring EC2 de base publie toutes les 5 minutes, donc une period de 60 secondes laisse quatre périodes vides sur cinq.
• Le jeu de dimensions n'a jamais été publié. Une alarme peut être créée avant que sa métrique custom n'existe, et elle restera en INSUFFICIENT_DATA indéfiniment si les dimensions ne correspondent pas exactement à ce que vous publiez.
• Une Unit a été précisée alors que la métrique ne l'utilise jamais. AWS recommande d'omettre Unit complètement, parce qu'un décalage produit une alarme bloquée plutôt qu'une erreur.
• La ressource est réellement inactive. Les volumes EBS détachés, les fonctions Lambda sans invocation et les Auto Scaling groups à zéro instance cessent tous de publier.

L'historique d'alarme est conservé 30 jours, et describe-alarm-history montre chaque transition d'état avec son horodatage. C'est votre premier réflexe quand quelqu'un demande si une alarme s'est déclenchée un jour.

aws cloudwatch describe-alarm-history \
  --alarm-name "checkout-api-cpu-high" \
  --history-item-type StateUpdate \
  --max-records 10

Conseils pour l'examen

• « L'alarme est restée en ALARM mais nous n'avons reçu qu'un seul email » n'est jamais un bug. Les actions se déclenchent au changement d'état. La seule action réinvoquée pendant que l'état tient est une action Auto Scaling, une fois par minute.
• Lisez la formulation des seuils attentivement. « 3 périodes consécutives » veut dire M égal N ; « 3 sur 5 » veut dire M à 3 et N à 5, et les points en dépassement peuvent être dispersés.
• Reliez les options de données manquantes à la nature de la métrique : une métrique qui ne publie qu'en cas d'échec pointe vers notBreaching ; une métrique remontée en continu où le silence est suspect pointe vers breaching ; les alarmes EC2 stop, terminate, reboot et recover pointent vers missing, qui est aussi le défaut global.
• Une period de 10, 20 ou 30 secondes veut dire alarme haute résolution, et cela ne marche que sur des métriques stockées en résolution 1 seconde. Un énoncé qui mentionne à la fois une period sous la minute et une métrique publiée par AWS décrit une alarme cassée.
• Si un scénario dit « aucun seuil fixe ne convient, le niveau normal change selon l'heure de la journée », la réponse est anomaly detection, et rappelez-vous qu'elle ne peut pas piloter l'Auto Scaling.
• Une fenêtre d'alarme de plus d'une journée est évaluée toutes les heures sur les données jusqu'au début de l'heure, et la fenêtre totale plafonne à sept jours.

La règle à retenir : l'état d'une alarme est décidé par une fenêtre glissante des N derniers datapoints, et tout ce qui semble imprévisible dans les alarmes vient de ce que fait CloudWatch quand cette fenêtre a des trous. Vous allez maintenant suivre la notification hors de l'alarme jusque dans Amazon SNS, où une autre série de pannes silencieuses vous attend.