| Système | À utiliser pour | Exemple |
|---|---|---|
| Uptime monitoring | 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 | 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 | Alertes de seuil sur les métriques intégrées et les métriques personnalisées | 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 | 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 | 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 |
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 ?
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 :- Un uptime check pour votre endpoint public de health-check.
- Un anomaly trigger pour le taux d’erreurs du namespace
web. - Un anomaly trigger pour le temps de réponse
p90oup95sur le trafic critique visible par les utilisateurs. - Un anomaly trigger pour les chutes de throughput.
- Un anomaly trigger pour le temps en file d’attente, la profondeur de file, ou le backlog des jobs en background.
- Des triggers de métriques d’hôte pour le CPU, la mémoire et le disque.
- 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 |
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 |
| 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 |
| Temps en file d’attente ou croissance du backlog | Avertissement précoce avant que les utilisateurs ne remarquent les délais | Anomaly detection trigger |
| 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 |
| Échec de l’endpoint de health-check | Confirme que l’application est inaccessible depuis l’extérieur de votre infrastructure | Uptime monitoring |
| Heartbeat manquant d’un cron job ou d’un worker | Confirme que le travail en background attendu s’exécute toujours | Check-in trigger |
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
p90oup95 - 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
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 et Notifications. 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, Opsgenie, ou un autre notifier webhook.
- Envoyez les avertissements et les dégradations vers le chat ou l’e-mail, par exemple Slack. Attribuez à staging son propre canal ou coupez-le.
- Définissez des valeurs par défaut de notification par namespace afin que
web,backgroundetadminpuissent 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 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 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
p90oup95pour 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
- Créez un endpoint de health-check dédié si vous n’en avez pas déjà un.
- Ajoutez un uptime monitor pour cet endpoint.
- Choisissez un notifier pour les notifications d’indisponibilité.
- Définissez au moins un warm-up d’une minute pour que de brefs hoquets réseau n’ouvrent pas d’alertes.
- Ignorez l’endpoint de health-check dans votre application AppSignal si vous ne voulez pas que ces requêtes soient comptabilisées dans votre volume mensuel de requêtes.
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 :- Utilisez First in Deploy pour les erreurs de production qui ne doivent alerter qu’une fois par release.
- Utilisez First After Close pour les incidents causés par des systèmes externes qui peuvent se rétablir sans deploy.
- Utilisez Every Nth per Hour ou Every Nth per Day pour les erreurs connues bruyantes où le volume compte davantage que chaque occurrence individuelle.
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
Exemple d’alerte sur une métrique personnalisée
Si vous envoyez des métriques personnalisées, vous pouvez alerter dessus avec 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
- Graphez-la d’abord et examinez son historique récent.
- Choisissez le champ qui correspond à la question que vous posez :
gauge,counter,count,mean,p90oup95. - Filtrez par tags comme
provider=bank-aouregion=eulorsque vous avez besoin d’une alerte plus étroite. - Ajoutez le bon notifier en fonction de la gravité du problème.
- Ajoutez un warm-up et un cooldown avant de dépendre de l’alerte en production.
Étapes suivantes
- Consultez les notification settings pour l’alerting basé sur les incidents.
- Créez des anomaly detection triggers pour les métriques et les seuils.
- Configurez Uptime monitoring pour un health check externe.
- Créez des process monitors et check-ins pour les tâches cron et les heartbeats.
- Utilisez les log triggers pour l’alerting basé sur les logs.