Skip to main content
Cette page donne une configuration de départ pour chaque alerte dont la plupart des applications en production ont besoin. Chaque modèle indique ce que le trigger mesure, quand il vaut la peine de le mettre en place, et des valeurs pour commencer. Traitez ces valeurs comme des points de départ. Tracez la métrique sur au moins deux semaines avant de fixer un seuil, puis ajustez-le à l’aide des recommandations d’affiner vos alertes. Quel que soit le modèle par lequel vous commencez, donnez au trigger un nom qui dit ce qui ne va pas, une description qui dit quoi faire, et un dashboard lié. Ces trois champs sont ce qui transforme la notification obtenue en quelque chose sur quoi la personne qui répond peut agir, et ils sont traités dans faire en sorte que la notification s’explique d’elle-même.

​
Les quatre alertes à mettre en place en premier

Si vous mettez en place l’alerting de zéro, ces quatre-là couvrent la plupart des incidents réels :
  1. Un uptime monitor sur un endpoint de health-check.
  2. Un trigger de taux d’erreurs sur votre namespace web.
  3. Un trigger de temps de réponse p95 sur le trafic visible par les utilisateurs.
  4. Des check-ins pour les jobs planifiés.
Ajoutez les alertes d’hôte et de saturation une fois que celles-ci sont stables. Ajouter tous les modèles de cette page d’un coup est un moyen fiable de créer de la fatigue liée aux alertes.

​
L’application est-elle accessible ?

Utilisez : Uptime monitoring Un contrôle externe qui vérifie que votre endpoint répond toujours. C’est la seule alerte qui fonctionne encore lorsque votre application ne peut plus rien envoyer à AppSignal, ce qui explique pourquoi la plupart des équipes la mettent en place en premier. AppSignal appelle l’URL chaque minute depuis quatre régions et signale un échec lorsque la réponse n’est pas dans la plage 2xx ou n’arrive pas dans les 30 secondes. Chaque région est suivie séparément, donc un monitor ouvre une alerte par région en échec. Une véritable panne ouvre jusqu’à quatre alertes, et un problème réseau entre une région et votre endpoint en ouvre une alors que votre application va bien. C’est la principale raison de définir un warm-up sur les uptime monitors : l’échec d’une seule région qui se résout en moins d’une minute n’envoie pas de notification. Un uptime monitor produit aussi des métriques taguées par région et par nom de monitor, vous pouvez donc ajouter des Anomaly detection triggers sur le temps de réponse par région si vous avez besoin d’alertes plus fines que « accessible ou non ». La surveillance de l’expiration des certificats SSL est disponible comme fonctionnalité AppSignal Labs. Une fois activée, vous l’activez sur un monitor https:// individuel plutôt que de construire un trigger à la main, et AppSignal vous notifie lorsqu’il reste moins de 14 jours au certificat, en utilisant les mêmes notifiers que le monitor. L’expiration d’un certificat est un problème qui évolue lentement : acheminez-la vers l’e-mail ou le chat plutôt que vers l’astreinte.

​
Les utilisateurs rencontrent-ils des erreurs ?

Utilisez : Un Anomaly detection trigger sur le taux d’erreurs, restreint à un namespace Le taux d’erreurs est l’indicateur le plus rapide que les utilisateurs subissent des erreurs, et il reste significatif quand le trafic change. Le trigger suggéré dans AppSignal démarre à 20 %, ce qui est volontairement prudent pour qu’une nouvelle application ne produise pas immédiatement des alertes. Abaissez-le une fois que vous connaissez votre référence. Créez un trigger distinct et plus tolérant pour background. Les échecs de jobs font généralement l’objet de retries, ils justifient donc rarement la même urgence que des requêtes web en échec. Faire tourner deux triggers de taux d’erreurs à des seuils différents fonctionne bien, à condition que chacun ait une destination différente. Un trigger à votre seuil de dégradation habituel part vers le chat, et un second à un seuil bien plus élevé, comme 50 %, signale un problème sérieux et devrait notifier l’astreinte. Deux seuils pointant vers le même notifier ne font que doubler les notifications.

​
Quand utiliser plutôt le nombre d’erreurs

Le nombre d’erreurs franchit un seuil fixe dès que le trafic augmente, il vous notifie donc les jours chargés, que quelque chose aille mal ou non. Ne l’utilisez que là où chaque occurrence compte et où le volume est naturellement faible, comme un namespace de paiement ou d’inscription. Restreignez-le étroitement et fixez un seuil bas.

​
Les requêtes deviennent-elles lentes ?

Utilisez : Un Anomaly detection trigger sur la performance, mesurée en millisecondes Les moyennes masquent les requêtes lentes pour une partie de votre trafic. Si une requête sur 20 prend 8 secondes alors que les autres sont rapides, la moyenne bouge à peine, mais 5 % des utilisateurs subissent une requête lente. Les percentiles corrigent cela. Un p95 de 400 ms signifie que 95 requêtes sur 100 se sont terminées en moins de 400 ms, et que les cinq plus lentes ont pris plus longtemps. Alertez sur p90 ou p95 plutôt que sur la moyenne, afin de remarquer un problème qui affecte une partie de votre trafic. Le trigger suggéré par AppSignal utilise une moyenne au-dessus de 500 ms, ce qui constitue une première alerte raisonnable mais passera à côté d’une dégradation partielle. Passez au p95 dès que vous avez une référence. Pour surveiller un seul chemin critique plutôt qu’un namespace entier, utilisez un trigger de performance restreint à une action. Le checkout, la connexion et la recherche sont des candidats fréquents. Donnez à chacun un seuil qui lui convient : une page qui appelle une API tierce peut raisonnablement prendre 10 secondes, une page d’accueil non.

​
Le trafic a-t-il disparu ?

Utilisez : Un Anomaly detection trigger sur le throughput, mesuré en requêtes par minute Une chute brutale du throughput signifie généralement qu’une défaillance s’est produite avant que les requêtes n’atteignent votre application : un domaine expiré, un load balancer mal configuré, ou une panne de CDN. Cette défaillance est invisible pour vos autres alertes, car une application qui ne reçoit aucun trafic ne rapporte ni erreurs ni requêtes lentes. Fixez le seuil par rapport à votre période la plus calme, et non à votre moyenne, sinon le trigger vous notifiera chaque nuit. Si votre trafic varie trop pour qu’un plancher fixe fonctionne, alertez plutôt lorsque le trafic atteint exactement zéro, comme décrit dans la section suivante.

​
Alerter sur un trafic trop élevé

Un trafic très supérieur à votre pic habituel peut aussi nécessiter un trigger. Il peut venir d’une croissance attendue, comme une campagne réussie, ou d’un problème, comme un bot qui aspire votre catalogue ou un client qui fait des retries en boucle. Dans les deux cas, l’alerte vous aide à réagir avant que le trafic n’épuise votre capacité. Réglez la comparaison sur More than, avec un seuil bien au-dessus de votre heure normale la plus chargée, et acheminez-la vers le chat. C’est rarement assez urgent pour une notification d’astreinte, mais cela explique de nombreuses autres alertes qui arrivent peu après.

​
L’activité s’est-elle arrêtée ?

Utilisez : Un Anomaly detection trigger avec un seuil d’exactement zéro Certaines des alertes les plus précieuses portent sur une absence plutôt que sur un excès. Un consommateur de file qui cesse de consommer, un namespace qui cesse de recevoir du trafic, ou une étape de pipeline qui cesse de produire des résultats peuvent ne montrer aucune erreur, aucune requête lente et aucune saturation. C’est l’activité manquante qui est le problème. Activer treat missing datapoints as 0 est ce qui fait fonctionner cela. Sans cette option, une métrique qui cesse complètement de rapporter n’envoie aucun point de donnée, le trigger n’a donc rien à évaluer et l’alerte ne s’ouvre jamais. Avec elle, AppSignal traite les données manquantes comme zéro et l’alerte s’ouvre comme prévu. De bons candidats sont le throughput par namespace, un compteur de jobs traités avec succès, ou un nombre de processus qui ne devrait jamais tomber à zéro. Ce motif est aussi le moyen fiable de remarquer un worker qui est mort plutôt que ralenti.
Utilisez ceci pour du travail continu qui devrait toujours être en cours. Pour du travail qui s’exécute selon un planning, utilisez plutôt des check-ins, qui sont conçus pour cela et n’ont pas besoin d’un warm-up assez long pour couvrir l’intervalle entre deux exécutions.

​
Le travail s’accumule-t-il ?

Utilisez : Un Anomaly detection trigger sur le temps en file d’attente, mesuré en millisecondes Le temps en file d’attente mesure combien de temps une requête ou un job a attendu avant que votre application commence à le traiter. Un temps en file d’attente qui augmente est un avertissement précoce que la capacité manque, généralement avant que les temps de réponse ou les taux d’erreurs ne réagissent. Votre application peut ne rapporter ni erreurs ni requêtes lentes alors que les utilisateurs attendent toujours : une commande confirmée des heures après avoir été passée, ou un rapport qui arrive un jour en retard. En pratique, la profondeur de file est souvent le signal le plus simple sur lequel alerter. Si vous suivez déjà le nombre de jobs en attente ou de messages non traités comme métrique personnalisée, un seuil de profondeur est concret, facile à raisonner et facile à fixer d’après l’historique. Taguez-le par nom de file pour qu’un backlog dans une file ne se lise pas comme une panne générale. Utilisez les deux quand vous pouvez. La profondeur vous dit que le backlog grandit ; le temps en file d’attente vous dit qu’il affecte déjà quelqu’un.

​
Les hôtes manquent-ils de ressources ?

Utilisez : Des triggers de métriques d’hôte Les alertes d’hôte décrivent des causes plutôt que des symptômes visibles par les utilisateurs : acheminez-les donc vers des canaux moins urgents que les alertes visibles par les utilisateurs. Un hôte à 95 % de CPU avec des temps de réponse sains n’est pas un incident. Les alertes d’hôte sont utiles parce qu’elles vous avertissent avant qu’une ressource ne soit complètement épuisée, moment où une application peut s’arrêter brutalement et où d’autres alertes peuvent s’ouvrir toutes en même temps. Chaque trigger d’hôte accepte un hostname, et sa valeur par défaut * correspond à tous les hôtes. Indiquez un nom précis ou un préfixe comme web-*, sauf si vous voulez vraiment une alerte par hôte du parc.

​
Utilisation du disque

C’est l’alerte d’hôte la plus claire à configurer, car un disque plein provoque des défaillances de façon fiable et l’utilisation du disque augmente souvent de manière prévisible. Fixez le seuil d’après la vitesse de remplissage du disque, et non d’après son niveau de remplissage. Un hôte polyvalent qui gagne un point de pourcentage par semaine va bien à 80 %. Un hôte de base de données ou de file qui peut gagner 20 points en une heure doit vous avertir à 60 %, car le temps restant compte davantage que l’espace restant. Cela signifie généralement plusieurs triggers de disque plutôt qu’un seul, chacun restreint à un groupe d’hôtes avec un caractère joker, par exemple db-* à 60 % et web-* à 80 %. Définissez aussi un trigger par mountpoint qui vous intéresse. Un trigger sans tag de mountpoint correspond à tous les systèmes de fichiers montés, y compris les montages de conteneurs éphémères.

​
Utilisation de la mémoire

Le pourcentage est généralement plus facile à réutiliser sur des hôtes de tailles différentes. Les valeurs absolues conviennent mieux lorsque vous savez quelle capacité libre une charge de travail précise nécessite.

​
Utilisation du swap

Lorsqu’un serveur commence à manquer de mémoire, il déplace des données vers le disque, ce qui est bien plus lent que la mémoire. L’application continue de fonctionner, aucune erreur ne se produit donc nécessairement, mais les requêtes peuvent devenir plus lentes. Il est utile d’alerter sur cela, car l’impact peut être progressif et facile à manquer. Le trigger suggéré dans AppSignal vous notifie dès qu’un hôte utilise du swap, ce qui est un moyen raisonnable de découvrir si vos hôtes en font. C’est généralement trop sensible pour être conservé sur le long terme : beaucoup d’hôtes sains allouent un peu de swap et n’y touchent plus jamais. Une fois votre référence connue, passez à un seuil en pourcentage afin que l’alerte s’ouvre pour une véritable pression mémoire plutôt que pour quelques mégaoctets alloués au démarrage.

​
Utilisation CPU et load average

L’agent rapporte le CPU par état plutôt qu’en un seul total : choisissez donc l’état qui décrit le travail qui vous intéresse, et utilisez iowait lorsque vous suspectez que l’hôte attend le disque plutôt qu’il ne calcule. Les hausses brèves de CPU sont normales. Seule une utilisation CPU élevée et durable nécessite généralement une notification, et même dans ce cas elle relève du chat plutôt que de l’astreinte, sauf si elle affecte déjà les temps de réponse. Le load average est souvent le plus utile des deux sur les hôtes de bases de données et de workers, car il compte les processus qui attendent le disque autant que le CPU. Il n’est toutefois pas comparable d’une machine à l’autre : un load average de 60 est une saturation sur un hôte à 16 cœurs et reste sain sur un hôte à 128. Restreignez un trigger de load average à une classe d’hôtes avec un caractère joker et fixez le seuil d’après le nombre de cœurs de cette machine, plutôt que de faire tourner un seul trigger sur un parc hétérogène.

​
Throughput disque et réseau

Les triggers d’I/O disque et de trafic réseau couvrent les données lues et écrites sur chaque disque, et les données reçues et transmises par chaque interface réseau. Pour la plupart des équipes, ils font de meilleurs graphiques de dashboard que des alertes, car un seuil pertinent dépend fortement de la charge de travail. Alertez sur eux lorsque vous avez un plafond connu, comme une limite d’IOPS provisionnée.

​
Le travail planifié s’est-il exécuté ?

Utilisez : Check-ins Anomaly detection ne peut pas vous dire de façon fiable qu’un travail planifié n’a pas eu lieu, car un trigger n’évalue que les données qui arrivent. Utilisez des check-ins pour cela.
  • Check-in cron, pour les jobs qui s’exécutent selon un planning. Son réglage clé est l’expression cron, plus un fuseau horaire.
  • Check-in heartbeat, pour les workers et processus censés continuer de tourner. Son réglage clé est la durée maximale depuis le dernier heartbeat.
Les deux utilisent une Maximum duration en minutes plutôt qu’un warm-up. Pour un process monitor cron, AppSignal signale un échec lorsqu’aucun événement n’arrive entre l’heure de début définie par le planning et la fin de cette durée. Pour un heartbeat, il signale un échec lorsqu’aucun événement n’arrive dans cette durée après le précédent. Réglez-la plus longue que la variation normale du job en heure de démarrage et en durée d’exécution, afin qu’un job qui démarre occasionnellement quelques minutes en retard ne notifie personne. De bons candidats sont les traitements de facturation nocturnes, les sauvegardes, les exports de données, les tâches de préchauffage du cache, et tout consommateur de longue durée.

​
Une dépendance est-elle défaillante ?

Utilisez : Log triggers Certaines défaillances ne deviennent jamais un incident ni une métrique. Un fournisseur de paiement qui part en timeout puis réussit au retry ne laisse ni erreur ni pic de latence assez marqué pour être remarqué, mais un motif durable mérite d’être connu. Partez de la requête qui trouve les lignes. Si vous les consultez déjà dans le terminal, c’est cette requête que vous avez :
Shell
Dès que la requête ne trouve que les lignes attendues, créez le trigger à partir d’elle. Le même texte de requête est réutilisé :
Shell
Pour faire la même chose dans l’interface, filtrez la page Logs sur les lignes qui vous intéressent, sélectionnez-en une pour ouvrir Log details, et créez le trigger depuis la section Actions, qui reprend votre requête, votre severity et votre source. Consultez log triggers pour le déroulé complet. Les Log triggers fonctionnent différemment des triggers de métriques, et la différence compte pour le bruit. Un Log trigger est évalué sur les lignes de log individuelles à mesure qu’elles arrivent, il n’a donc pas les réglages de warm-up et de cooldown des triggers d’anomalie. Contrôlez plutôt le volume de notifications avec le réglage de seuil :
  • First After Close pour un problème qui se résout de lui-même, afin d’obtenir une notification chaque fois que le problème revient après avoir été clos.
  • Nth in an hour pour un motif de log qui correspond de façon intermittente par conception, où le nombre de lignes correspondantes est le signal important.
  • Every Occurrence seulement là où une seule ligne compte vraiment.
Utilisez Never Notify pour les motifs que vous voulez suivre et compter sans notifier personne.

​
Obtenir warm-up et cooldown sur des données de log

Lorsqu’un motif de log est trop bruyant pour l’un de ces seuils, convertissez-le en métrique au lieu d’alerter directement sur les lignes. Extrayez une métrique issue des logs à partir des lignes correspondantes, puis pointez un Anomaly detection trigger sur cette métrique. Cela fait deux commandes. D’abord, comptez les lignes correspondantes dans une métrique. Un counter n’a pas besoin de champ, car il compte des lignes plutôt que d’y lire une valeur :
Shell
Ensuite, alertez sur cette métrique, là où warm-up et cooldown deviennent disponibles :
Shell
Cela donne aux données issues des logs la machine à états complète : un seuil, un warm-up pour ignorer une hausse brève, et un cooldown pour qu’un problème récurrent produise une seule alerte. C’est l’approche recommandée pour une dépendance qui défaille par courtes périodes plusieurs fois par jour.

​
Une métrique métier est-elle anormale ?

Utilisez : Un Anomaly detection trigger sur une métrique personnalisée Les métriques personnalisées sont le seul moyen d’alerter sur des valeurs propres à l’application qu’AppSignal ne peut pas déduire, comme les paiements réussis par minute, les inscriptions, ou la taille d’une file de travail. C’est la seule défaillance qu’aucune autre alerte de cette page ne peut détecter. Si un changement chez votre fournisseur de paiement se met à rejeter toutes les transactions, votre application reste accessible, rapide et sans erreur alors que rien n’est vendu : seule une métrique que vous envoyez vous-même peut le détecter. Tracez d’abord la métrique, puis fixez le seuil d’après ce que vous voyez. Pour vérifier une métrique personnalisée dans l’interface d’alerting, ouvrez Anomaly detection, allez dans Triggers, sélectionnez Add trigger, puis choisissez Custom metrics sous Other. Saisissez le nom de la métrique et utilisez l’aperçu du graphique et les combinaisons de tags pour confirmer qu’AppSignal a bien reçu la métrique.

​
Étapes suivantes