> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Réduire le bruit des alertes
> Recommandations de production pour ramener une configuration d'alerting aux notifications sur lesquelles votre équipe peut agir, classées selon la quantité de bruit que chaque étape supprime.
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](/alerting/tuning).
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](#use-exact-tag-filters-or-send-a-dedicated-alert-metric) et [limiter les valeurs de tags à un petit ensemble fixe](#keep-tag-values-to-a-small-fixed-set). 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](/application/integrations/pagerduty) ou [Opsgenie](/application/integrations/opsgenie).
* **Cela empire, mais rien n'est encore perdu.** Chat d'équipe, comme [Slack](/application/integrations/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](/application/namespaces), 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 :
```ruby Ruby theme={null}
status_code = response.code.to_s
# Useful for charts broken down by status.
Appsignal.increment_counter("api_request", 1, :status => status_code)
# Useful for alerting because it only increments for 5xx responses.
Appsignal.increment_counter("api_request_failed", 1) if status_code.to_i >= 500
```
```elixir Elixir theme={null}
status = response.status
# Useful for charts broken down by status.
Appsignal.increment_counter("api_request", 1, %{status: status})
if status >= 500 do
# Useful for alerting because it only increments for 5xx responses.
Appsignal.increment_counter("api_request_failed", 1)
end
```
Configurez ensuite le trigger pour qu'il utilise la métrique plus restreinte :
```sh Shell theme={null}
appsignal-cli triggers create --app "MyApp" --environment production \
--name "Server errors from the payment API" \
--metric-name api_request_failed --kind Advanced --field counter \
--comparison-operator ">" --condition-value 10 \
--warmup-duration 3 --cooldown-duration 5 \
--notifier-ids
```
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](/metrics/custom), 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 :
```ruby Ruby theme={null}
# A tag with a small set of values is safe to graph and alert on.
Appsignal.increment_counter("order_processed", 1, :region => order.region)
```
```elixir Elixir theme={null}
# A tag with a small set of values is safe to graph and alert on.
Appsignal.increment_counter("order_processed", 1, %{region: order.region})
```
L'identifiant de commande reste important lorsque vous enquêtez : placez-le donc dans une [ligne de log](/logging), 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](/metrics/custom#metric-tags) 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](/uptime-monitoring/setup) 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 :
```sh Shell theme={null}
# Every trigger, as JSON you can diff, grep, or hand to an agent
appsignal-cli --output json triggers list --app "MyApp" --environment production
# Narrow to one metric or one kind when you are hunting duplicates
appsignal-cli triggers list --app "MyApp" --environment production --metric-name response_time
```
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 :
```sh Shell theme={null}
appsignal-cli triggers update --id --app "MyApp" --environment production \
--name "Slow web requests" \
--metric-name response_time --kind Advanced --field p95 \
--comparison-operator ">" --condition-value 750 \
--warmup-duration 5 --cooldown-duration 5 \
--notifier-ids
```
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 :
```sh Shell theme={null}
appsignal-cli triggers archive --id --app "MyApp" --environment production
```
Le [MCP server](/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](/cli/triggers) 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 :
| Ce que nous surveillons | Condition | Warm-up | Cooldown | Destination |
| -------------------------------------------------- | ------------------------ | ---------- | ---------- | ------------------------ |
| Utilisation du disque sur `/` | Au-dessus de 80 % | 10 minutes | 60 minutes | Astreinte |
| Mémoire libre | En dessous de 100 MB | 0 | 0 | Astreinte |
| Swap utilisé | Au-dessus de 50 % | 0 | 0 | Astreinte |
| Éléments en attente dans une file, tagués par file | Plus de 10 000 | 2 minutes | 0 | Astreinte |
| Retard de traitement, au `p95` | Au-dessus de 2 000 ms | 0 | 0 | Astreinte |
| Connexions vers une classe d'hôtes | Plus de 800 | 2 minutes | 0 | Chat d'équipe uniquement |
| Throughput dans un namespace background | 30 000 req/min ou plus | 2 minutes | 0 | Astreinte |
| Retard de réplication | Au-dessus de 60 secondes | 2 minutes | 0 | E-mail et astreinte |
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
* Parcourez les réglages en détail avec [affiner vos alertes](/alerting/tuning).
* Vérifiez que rien d'important n'est laissé sans surveillance avec [alerting en production](/alerting/production).
* Trouvez une configuration de départ pour une alerte précise dans les [modèles d'alertes](/alerting/recipes).
* Façonnez une métrique pour l'alerting au moment où vous l'envoyez, avec les [métriques personnalisées](/metrics/custom).