Avant de créer un trigger
Trois étapes de configuration rendent plus utile chaque alerte qui suivra, et toutes les trois sont plus faciles à faire d’emblée qu’à rattraper ensuite. Ajoutez vos notifiers. Les triggers référencent des notifiers : les créer d’abord vous permet d’acheminer chaque alerte au moment où vous la construisez, plutôt que de tout reprendre plus tard. Mettez en place au moins deux destinations : une pour l’urgent, comme un outil d’astreinte, et une pour le non-urgent, comme un canal de chat d’équipe. Les notifiers sont configurés une fois pour l’organisation et partagés entre les applications. Envoyez des deploy markers. La plupart des incidents de production commencent par une mise en production. Un marker transforme « quand est-ce que cela a commencé ? » en une question à laquelle vous pouvez répondre en quelques secondes, et c’est ce qui fait fonctionner le réglage de notification First in Deploy. Découpez votre application en namespaces. Les namespaces sont le principal levier pour alerter à différents niveaux de gravité sans configurer chaque alerte individuellement. Si le traficweb, background et admin arrive dans un seul namespace, chaque seuil que vous définissez doit convenir aux trois à la fois, ce qui signifie généralement qu’il ne convient à aucun.
Ajouter les alertes par couches
Ajouter toutes les alertes d’un coup produit trop de notifications dès le premier jour et apprend à l’équipe à les ignorer. Ajoutez une couche, vivez avec pendant une semaine, puis ajoutez la suivante.- Accessibilité. Un uptime monitor sur un endpoint de health-check. C’est la seule alerte qui fonctionne encore lorsque votre application ne peut plus rien rapporter du tout.
- Symptômes visibles par les utilisateurs. Taux d’erreurs et temps de réponse sur votre namespace visible par les utilisateurs. Ces alertes correspondent aux erreurs ou aux temps de réponse lents que subissent les utilisateurs.
- Travail planifié et en background. Des check-ins pour les tâches cron et les heartbeats de workers, et une alerte d’absence pour toute file d’attente qui ne devrait jamais être dépourvue d’activité.
- Saturation. Disque, mémoire et swap de l’hôte. Ce sont des causes plutôt que des symptômes, acheminez-les donc vers le chat plutôt que vers l’astreinte.
- Métriques métier. Des métriques personnalisées pour l’activité propre à votre application que vous seul pouvez mesurer, comme les paiements aboutis ou les inscriptions par minute.
Garder le bruit de staging et de test hors de la production
L’alerting de production ne reste crédible que si le bruit hors production ne l’atteint jamais.- Donnez à chaque environnement sa propre application dans AppSignal, afin que les seuils et les notifiers soient définis par environnement plutôt que partagés.
- Donnez à la staging son propre canal de chat, ou laissez ses triggers sans aucun notifier. Un trigger sans notifier enregistre toujours des alertes que vous pouvez consulter plus tard, sans notifier personne.
- Utilisez des seuils différents. Le trafic de staging est plus faible et change davantage que celui de production : un seuil réglé sur des données de production peut n’ouvrir jamais d’alerte, ou en ouvrir trop souvent.
- Gardez les canaux de test personnels hors des applications de production. Un notifier peut être partagé par plusieurs applications, et les alertes de trigger sont acheminées par les notifiers sélectionnés sur chaque trigger.
Vérifier votre couverture
Trop de notifications est la défaillance visible. La défaillance cachée est une panne dont personne n’a été alerté. Parcourez les modes de défaillance plutôt que les fonctionnalités, et vérifiez que chacun dispose d’une alerte :
La dernière ligne est celle qui manque le plus souvent. Toutes les autres alertes de cette liste ont besoin que des données arrivent pour pouvoir s’ouvrir.
Deux questions sont utiles pour passer l’ensemble en revue. D’abord, pour chaque ligne que vous couvrez, l’alerte atteint-elle quelqu’un capable d’agir au moment de la journée où elle est la plus susceptible de s’ouvrir ? Ensuite, parmi vos derniers incidents de production, combien ont d’abord été signalés par une personne plutôt que par une alerte ? Ce second nombre est une mesure utile de votre couverture.
Décider de la vitesse à laquelle vous devez savoir
La détection n’est pas instantanée, et il vaut la peine de décider délibérément du délai que chaque alerte peut supporter. Trois facteurs s’additionnent pour former le temps entre le début d’un problème et l’arrivée d’une notification :- Agrégation. Les métriques sont évaluées une fois par minute, il s’écoule donc toujours jusqu’à une minute avant que la valeur en cause soit même prise en compte.
- Traitement. AppSignal attend une minute que les données arrivent de tous vos serveurs avant de les évaluer.
- Warm-up. Le nombre de minutes qu’AppSignal attend avant d’ouvrir l’alerte.
- Paiement ou commande cassés, de sorte que les clients ne peuvent pas acheter, réserver ou transférer de l’argent. Le plus vite possible, donc peu ou pas de warm-up.
- Site ou application inaccessible. 1–2 minutes.
- Taux d’erreurs élevé, de sorte que les clients rencontrent des erreurs. 1–2 minutes.
- Dégradation du temps de réponse, de sorte que les requêtes prennent plus de temps que d’habitude. 1–3 minutes.
- File d’attente qui s’accumule, de sorte que le travail est encore traité mais arrive en retard. 1–3 minutes.
- Utilisation du disque approchant de la capacité maximale. 10–60 minutes.
Vérifier une alerte avant de compter sur elle
Un trigger qui ne correspond à rien peut donner l’impression d’un système en bonne santé. Avant de compter une alerte comme une couverture, confirmez tout ce qui suit :- L’aperçu du graphique affiche des données. Un aperçu vide dans le formulaire du trigger signifie que le trigger ne correspond actuellement à rien.
- Le hostname se résout. Si le champ hostname avertit que l’hôte n’a pas été trouvé, le trigger surveille probablement une machine qui a été renommée ou remplacée.
- La combinaison de tags est reconnue. AppSignal avertit lorsqu’une combinaison de tags n’a pas été vue au cours de la dernière heure. Utilisez l’une des combinaisons de clés de tags listées dans le formulaire du trigger, et donnez à chaque valeur une valeur exacte ou un caractère joker.
- Un notifier est attaché. Un trigger sans notifier enregistre des alertes sans envoyer de notifications.
- Le notifier fonctionne. Envoyez une notification de test, et confirmez qu’elle arrive dans le canal attendu plutôt que dans un canal qui y ressemble.
- Les alertes d’absence gèrent les données manquantes. Pour tout trigger dont le seuil est zéro ou une valeur minimale, vérifiez que treat missing datapoints as 0 est activé, sinon il ne s’ouvrira pas précisément dans le cas pour lequel vous l’avez créé.
Maintenir l’alerting après la mise en place
L’alerting n’est pas terminé une fois qu’il est en place.- Écrivez le runbook dans le trigger. Un nom qui dit ce qui ne va pas, une description qui dit quoi faire, et un dashboard lié. Traité dans faire en sorte que la notification s’explique d’elle-même.
- Évitez de réajuster pendant un incident. Modifier les réglages d’un trigger peut affecter l’alerte que vous suivez actuellement, y compris en fermant ou en remplaçant l’état actif de l’alerte.
- Passez en revue chaque trimestre. L’alerting se dégrade à mesure que les hôtes sont remplacés, les services renommés et le trafic augmente. La checklist de revue indique ce qu’il faut examiner.
- Ajoutez une alerte après chaque incident, et retirez-en une aussi. La revue post-incident est le meilleur moment pour remarquer à la fois ce qui manquait et ce qui s’est ouvert sans nécessiter d’action.
Étapes suivantes
- Choisissez des configurations dans les modèles d’alertes.
- Réduisez le volume avec affiner vos alertes.
- Définissez les valeurs de notification par défaut par namespace.
- Mettez en place des check-ins pour le travail planifié.