Configurer les alertes Azure Monitor et les action groups

Tout ce que j'ai déployé sur Azure jusqu'ici, j'ai découvert les problèmes en ouvrant et en regardant. Ça marche pour un projet d'apprentissage sans utilisateurs. Ça ne marche évidemment pas pour quoi que ce soit de réel, ce qui m'a amené à cette partie de l'AZ-900.

Les deux moitiés d'une alerte

Ce qui a fait tilt pour moi, c'est qu'Azure divise l'alerting en deux pièces séparées, et elles font des travaux différents.

Une alert rule, c'est la condition. Elle observe une métrique ou un log et décide quand quelque chose compte comme un problème : CPU au-dessus de 80 % pendant cinq minutes, réponses HTTP 5xx au-dessus d'un certain compte, une VM qui a arrêté de répondre.

Un action group, c'est ce qui se passe ensuite. C'est la liste de qui est notifié et comment : envoyer un email, envoyer un SMS, appeler un webhook, déclencher une Logic App ou une Function.

Les garder séparés semblait être une indirection inutile jusqu'à ce que je pense à l'alternative. Si les détails de notification vivaient à l'intérieur de chaque alert rule, changer qui est prévenu voudrait dire modifier chaque règle jamais créée. Avec les action groups, la liste de contacts est définie une fois et référencée par chaque règle qui en a besoin. Changez-la à un seul endroit, chaque alerte suit.

Sur quoi vous pouvez vraiment mettre une alerte

Deux grandes sources, et la différence compte.

Les metric alerts tournent sur des données numériques que les resources émettent en continu : pourcentage de CPU, mémoire, nombre de requests, temps de réponse, usage disque. Elles s'évaluent rapidement et sont le bon outil pour « cette resource est-elle en bonne santé maintenant ».

Les log alerts exécutent une query sur des logs collectés selon un planning. Plus lentes, plus flexibles, et le bon outil pour des choses qu'une métrique ne peut pas exprimer, comme « plus de dix tentatives de connexion ratées depuis la même IP en cinq minutes ».

Pour le genre d'applications que je construis, celles basées sur des métriques couvrent la plupart de ce que je voudrais. Le temps de réponse qui monte et le taux d'erreur qui monte sont les deux signaux qui me disent que quelque chose ne va pas avant qu'un utilisateur ne me le dise.

Les alertes ont une severity, et ce n'est pas de la décoration

Les alert rules reçoivent une severity de 0 à 4, où 0 est critique et 4 est verbeux. Ça a l'air d'être une métadonnée qu'on remplit et qu'on ignore.

Ça ne l'est pas, parce que c'est ce qui permet de router différentes urgences vers différents action groups. Une alerte severity 0 peut déclencher un SMS à 3 heures du matin. Une severity 3 peut envoyer un email lu le lundi. Sans severities, tout est également urgent, ce qui en pratique veut dire que rien ne l'est, parce que les gens finissent par ignorer le canal.

Le mode de défaillance, c'est trop d'alertes, pas trop peu

C'est la chose la plus utile que j'ai tirée en étudiant ça, et ce n'est pas un détail technique.

Une alerte qui se déclenche constamment finit ignorée. Une fois qu'une équipe apprend qu'une alerte en particulier est généralement du bruit, elle arrête de la lire, et c'est alors pire que de n'avoir aucune alerte, parce que tout le monde croit que quelque chose est surveillé alors qu'en fait rien ne l'est.

Donc la question utile en créant une alerte n'est pas « aimerais-je être au courant de ça ». C'est « si ça se déclenche, y a-t-il quelque chose que je ferais vraiment ? » Si la réponse honnête est non, l'alerte est du bruit portant une étiquette d'avertissement. Un dashboard est le bon endroit pour l'information que vous voulez pouvoir consulter ; une alerte est pour les choses qui nécessitent que quelqu'un agisse.

Ce que je mettrais en place pour mes propres projets

Pour l'API que j'ai qui tourne sur Container Apps, trois alertes couvriraient les défaillances réalistes : le taux d'erreur qui grimpe, le temps de réponse qui grimpe, et l'app qui échoue à son health check.

C'est tout. Pas le CPU, pas la mémoire, pas la douzaine d'autres métriques disponibles, parce que je ne ferais rien de différent en me basant dessus. Si le CPU est élevé et que rien n'est lent et que rien n'échoue, alors rien ne va vraiment mal.

Ce que je n'ai toujours pas fait

J'ai étudié ça plutôt que de le faire tourner. Mettre en place des alertes sur une application vivante puis vivre avec pendant un moment est une expérience différente de comprendre les concepts, et je m'attendrais à ce que ce soit là que j'apprendrais ce que mes seuils devraient vraiment être. Choisir un nombre pour « le temps de réponse est trop élevé » sans vrai trafic pour comparer est une supposition, et la seule façon de la corriger, c'est de supposer, d'observer, et d'ajuster.