Avec Anomaly detection, vous pouvez configurer des triggers pour envoyer des notifications lorsqu’une valeur de métrique dépasse un seuil ou passe en dessous. Par exemple : lorsque le taux d’erreurs d’une application dépasse 5 % ou que la mémoire libre passe sous 100 MB.
Anomaly detection vérifie les valeurs des métriques une fois par minute. Lorsqu’une métrique atteint une condition de seuil, AppSignal ouvre une alerte et notifie les notifiers sélectionnés. AppSignal les notifie à nouveau lorsque la condition de seuil n’est plus remplie.
Utilisez les réglages warm-up et cooldown pour contrôler l’ouverture et la fermeture d’une nouvelle alerte.
Pour des conseils sur le choix des seuils et sur la maîtrise du volume d’alertes, consultez affiner vos alertes et les modèles d’alertes.
É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.
Vous pouvez configurer des triggers avec une variété de métriques :
- 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
N’utilisez pas Anomaly detection et le warm-up pour vérifier si des jobs horaires, des jobs quotidiens ou des tâches cron s’exécutent.
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.
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 :
Lorsque vous créez un trigger pour cette métrique, sélectionnez également des tags.
Lorsque vous saisissez des tags, AppSignal liste les combinaisons de tags qu’il a vues pour cette métrique et vous avertit lorsque la combinaison saisie n’a pas été vue au cours de la dernière heure. Cet avertissement signifie généralement que le trigger ne correspondra à aucune donnée.
Utilisez l’une des combinaisons de clés de tags qu’AppSignal liste pour la métrique, par exemple 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.
Évitez de réajuster un trigger pendant que vous suivez encore une alerte active à travers lui.
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 atteint 0.
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
Vous pouvez aussi filtrer facilement vos incidents selon leur état.
Pour approfondir l’investigation d’un incident, vous pouvez ouvrir son résumé. Vous y trouverez tous les outils et informations nécessaires pour approfondir l’anomalie qui a déclenché votre alerte. Sur la page de résumé, vous avez accès à :
- 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.
Toutes ces fonctionnalités sont facilement accessibles dans notre interface intuitive :
