> ## 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.
# Alerting dans AppSignal
> Découvrez quelle fonctionnalité d'alerting AppSignal utiliser, quelles alertes les équipes mettent en place en premier, et comment éviter les alertes bruyantes.
Les alertes permettent à votre équipe de repérer les comportements qui nécessitent votre attention avant que les clients aient à vous les signaler. Dans AppSignal, les alertes les plus utiles sont précises, acheminées vers les bonnes personnes, et urgentes uniquement lorsqu'une intervention humaine est nécessaire.
AppSignal propose cinq systèmes d'alerting :
| Système | À utiliser pour | Exemple |
| --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Uptime monitoring](/uptime-monitoring/setup) | Un contrôle externe qui vérifie que vos endpoints publics répondent toujours | Alerter lorsqu'un endpoint de health-check cesse de renvoyer un `2xx` depuis une région |
| [Incident notifications](/application/notification-settings) | Les erreurs et incidents de performance qu'AppSignal détecte déjà dans votre application | Notifier l'équipe la première fois qu'une erreur apparaît après un deploy, ou lorsqu'un incident clos se reproduit |
| [Anomaly detection triggers](/anomaly-detection) | Alertes de seuil sur les métriques intégrées et les [métriques personnalisées](/metrics/custom) | Alerter lorsque le taux d'erreurs reste au-dessus de `5%`, que le temps de réponse `p95` augmente, que le throughput chute, ou que l'utilisation du disque dépasse `85%` |
| [Log triggers](/logging/triggers) | Motifs dans les logs qui devraient déclencher une alerte même s'ils ne deviennent jamais un incident ou une métrique | Alerter lorsqu'un fournisseur de paiement commence à logger des timeouts répétés |
| [Check-in triggers](/check-ins) | Tâches cron, heartbeats et autres processus qui doivent se signaler à l'heure | Alerter lorsqu'un job nocturne ne se termine pas, ou qu'un worker cesse d'envoyer des heartbeats |
Uptime monitoring vérifie vos endpoints depuis les serveurs d'AppSignal dans plusieurs régions via l'internet public ; les quatre autres alertent sur les données que votre application envoie déjà à AppSignal. Beaucoup d'équipes le configurent en premier, car il détecte une panne même lorsque l'application ne peut plus rien envoyer.
## Que sont les alertes
Les alertes transforment la télémétrie en action. Elles vous aident à répondre à des questions telles que :
* L'application est-elle en panne ?
* Les utilisateurs voient-ils plus d'erreurs que d'habitude ?
* Le trafic a-t-il chuté parce que quelque chose en amont a échoué avant que les requêtes n'atteignent l'application ?
* Une file d'attente en background s'accumule-t-elle ?
* Un job planifié a-t-il cessé de s'exécuter ?
Une bonne règle empirique est d'alerter sur les symptômes que ressentent les utilisateurs, et non sur chaque cause interne. C'est l'idée derrière les [« quatre signaux d'or »](https://sre.google/sre-book/monitoring-distributed-systems/) du SRE : latence, trafic, erreurs et saturation. Dans AppSignal, ils correspondent au temps de réponse, au throughput, au taux d'erreurs, aux métriques d'hôte et à la croissance des files d'attente.
## Choisir le bon système d'alerting
Utilisez Incident notifications lorsqu'AppSignal a déjà un incident et que vous voulez contrôler qui est notifié et à quelle fréquence. C'est une valeur par défaut solide pour les exceptions et les actions lentes dont vous savez déjà qu'elles vous importent.
Utilisez Anomaly detection triggers lorsque vous souhaitez des alertes basées sur des seuils appliqués à des métriques. C'est l'option la plus flexible pour une couverture de type SRE, incluant le taux d'erreurs, les percentiles de temps de réponse, le throughput, le temps en file d'attente, les métriques d'hôte et les métriques personnalisées.
Utilisez Log triggers lorsque le signal existe dans les logs mais pas encore sous forme d'incident ou de métrique dédiée. Ils fonctionnent bien pour les défaillances spécifiques à une intégration, comme un timeout chez une banque ou un fournisseur particulier alors que le reste du système semble sain.
Utilisez Check-in triggers lorsque le succès signifie « ce processus s'est signalé à l'heure ». Ce sont les bons outils pour les tâches cron, les heartbeats, les workers et les tâches planifiées.
## Un ensemble de départ pratique
Pour la plupart des applications en production, un ensemble de départ utile ressemble à ceci :
1. Un uptime check pour votre endpoint public de health-check.
2. Un anomaly trigger pour le taux d'erreurs du namespace `web`.
3. Un anomaly trigger pour le temps de réponse `p90` ou `p95` sur le trafic critique visible par les utilisateurs.
4. Un anomaly trigger pour les chutes de throughput.
5. Un anomaly trigger pour le temps en file d'attente, la profondeur de file, ou le backlog des jobs en background.
6. Des triggers de métriques d'hôte pour le CPU, la mémoire et le disque.
7. Des Check-ins pour les tâches cron, les tâches planifiées et les workers de longue durée.
## Alertes populaires pour démarrer
Voici les premières alertes courantes pour les équipes qui souhaitent une couverture large sans trop de bruit :
| Alerte | Pourquoi elle est utile | Fonctionnalité AppSignal |
| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| Taux d'erreurs dans le namespace `web` | Le signal le plus rapide indiquant que les utilisateurs rencontrent des dysfonctionnements | [Anomaly detection trigger](/anomaly-detection) |
| Temps de réponse `p90` ou `p95` pour les actions critiques | Les moyennes masquent une expérience lente pour une partie de votre trafic | [Anomaly detection trigger](/anomaly-detection) |
| Chute de throughput | Une chute brutale signifie souvent qu'un composant en amont a échoué avant que les requêtes n'atteignent votre application | [Anomaly detection trigger](/anomaly-detection) |
| Temps en file d'attente ou croissance du backlog | Avertissement précoce avant que les utilisateurs ne remarquent les délais | [Anomaly detection trigger](/anomaly-detection) |
| Utilisation du CPU, de la mémoire et du disque | Alerte d'infrastructure pour les problèmes de saturation et de capacité | [Anomaly detection trigger](/anomaly-detection) |
| Échec de l'endpoint de health-check | Confirme que l'application est inaccessible depuis l'extérieur de votre infrastructure | [Uptime monitoring](/uptime-monitoring/setup) |
| Heartbeat manquant d'un cron job ou d'un worker | Confirme que le travail en background attendu s'exécute toujours | [Check-in trigger](/check-ins) |
## Ce que les SRE cherchent généralement à couvrir
Si vous construisez une couverture d'alertes à partir de zéro, voici les priorités courantes :
* Erreurs visibles par les utilisateurs
* Requêtes utilisateur lentes, en particulier aux `p90` ou `p95`
* Chutes de trafic et variations inhabituelles de throughput
* Croissance des files d'attente en background et jobs retardés
* Saturation des hôtes comme le CPU, la mémoire et le disque
* Jobs planifiés qui ne démarrent pas, ne se terminent pas, ou ne se signalent pas
* Problèmes de dépendances externes comme des API bancaires lentes, des timeouts, ou des tempêtes de retry
C'est aussi pourquoi les deploy markers sont importants, même s'ils ne constituent pas un type d'alerte en soi. Ils vous aident à répondre à la question de savoir si l'alerte a commencé juste après une release.
## Configurer les alertes avec succès
Un bon alerting est surtout une question de périmètre et de routage :
* Ajoutez d'abord des notifiers sur les pages [Integrations](/application/integrations) et [Notifications](https://appsignal.com/redirect-to/app?to=notifiers). Chaque trigger peut utiliser un notifier différent, ce qui vous permet de router par gravité.
* Envoyez les alertes urgentes de production vers un outil d'astreinte comme [PagerDuty](/application/integrations/pagerduty), [Opsgenie](/application/integrations/opsgenie), ou un autre notifier webhook.
* Envoyez les avertissements et les dégradations vers le chat ou l'e-mail, par exemple [Slack](/application/integrations/slack). Attribuez à staging son propre canal ou coupez-le.
* Définissez des [valeurs par défaut de notification par namespace](/application/notification-settings#organization-and-app-namespace-defaults) afin que `web`, `background` et `admin` puissent notifier des équipes différentes par défaut.
* Commencez par des alertes liées à l'impact utilisateur, puis ajoutez des contrôles opérationnels plus fins une fois que vous voyez ce qui est utile.
## Éviter les alertes bruyantes
C'est la partie qui distingue une alerte utile d'une alerte que l'équipe apprend à ignorer :
* Définissez les seuils à partir d'un historique réel, pas de suppositions. Examinez plusieurs semaines de la tendance de la métrique avant de choisir un seuil.
* Utilisez des [fenêtres de warm-up](/anomaly-detection#warm-up-and-cooldown) afin qu'une condition doive tenir plusieurs minutes avant que l'alerte ne s'ouvre. Trois à cinq minutes est un point de départ courant, et la plupart des fausses alarmes sont des pics d'une seule minute.
* Utilisez au moins un warm-up d'une minute sur les uptime monitors pour absorber les brefs hoquets réseau.
* Ajoutez un [cooldown](/anomaly-detection#warm-up-and-cooldown) pour qu'un signal instable devienne une seule alerte plus longue au lieu de s'ouvrir et de se fermer à répétition.
* Préférez les taux aux valeurs absolues lorsque le trafic varie au cours de la journée. Le taux d'erreurs est généralement plus utile que le nombre brut d'erreurs.
* Préférez `p90` ou `p95` pour les alertes sensibles à la latence plutôt que de vous fier aux moyennes.
* Cadrez les alertes par namespace, action ou tags afin que la notification indique exactement ce qui est affecté.
* Une bonne alerte soutenue vaut mieux que cinq alertes nerveuses. N'envoyez à l'astreinte que les alertes urgentes et visibles par les clients, et le reste au chat.
## Configurer Uptime monitoring
1. Créez un endpoint de health-check dédié si vous n'en avez pas déjà un.
2. Ajoutez un [uptime monitor](/uptime-monitoring/setup) pour cet endpoint.
3. Choisissez un notifier pour les notifications d'indisponibilité.
4. Définissez au moins un warm-up d'une minute pour que de brefs hoquets réseau n'ouvrent pas d'alertes.
5. [Ignorez l'endpoint de health-check](/uptime-monitoring/setup#plans-and-requests) dans votre application AppSignal si vous ne voulez pas que ces requêtes soient comptabilisées dans votre volume mensuel de requêtes.
Utilisez Uptime monitoring pour « l'application est-elle joignable depuis l'extérieur ? ». Utilisez Check-ins pour « ce processus planifié ou en background s'est-il signalé à l'heure ? ».
## Exemples
### Exemple d'Incident notification
Utilisez Incident notifications lorsqu'AppSignal a déjà créé un incident d'erreur ou de performance et que vous avez surtout besoin du bon comportement de notification.
Par exemple :
1. Utilisez **First in Deploy** pour les erreurs de production qui ne doivent alerter qu'une fois par release.
2. Utilisez **First After Close** pour les incidents causés par des systèmes externes qui peuvent se rétablir sans deploy.
3. Utilisez **Every Nth per Hour** ou **Every Nth per Day** pour les erreurs connues bruyantes où le volume compte davantage que chaque occurrence individuelle.
Associer Incident notifications aux [deploy markers](/application/markers/deploy-markers) facilite grandement la réponse à la question : « Est-ce que cela a commencé après notre dernier deploy ? »
### Exemple de Log trigger
Utilisez Log triggers lorsque les logs contiennent le signal dont vous avez besoin. Par exemple, un flux de paiement ou d'inscription peut effectuer des retry lorsqu'une API bancaire est lente, donc un seul échec ne mérite peut-être pas une alerte urgente, mais un motif soutenu si.
```sql SQL theme={null}
severity=error provider=bank-a message:timeout
```
Un tel trigger peut notifier l'équipe lorsqu'un fournisseur commence à générer des timeouts. Si les retry sont fréquents, utilisez **First After Close** ou **Nth in an hour** plutôt que d'alerter sur chaque ligne de log correspondante.
### Exemple d'alerte sur une métrique personnalisée
Si vous envoyez des métriques personnalisées, vous pouvez alerter dessus avec [anomaly detection](/anomaly-detection).
Par exemple, vous pouvez envoyer :
* Un counter pour les paiements ou inscriptions réussis
* Une gauge pour la profondeur de file d'attente ou le nombre de workers actifs
* Une measurement pour le temps de réponse d'un fournisseur
Une fois la métrique visible dans AppSignal :
1. Graphez-la d'abord et examinez son historique récent.
2. Choisissez le champ qui correspond à la question que vous posez : `gauge`, `counter`, `count`, `mean`, `p90` ou `p95`.
3. Filtrez par tags comme `provider=bank-a` ou `region=eu` lorsque vous avez besoin d'une alerte plus étroite.
4. Ajoutez le bon notifier en fonction de la gravité du problème.
5. Ajoutez un warm-up et un cooldown avant de dépendre de l'alerte en production.
## Étapes suivantes
* Consultez les [notification settings](/application/notification-settings) pour l'alerting basé sur les incidents.
* Créez des [anomaly detection triggers](/anomaly-detection) pour les métriques et les seuils.
* Configurez [Uptime monitoring](/uptime-monitoring/setup) pour un health check externe.
* Créez des [process monitors et check-ins](/check-ins/create) pour les tâches cron et les heartbeats.
* Utilisez les [log triggers](/logging/triggers) pour l'alerting basé sur les logs.