Skip to main content
Une nouvelle application peut envoyer trop d’alertes. Les seuils sont définis avant que quiconque connaisse la plage normale de la métrique, les triggers surveillent chaque hôte et chaque valeur de tag, et toutes les notifications partent vers un seul canal. En quelques semaines, l’équipe commence à ignorer ce canal, et peu après quelqu’un en désactive les notifications. Cette page est l’étape d’affinage qui corrige cela. Les étapes sont classées selon la quantité de bruit que chacune supprime, de sorte que travailler de haut en bas apporte l’essentiel du bénéfice rapidement. Pour le fonctionnement de chaque réglage, consultez affiner vos alertes. Les deux étapes qui suppriment généralement le plus de notifications sont utiliser des filtres de tags exacts plutôt que de larges caractères joker et limiter les valeurs de tags à un petit ensemble fixe. Toutes deux empêchent un trigger d’ouvrir des alertes pour des valeurs que vous n’aviez pas l’intention de surveiller.

​
Choisir une destination selon la rapidité d’action requise

L’essentiel du bruit de notification vient d’alertes envoyées vers un canal qui suggère plus d’urgence qu’elles n’en ont. Choisissez la destination en fonction de la rapidité avec laquelle quelqu’un doit agir.
  • Les clients perdent de l’argent ou l’accès cette nuit. Astreinte, comme PagerDuty ou Opsgenie.
  • Cela empire, mais rien n’est encore perdu. Chat d’équipe, comme Slack.
  • Demain convient tout à fait. E-mail, ou un canal de chat à faible trafic.
  • Rien, car c’est déjà connu. Aucun notifier.
Chaque trigger sélectionne ses propres notifiers. Un trigger sans notifier enregistre toujours ses alertes, vous pouvez donc surveiller une métrique sans envoyer de notifications. Donnez à la staging son propre canal, ou laissez ses triggers sans notifier. Des alertes de staging qui arrivent dans un canal de production sont le moyen le plus rapide d’apprendre à une équipe à ignorer ce canal.

​
Restreindre chaque trigger à la série que vous visez réellement

Un trigger n’ouvre pas une alerte. Il ouvre une alerte par série correspondante. Un trigger d’hôte laissé sur son hostname par défaut * couvre tous les hôtes qui rapportent à l’application, donc 30 hôtes franchissant un seuil ensemble produisent 30 notifications pour un seul problème. Restreignez la portée jusqu’à ce que la notification indique exactement ce qui est affecté :
  • Remplacez * par un hostname précis, ou un préfixe comme web-*. Les valeurs de tags acceptent les caractères joker, donc hostname=frontend* restreint un trigger à une classe de machines.
  • Restreignez les triggers de taux d’erreurs et de temps de réponse à un seul namespace, afin que web, background et admin puissent porter des seuils et des destinations différents.
  • Ajoutez un tag pour la ressource précise qui vous intéresse, comme un seul mountpoint plutôt que tous les systèmes de fichiers montés.

​
Utiliser des filtres de tags exacts ou envoyer une métrique d’alerte dédiée

Cette limitation est à l’origine de nombreuses demandes de support sur les alertes bruyantes, et il vaut la peine de la comprendre avant de concevoir une métrique. Supposons que vous envoyiez un compteur nommé api_request, avec un tag status, afin de pouvoir le ventiler par 200, 404 et 500. Si une seule valeur exacte vous intéresse, comme status=500, utilisez cette valeur exacte dans le trigger. Le problème commence lorsque vous voulez un groupe de valeurs : toutes les réponses 5xx, tout sauf 200, ou toute réponse en échec. Un filtre de tag ne peut exprimer ni exclusions ni plages, et * correspond à toutes les valeurs de ce tag. Un trigger avec un caractère joker large peut ouvrir des alertes pour des statuts en succès en même temps que pour des échecs, et la plupart de ce qui arrive décrit une application qui fonctionne correctement. La solution est de faire de la condition sur laquelle vous voulez alerter sa propre série, au moment où vous l’envoyez. Conservez la métrique taguée lorsqu’elle est utile pour les graphiques, et envoyez-en une seconde, plus restreinte, pour l’alerting :
Configurez ensuite le trigger pour qu’il utilise la métrique plus restreinte :
Shell
L’alerte ne s’ouvre désormais que pour la condition qui doit envoyer une notification. Décidez-le pendant que vous écrivez la métrique personnalisée, car c’est plus simple que de reconcevoir la métrique après que les alertes ont commencé à s’ouvrir.

​
Limiter les valeurs de tags à un petit ensemble fixe

N’utilisez jamais comme valeur de tag une valeur unique par événement. Les identifiants de requête, numéros de commande, identifiants clients et horodatages ressemblent tous à un contexte utile et causent tous les deux mêmes problèmes. Chaque valeur distincte constitue une série séparée. Un trigger sur cette métrique ouvre une alerte par valeur, ce qui peut créer un nombre illimité d’alertes. Les tags à forte cardinalité rendent aussi les graphiques de métriques et l’alerting difficiles à gérer. Une valeur de tag devrait avoir une poignée de variantes que vous pourriez énumérer de mémoire. Par exemple, taguez selon une dimension bornée comme region, et non selon un identifiant unique :
L’identifiant de commande reste important lorsque vous enquêtez : placez-le donc dans une ligne de log, où une forte cardinalité est attendue. Utilisez les tags de métriques pour les dimensions selon lesquelles vous voudriez grouper un graphique. La référence des métriques personnalisées donne plus de détails sur le choix des tags, notamment sur le fait de conserver la même combinaison partout où vous rapportez une métrique.

​
Alerter sur des taux, pas sur des compteurs

Un nombre d’erreurs franchit un seuil fixe dès que le trafic augmente, il vous notifie donc lors de votre journée la plus chargée, que quelque chose aille mal ou non. Le taux d’erreurs reste significatif à 4 h du matin comme au pic. Passer d’un compteur à un taux est souvent la seule modification qui transforme une alerte nocturne en alerte utile. Ne conservez les compteurs que là où chaque occurrence compte et où le volume est naturellement faible, comme les échecs dans un parcours de paiement.

​
Adapter le warm-up à l’ampleur des variations de la métrique

Le warm-up est le temps qu’AppSignal attend avant d’ouvrir une alerte. Pendant cette attente, la métrique doit rester au-dessus ou en dessous du seuil, selon le trigger. Cela filtre les pics d’une minute, comme un deploy lent, une pause de garbage collection ou un hôte en cours de redémarrage. Définissez le warm-up en fonction de l’ampleur des variations de la métrique d’une minute à l’autre, et non de la gravité de la métrique. Commencez par zéro à deux minutes pour la plupart des alertes de production. N’utilisez un warm-up plus long que lorsqu’une métrique connaît souvent des pics et récupère rapidement. La mémoire et le swap évoluent progressivement, ils ne nécessitent donc souvent que peu ou pas de warm-up. S’il vous faut 30 ou 60 minutes pour réduire les notifications, revoyez plutôt le seuil ou la portée.

​
Utiliser le cooldown quand une métrique reste près de son seuil

Le cooldown évite qu’un seul incident produise un flot de notifications d’ouverture et de fermeture pendant qu’une métrique franchit le seuil de façon répétée. La plupart des triggers n’en ont jamais besoin. L’exception concerne les métriques de ressources qui évoluent lentement, et qui peuvent nécessiter un cooldown plus long : un disque proche de 80 % peut franchir cette limite plusieurs fois avant que quelqu’un libère de l’espace, donc sans un cooldown long il peut alerter de nouveau chaque fois que la valeur passe au-dessus et en dessous du seuil. Trente à 60 minutes transforment plusieurs notifications en une alerte qui reste ouverte jusqu’à la résolution.

​
Ne pas augmenter le cooldown d’un uptime monitor

Augmenter le cooldown est le correctif habituel pour un trigger qui s’ouvre et se ferme de façon répétée, mais c’est le mauvais correctif ici. L’échec d’un uptime monitor signifie que l’endpoint n’a pas répondu. Supprimer la seconde notification ne rend pas la première moins exacte. Utilisez plutôt le warm-up. AppSignal vérifie votre endpoint chaque minute depuis quatre régions et suit chaque région séparément, donc une seule panne peut ouvrir jusqu’à quatre alertes, et un problème réseau entre une seule région et votre endpoint en ouvre une alors que votre application est saine. Un warm-up d’au moins une minute filtre ce cas sans masquer une véritable panne.

​
Faire en sorte que chaque notification s’explique d’elle-même

La fatigue liée aux alertes ne dépend pas seulement du nombre de notifications qui arrivent. Elle dépend aussi du travail nécessaire pour comprendre chacune d’entre elles. Trois champs fournissent ce contexte : Nom. Dites ce qui ne va pas, pas quelle métrique a bougé. Un trigger sur une métrique personnalisée s’appelle au départ Custom metric, et une liste de triggers portant tous ce nom ne peut pas être triée. Description. Traitez-la comme le runbook. Court convient, mais le champ accepte plusieurs paragraphes, commandes et liens. Les descriptions les plus utiles incluent les informations que la personne qui répond devrait sinon reconstituer : le chiffre qui compte (« la limite du load balancer est 320 »), les remèdes dans l’ordre, une étape de diagnostic, la durée du correctif, et quelle était la cause la fois précédente. Dashboard. Liez le dashboard qui montre la métrique aux côtés des métriques liées, afin que la notification donne à la personne qui répond un point de départ pour l’investigation.

​
Passer vos triggers en revue régulièrement

La configuration des alertes se périme. Les triggers survivent aux incidents qui les ont motivés, les seuils définis pour le trafic de l’an dernier ne conviennent plus, et les hôtes nommés dans un trigger sont remplacés. Environ chaque trimestre, demandez-vous pour chaque trigger : s’est-il ouvert au cours des 90 derniers jours, quelqu’un a-t-il agi en conséquence, a-t-il ouvert de nombreuses alertes pour un seul incident, et sa destination est-elle toujours la bonne ? Une alerte sur laquelle personne n’agit doit être affinée, réacheminée ou archivée. Passer l’ensemble en revue est plus rapide depuis le terminal qu’en ouvrant chaque trigger :
Shell
Réajuster tient en une seule commande, mais les mises à jour nécessitent la définition complète du trigger. Partez des valeurs actuelles de triggers list, modifiez les champs que vous voulez réajuster, et incluez les valeurs optionnelles que vous souhaitez conserver, comme les identifiants de notifiers, les tags et le lien vers le dashboard :
Shell
Modifier les réglages d’un trigger peut affecter l’état actif de l’alerte : évitez donc de réajuster un trigger pendant que vous utilisez une alerte ouverte pour gérer un incident. Archiver un trigger ferme aussi ses alertes et ses incidents, ce qui est utile pour un trigger sur lequel personne n’agit :
Shell
Le MCP server offre les mêmes accès en lecture et en écriture aux triggers, vous pouvez donc demander à un agent de lister tous les triggers qui ne se sont pas ouverts depuis 90 jours et de proposer ce qu’il faut archiver. Consultez la référence de l’AppSignal CLI pour tous les flags.

​
Comment AppSignal alerte sur AppSignal

Nous faisons tourner AppSignal sur AppSignal, et notre équipe des opérations affine cette configuration depuis des années. Sa forme constitue une cible raisonnable à viser : Cinq motifs de ce tableau sont utiles pour les alertes de production :
  1. Les warm-ups sont courts. La plupart vont de zéro à deux minutes. Le seul long porte sur l’utilisation du disque, et il est associé à une heure de cooldown plutôt qu’utilisé à sa place.
  2. Le cooldown est utilisé une seule fois, délibérément. Seule l’utilisation du disque reste habituellement au-dessus du seuil jusqu’à ce que quelqu’un agisse, donc seule elle en a besoin.
  3. Toutes les alertes ne notifient pas l’astreinte. Le plafond de connexions part vers le chat d’équipe, car il annonce un problème de capacité plutôt qu’il ne décrit une panne.
  4. L’e-mail est ajouté, pas substitué. Le retard de réplication atteint un outil d’astreinte et l’e-mail en même temps, car l’e-mail est le seul canal qui continue de rappeler tant qu’une alerte reste ouverte.
  5. Chaque trigger porte une description. Les plus utiles nomment la limite pertinente, donnent deux remèdes dans l’ordre, et consignent quelle s’est avérée être la cause la fois précédente.
Les triggers les plus difficiles à passer en revue sont ceux laissés sous le nom Custom metric. Nommer est une petite tâche, mais elle a un grand effet sur la revue et le tri.

​
Étapes suivantes