États des alertes
Les alertes peuvent avoir cinq états :
Quand serai-je notifié ?
AppSignal vous notifie sur deux transitions d’état : lorsqu’une alerte s’ouvre, et lorsqu’elle est résolue. L’e-mail peut aussi envoyer des rappels tant qu’une alerte reste ouverte. Tous les autres canaux, dont Slack, PagerDuty, Opsgenie et les webhooks, ne sont notifiés que sur les transitions d’ouverture et de résolution. Les alertes sont envoyées aux notifiers sélectionnés sur le trigger, et non à tous les notifiers configurés sur l’application.Mettre un trigger en silence
Contrairement aux incidents d’erreur, les alertes n’ont pas d’options de fréquence de notification. Il n’existe pas de réglage Never Notify ni Every Nth per Hour, car les notifications suivent la machine à états des alertes plutôt qu’un décompte d’occurrences. Pour qu’un trigger ne notifie plus personne, retirez ses notifiers. Pour qu’il ne produise plus aucune alerte, archivez-le. L’acheminement des alertes de trigger est contrôlé sur le trigger lui-même. Sélectionnez les notifiers qui doivent recevoir les alertes de ce trigger, ou retirez tous les notifiers pour garder le trigger actif sans envoyer de notifications.Alertes par e-mail
Les e-mails d’alerte incluent un aperçu des nouvelles alertes, des rappels, et le statut des autres alertes qui ne sont pas encore terminées.Création et configuration des triggers
Configurez Anomaly detection par application depuis la section « Anomaly detection » de la navigation de l’application. L’aperçu des alertes affiche les dernières alertes créées par les triggers configurés pour l’application. Ouvrez la page Triggers pour créer et modifier des triggers. Sélectionnez Add trigger pour ouvrir le sélecteur de métriques, puis choisissez un type de trigger parmi Tracing, Host metrics ou Other. Les triggers de métriques personnalisées sont listés sous Other, en tant que Custom metrics.
- Taux d’erreurs
- Nombres d’erreurs (absolus)
- Throughput de l’application
- Performance des actions (actions lentes)
- Temps en file d’attente
- Métriques d’hôte
- Charge CPU
- I/O disque
- Utilisation du disque
- Load averages
- Utilisation de la mémoire
- Utilisation du réseau
Warm-up et cooldown
Vous pouvez configurer les réglages de warm-up et de cooldown pour chaque trigger. Ces réglages définissent combien de temps AppSignal attend avant d’ouvrir et de fermer une alerte.Warm-up
En général, lorsque la condition de seuil d’un trigger est atteinte, il ouvre une alerte. Par exemple, le taux d’erreurs est supérieur à 5 %. Lorsqu’un trigger a une période de warm-up, AppSignal n’ouvre l’alerte qu’après que la condition de seuil est restée vraie pendant toute la période de warm-up. Par exemple, le taux d’erreurs doit rester supérieur à 5 % pendant plus de 3 minutes. AppSignal vous notifie lorsque le statut de l’alerte passe de warm-up à ouvert.Cooldown
Les alertes ouvertes par un trigger sont automatiquement fermées lorsque la condition de seuil n’est plus remplie. Pour éviter des notifications répétées d’ouverture et de fermeture pour le même problème, configurez une période de cooldown. Si vous configurez une période de cooldown, AppSignal ne créera pas de nouvelle alerte à moins que la condition du trigger soit remplie de nouveau après l’expiration de la période de cooldown. Par exemple :- Une alerte s’ouvre parce que le taux d’erreurs est supérieur à 5 %.
- Le taux d’erreurs baisse, donc l’alerte se ferme.
- Le trigger a une période de cooldown de deux minutes.
- Le taux d’erreurs repasse au-dessus de 5 %.
- AppSignal ne crée pas de nouvelle alerte à moins que le taux d’erreurs dépasse 5 % après la fin de la période de cooldown.
Tags
Certaines métriques nécessitent aussi de sélectionner des tags. Par exemple, si vous envoyez à AppSignal une métrique personnalisée qui porte des tags :
namespace ou namespace, queue. Les valeurs de tags peuvent être des valeurs exactes comme namespace=web ou des caractères joker comme queue=*.
Un trigger peut ouvrir plusieurs alertes
Un trigger ouvre une alerte par série correspondante, et non une alerte au total. Un trigger qui correspond à 30 hôtes ouvre 30 alertes lorsque les 30 franchissent le seuil. Les triggers de métriques d’hôte rendent cela facile à négliger, car le champ hostname accepte les caractères joker et sa valeur par défaut* correspond à tous les hôtes qui rapportent à l’application. Saisissez un hostname précis, ou un préfixe comme web-*, pour limiter les hôtes couverts par un trigger.
Il en va de même pour les tags sur toute autre métrique. Plus le filtre de tags est restreint, plus l’alerte est précise, et moins un seul incident produit de notifications.
Modification et archivage des triggers
Modifier ou archiver un trigger peut affecter les alertes et incidents qui y sont rattachés. Modifier ou archiver un trigger peut avoir ces effets :- Les alertes encore dans leur phase de warm-up sont abandonnées.
- Les alertes ouvertes sont fermées et marquées comme archivées.
- Lorsque vous modifiez un trigger, les incidents d’anomalie ouverts du trigger précédent sont liés au nouveau trigger, afin que l’historique de l’incident et le journal restent disponibles après la modification.
- Lorsque vous archivez un trigger sans le remplacer, les incidents d’anomalie ouverts de ce trigger sont fermés.
Points de données manquants comme 0
Par défaut, les triggers supposent qu’un point de donnée est envoyé chaque minute. Cela peut ne pas être réalisable dans des situations telles que l’incrémentation d’un compteur uniquement lorsqu’une action précise se produit. Dans ces cas, activez Treat missing datapoints as 0. AppSignal traite alors un point de donnée manquant comme zéro, ce qui aide une alerte à se fermer lorsqu’aucune donnée n’arrive à la minute suivante. Cela rend aussi possibles les alertes d’absence, comme alerter lorsqu’une métrique atteint0.
Traitement des données
Les métriques utilisées par les triggers pour créer des alertes ne sont pas traitées instantanément lorsqu’elles sont envoyées de votre application à AppSignal. Vos données de métriques traversent plusieurs systèmes avant d’arriver à notre processeur. Les données peuvent aussi être envoyées depuis plusieurs serveurs qui envoient les données à des intervalles différents. Le processeur attend ensuite* que toutes les données d’une minute soient arrivées avant de les traiter et de créer ou mettre à jour les alertes. Si vous rencontrez des problèmes avec les métriques qu’AppSignal rapporte pour Anomaly detection, assurez-vous que les serveurs de votre application rapportent simultanément en les configurant avec NTP. Des heures rapportées incorrectes ou différentes par plusieurs serveurs applicatifs peuvent empêcher les alertes de s’ouvrir ou de se fermer. Vous pouvez en savoir plus sur la façon dont AppSignal traite les données pour Anomaly detection et sur ce que cela implique pour les alertes dans notre documentation sur le cycle de vie des données. *: Pour plus d’informations sur les temps d’attente, consultez notre page sur le cycle de vie des données.Gestion des incidents
Vous pouvez consulter tous les incidents d’alerte sur la page Anomaly Issues de l’application AppSignal. La page Issues affiche un aperçu de tous les incidents d’alerte ouverts, classés par dernière occurrence, avec des colonnes pour l’anomalie :- Nom
- Statut
- Personnes assignées
- État
- Heure du dernier changement d’état
- Informations sur l’alerte : le nom de la métrique, l’état de l’alerte et ses tags.
- Graphique de fréquence des occurrences : une représentation visuelle des occurrences de l’alerte.
- Réglages de l’incident : la possibilité de fermer l’alerte, de définir sa gravité et de l’assigner à un membre de l’équipe.
- Informations sur le trigger : les conditions nécessaires pour déclencher l’alerte.
- Dernières occurrences : un tableau des occurrences les plus récentes, avec leur heure de début et de fin, leur état et leur valeur maximale.
- Journal : un journal pour consigner les informations importantes sur cette alerte, pour votre équipe ou pour vous-même plus tard.
- Accès à Time Detective : utilisez Time Detective pour voir l’état de votre application lors de la dernière occurrence de l’alerte.
