Affiner vos alertes

Une alerte n’est utile que si quelqu’un agit en conséquence. Lorsqu’une équipe reçoit plus de notifications qu’elle ne peut traiter, elle commence à toutes les ignorer, y compris celle qui comptait. C’est la fatigue liée aux alertes, et il s’agit généralement d’un problème de configuration plutôt que de monitoring. Cette page explique comment affiner une alerte qui existe déjà. Si vous en êtes encore à décider sur quoi alerter, commencez par les modèles d’alertes. Si votre problème concerne l’ensemble plutôt qu’un seul trigger, réduire le bruit des alertes traite d’abord les changements qui suppriment le plus de notifications.

​

Signes que votre alerting a besoin d’être affiné

• Un canal reçoit des alertes que personne n’examine.
• La même alerte s’ouvre et se ferme plusieurs fois par heure.
• Un seul incident produit de nombreuses notifications depuis de nombreux hôtes ou combinaisons de tags.
• L’astreinte reçoit des alertes sur lesquelles on ne peut agir qu’aux heures de bureau.
• Quelqu’un a désactivé les notifications du canal d’alertes.

Chacun de ces cas correspond à un réglage précis décrit dans les sections suivantes.

​

Seuil, warm-up et cooldown

Chaque Anomaly detection trigger possède trois réglages qui déterminent quand les alertes s’ouvrent et se ferment. Affiner signifie presque toujours ajuster l’un d’entre eux.

​

Définir les seuils à partir de l’historique de la métrique

Avant de choisir un seuil, tracez la métrique sur au moins deux semaines et observez sa plage normale, y compris ses pics quotidiens et hebdomadaires. Un seuil placé sous un pic habituel du lundi matin vous notifiera chaque lundi matin. Un bon point de départ est la valeur que la métrique atteint pendant une période chargée mais saine, plus une marge suffisante pour que les variations normales ne la franchissent pas. Si vous ne pouvez pas décrire ce que vous feriez au franchissement du seuil, ce n’est probablement pas le bon seuil.

​

Utiliser le warm-up pour filtrer les pics

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. Avec un warm-up de 0, AppSignal peut ouvrir une alerte dès que la métrique franchit le seuil. Utilisez le warm-up pour éviter les alertes liées à de courts pics de métrique, comme un deploy lent, une pause de garbage collection ou un hôte en cours de redémarrage. Commencez par zéro à deux minutes pour la plupart des alertes de production. N’utilisez un warm-up plus long que lorsque la métrique connaît souvent des pics et récupère rapidement. Définissez le warm-up en fonction de l’ampleur des variations de la métrique d’une minute à l’autre. Une métrique qui change rapidement a souvent besoin d’un warm-up. Une métrique qui change progressivement n’en a souvent besoin que peu, voire pas du tout. Les warm-ups utiles sont généralement courts. Au-delà d’environ 10 minutes, vous retardez surtout la notification plutôt que vous ne l’améliorez. 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 les alertes s’ouvrent et se ferment de façon répétée

Le cooldown est le nombre de minutes pendant lesquelles la métrique doit rester revenue à la normale avant que l’alerte se ferme et qu’une nouvelle puisse s’ouvrir. Pour les triggers « supérieur à », cela signifie que la métrique reste sous le seuil. Pour les triggers « inférieur à », cela signifie qu’elle reste au-dessus du seuil. Sans cooldown, une métrique qui franchit son seuil de façon répétée produit un flot de notifications d’ouverture et de fermeture pour un seul incident. Un cooldown court transforme ce flot en une seule alerte. Réglez-le légèrement plus long que la période pendant laquelle la métrique passe habituellement au-dessus et en dessous du seuil. Le cooldown est un correctif ciblé plutôt qu’un réglage par défaut. La plupart des triggers n’en ont jamais besoin, car la plupart des métriques ne se situent pas exactement sur leur seuil. Laissez-le à 0 jusqu’à ce que vous voyiez un trigger s’ouvrir et se fermer de façon répétée pour ce qui était clairement un seul incident, puis réglez-le d’après la durée réelle de ces intervalles.

​

Portée : un trigger peut ouvrir de nombreuses alertes

C’est la cause la plus fréquente d’un grand nombre de notifications issues d’un seul incident. Un trigger n’ouvre pas une alerte. Il ouvre une alerte par série correspondante. Pour les triggers d’hôte, cela signifie une alerte par hôte. Le champ hostname accepte un caractère joker, et sa valeur par défaut * correspond à tous les hôtes qui rapportent à l’application. Un parc de 30 hôtes franchissant un seuil de CPU au même moment produit 30 alertes. Restreignez la portée afin que la notification indique exactement ce qui est affecté :

• Indiquez un hostname précis, ou un préfixe comme web-*, au lieu de laisser la valeur par défaut *.
• Ajoutez des tags afin que le trigger ne surveille que les séries qui vous intéressent, comme mountpoint=/ pour l’utilisation du disque ou region=eu pour une métrique personnalisée.
• Restreignez les triggers de taux d’erreurs et de temps de réponse à un seul namespace, afin que web, background et admin puissent avoir des seuils et des notifiers différents.

Lorsque vous ajoutez des tags, AppSignal vous avertit si la combinaison de tags n’a pas été vue au cours de la dernière heure. Cet avertissement signifie généralement que le trigger ne correspondra jamais à aucune donnée. Utilisez l’une des combinaisons de clés de tags listées dans le formulaire du trigger, et donnez à chaque valeur une valeur exacte ou un caractère joker. Les uptime monitors se comportent de la même manière. Chacune des quatre régions est suivie séparément, donc un seul monitor peut ouvrir quatre alertes pour une seule panne, et une alerte lorsqu’une seule région ne parvient pas à joindre un endpoint par ailleurs sain.

​

Choisir une métrique qui reflète l’impact utilisateur

Modifier les réglages d’un trigger ne peut pas corriger un trigger qui surveille la mauvaise métrique. Préférez les taux aux compteurs. Le nombre d’erreurs franchit un seuil fixe dès que le trafic augmente, il vous notifie donc lors de vos journées les plus chargées, que quelque chose aille mal ou non. Le taux d’erreurs reste stable quand le trafic change. N’utilisez les compteurs que pour les métriques où chaque occurrence compte, comme les erreurs dans un parcours de paiement. Préférez les percentiles aux moyennes. Un temps de réponse moyen masque une expérience lente pour une partie de votre trafic. Si 5 % des requêtes prennent 8 secondes, la moyenne bouge à peine. Alertez plutôt sur p90 ou p95. Préférez les symptômes visibles par les utilisateurs aux causes. Alertez sur les erreurs, la latence, le trafic ou les actions métier en échec, et utilisez les dashboards pour trouver la cause. Une utilisation CPU élevée n’est pas en soi un problème si les temps de réponse sont corrects. Cela maintient le nombre d’alertes proportionnel au nombre d’incidents réels. Réglez délibérément les données manquantes sur zéro. Un trigger suppose qu’un point de donnée arrive chaque minute. Pour les métriques qui ne rapportent que lorsqu’il se passe quelque chose, comme un compteur, activez treat missing datapoints as 0 afin que l’alerte se ferme lorsque l’activité cesse. Laissez l’option désactivée lorsqu’une absence de données signifie « aucune information » plutôt que « zéro ».

​

Acheminer par gravité, pas par habitude

Envoyer tout vers un seul canal provoque la fatigue liée aux alertes. Chaque trigger peut utiliser son propre notifier : servez-vous en pour séparer les alertes urgentes de celles qui peuvent attendre. Donnez à la staging son propre canal, ou laissez ses triggers sans notifier. Des alertes de staging qui arrivent dans un canal de production sont l’un des moyens les plus rapides d’apprendre à une équipe à ignorer ce canal. La gravité n’est pas le seul découpage utile. Dès que vous avez plus d’une poignée de triggers, des canaux de chat séparés par domaine, par exemple un pour les erreurs applicatives et un pour l’infrastructure, gardent chaque canal suffisamment restreint pour que les personnes qui le suivent reconnaissent ce qui sort de l’ordinaire. Un canal unique qui reçoit tout rend les notifications importantes plus faciles à manquer.

​

Acheminer différemment les incidents et les triggers

L’acheminement comporte deux niveaux, et ils se comportent différemment. Pour les Anomaly detection triggers, choisissez les notifiers sur le trigger lui-même. Retirer tous les notifiers laisse le trigger actif et il continue d’enregistrer des alertes, mais il n’envoie aucune notification. Pour les incidents d’erreur et de performance, définissez les valeurs de notification par défaut par namespace plutôt que de configurer chaque incident. Un namespace admin réglé sur Never Notify supprime d’un coup toute une catégorie de notifications à faible valeur. Les valeurs par défaut par namespace sont aussi l’endroit où vous acheminez les incidents web, background et admin vers des destinations différentes. Les notifiers sont configurés une fois pour l’organisation et peuvent être partagés entre applications : un notifier utilisé par de nombreuses applications demande donc de la prudence. Vérifiez où un notifier est utilisé avant de le modifier.

​

Faire en sorte que la 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. Une alerte qui indique qu’un chiffre a franchi un seuil oblige la personne qui répond à chercher ce que ce seuil signifie. Une alerte qui s’explique d’elle-même permet d’agir immédiatement, ou d’être ignorée à bon escient. Trois champs fournissent ce contexte, et il vaut la peine de remplir les trois sur chaque trigger. Nom. Dites ce qui ne va pas, pas quelle métrique a bougé. Une liste de triggers où de nombreuses entrées s’appellent Custom metric ne peut être ni passée en revue ni triée. Description. Traitez-la comme un runbook d’une ligne. Indiquez ce que la condition signifie et ce que la personne qui répond doit faire. Ce sont les deux questions auxquelles elle doit répondre, et la description est le meilleur endroit pour y répondre :

• « Cet hôte fait du swap, donc chaque requête qu’il sert est plus lente. Vérifiez ce qui consomme la mémoire et prévenez le canal des opérations. »
• « Moins de 100 MB de mémoire libre. Vérifiez ce qui la consomme et ajoutez de la capacité avant que le kernel ne commence à tuer des processus. »
• « Ce service a une fuite mémoire connue. La mémoire croît jusqu’à ce que le kernel tue le processus : redémarrez-le et n’escaladez que s’il revient dans l’heure. »

Le troisième exemple mérite l’attention. Documenter une cause connue sur le trigger évite que la même investigation soit refaite par la personne d’astreinte du moment, et indique à celle qui répond quand ne pas agir. Dashboard. Chaque trigger peut être lié à un dashboard, et le lien est inclus dans la notification. Renvoyez vers le dashboard qui montre la métrique en contexte, aux côtés des métriques liées. Cela donne à la personne qui répond un point de départ pour l’investigation.

​

Ce que vous ne pouvez pas régler, et ce qui ne devrait pas alerter

Deux choses concernant les alertes de trigger ne peuvent pas être réglées, et une catégorie de métriques ne devrait pas alerter du tout. Les options de fréquence s’appliquent aux incidents et aux Log triggers, pas aux alertes des Anomaly detection triggers. Les notifications d’erreur et de performance utilisent les options de notification d’incident, telles que Every Occurrence, First in Deploy, First After Close et Never Notify, définies par namespace dans les valeurs de notification par défaut. Les Log triggers disposent d’options de seuil similaires. Les alertes des Anomaly detection triggers suivent en revanche la machine à états des alertes. Seul l’e-mail se répète tant qu’une alerte d’anomalie reste ouverte. Les notifiers e-mail ont un Reminder interval de 15 minutes, 30 minutes ou 1 heure. Slack, PagerDuty, Opsgenie et les webhooks n’ont pas d’équivalent. Ce qu’il faut faire à la place. Pour qu’un trigger ne notifie plus personne, retirez ses notifiers, ou archivez-le. Si une alerte ouverte doit continuer à envoyer des rappels jusqu’à ce que quelqu’un agisse, associez l’e-mail à un outil d’astreinte doté de sa propre politique d’escalade. Si une alerte de longue durée remplit un canal de chat, la cause est l’ouverture et la fermeture répétées plutôt que les rappels : le correctif est donc un cooldown plus long. Pour les autres cas, décidez si la condition doit envoyer une notification du tout.

• Alertez sur un taux d’erreurs au-dessus de 5 % dans web pendant trois minutes, pas sur chaque exception individuelle, même rare.
• Alertez sur un temps de réponse p95 du checkout qui double, pas sur une moyenne passée de 180 ms à 200 ms.
• Alertez sur un throughput à zéro alors qu’il est normalement de 400 req/min, pas sur un trafic qui diminue de moitié la nuit, comme chaque nuit.
• Alertez sur un disque à 85 % qui gagne un point par heure, pas sur un CPU qui atteint 100 % pendant une minute lors d’un deploy.
• Alertez sur un job de facturation nocturne qui ne s’est jamais signalé, pas sur le même job qui démarre deux minutes en retard.
• Alertez sur un fournisseur de paiement en timeout 50 fois en une heure, pas sur une requête en timeout qui a réussi au retry.

Si une métrique est intéressante mais ne permet pas d’agir, placez-la sur un dashboard au lieu d’envoyer des notifications à son sujet.

​

Passer les 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. Passez vos triggers en revue environ chaque trimestre et demandez-vous, pour chacun :

1. A-t-il ouvert une alerte au cours des 90 derniers jours ? Si non, ouvrez-le et vérifiez l’aperçu du graphique. Aucune donnée, ou un avertissement du champ hostname indiquant que l’hôte n’a pas été trouvé, signifie qu’il surveille quelque chose qui n’existe plus. Des hôtes renommés ou remplacés en sont la cause habituelle, et le trigger ne vous notifie pas lorsqu’il ne correspond à rien.
2. Quelqu’un a-t-il agi en conséquence ? Une alerte sur laquelle personne n’agit doit être affinée, réacheminée ou archivée.
3. A-t-il ouvert de nombreuses alertes pour un seul incident ? Restreignez sa portée.
4. Son notifier est-il toujours le bon ? Envoyer des problèmes non urgents à l’astreinte est une source majeure de fatigue liée aux alertes.
5. S’explique-t-il de lui-même ? Un trigger sans nom ni description ne peut pas être trié, car personne ne peut dire ce qu’il fait sans le reconstituer.
6. Est-il en doublon ? Deux triggers avec la même métrique, le même seuil et le même notifier envoient deux notifications pour un seul problème.
7. Quelqu’un en est-il encore responsable ? Les triggers créés par des personnes ayant quitté l’entreprise sont les plus susceptibles d’être périmés et les moins susceptibles d’être revus.

Vous pouvez lister tous les triggers configurés avec l’AppSignal CLI ou via le MCP server pour les passer en revue sans ouvrir chacun d’eux dans l’interface.

​

Récapitulatif : affiner un trigger qui envoie trop de notifications

Cette section n’introduit rien de nouveau. Elle met les sections précédentes dans l’ordre à partir d’un exemple : un trigger sur l’utilisation CPU d’un hôte au-dessus de 80 %, sans warm-up, sans cooldown, et avec le hostname par défaut *, qui envoie plusieurs notifications d’astreinte par nuit alors qu’aucun problème n’est visible par les utilisateurs.

1. Vérifiez la métrique. L’utilisation CPU est une cause, pas un symptôme visible par les utilisateurs, et le temps de réponse comme le taux d’erreurs sont sains pendant les pics de CPU.
2. Restreignez la portée. Les pics viennent des workers en background, le hostname devient donc web-*.
3. Définissez le seuil d’après l’historique. Deux semaines de données montrent que les hôtes web atteignent régulièrement 85 % au pic du soir, le seuil passe donc à 95 %.
4. Ajoutez un warm-up. Deux minutes, car un bref pic de CPU est normal et ne devrait pas notifier l’astreinte.
5. Ajoutez un cooldown. Réglez un cooldown court, afin qu’un hôte proche du seuil produise une alerte plutôt que six.
6. Réacheminez-le. Une saturation CPU durable est un problème de capacité, pas une panne : elle part donc vers le chat d’équipe et le notifier d’astreinte est retiré.
7. Ajoutez l’alerte qui manquait. L’équipe avait besoin d’une alerte sur l’impact utilisateur, elle ajoute donc un trigger de temps de réponse p95 sur le namespace web, acheminé vers l’astreinte. Alerting en production explique comment trouver le reste.

Le résultat est un nombre réduit de notifications, et celles qui restent décrivent quelque chose sur quoi une personne peut agir.

​

Étapes suivantes

• Choisissez ce qu’il faut surveiller avec les modèles d’alertes.
• Vérifiez l’ordre de mise en place et la couverture avec alerting en production.
• Revoyez en détail le fonctionnement du warm-up et du cooldown.
• Configurez les réglages de notification pour les incidents d’erreur et de performance.
• Mettez en place des check-ins pour le travail planifié plutôt que d’utiliser de longs warm-ups.