Skip to main content
Chaque fois qu’AppSignal détecte une nouvelle erreur, il ouvre un incident. Vous pouvez trouver les incidents dans la section Erreurs. AppSignal peut envoyer des notifications lorsqu’il détecte un nouvel incident ou une nouvelle occurrence d’un incident existant. Les notifications peuvent être envoyées par e-mail ou par l’un de nos nombreux notificateurs.
Ces paramètres s’appliquent aux incidents d’erreur. La performance ne déclenche pas d’alertes via des incidents. Pour être averti quand une action devient lente, configurez un trigger comme décrit dans la section alerting de performance. Les alertes des Anomaly detection triggers sont acheminées par les notifiers sélectionnés sur chaque trigger.

Options de notification

Chaque fois qu’un nouvel incident est créé, il héritera des valeurs par défaut de notification de l’application. Lorsqu’un incident d’erreur a été créé, ses paramètres de notification peuvent être modifiés sur la page de l’incident elle-même. Si un incident a été fermé, il sera rouvert lorsqu’une nouvelle notification est envoyée. Six options de notification sont disponibles : Les nouveaux incidents d’erreur sont par défaut sur First in Deploy.

Every Occurrence

Une notification est envoyée chaque fois qu’un incident est déclenché. Cette option a un temps de recharge de 5 minutes. Cela signifie que si un incident est déclenché 20 fois par minute, pendant 20 minutes, vous recevrez une notification à la minute 0, 5, 10, 15 et 20.

First in Deploy

Une notification est envoyée à la première occurrence d’un incident après qu’un nouveau marqueur de déploiement soit reçu. Vous devrez configurer les marqueurs de déploiement pour qu’AppSignal détecte un déploiement et sache quand un incident s’est produit pour la première fois dans un déploiement.

First After Close

Une notification est envoyée à la première occurrence d’un incident après que l’incident a été précédemment fermé. Les incidents peuvent être ouverts et fermés dans la barre latérale de la page de détail de l’incident. Cette option est une bonne option pour les incidents qui ne sont pas déclenchés par un bug de code, mais par une source externe (par exemple, un tiers a un problème de connexion) et ne peuvent pas être fermés en déployant une nouvelle version de l’application.

Never Notify

Aucune notification n’est envoyée lorsque l’incident est déclenché. Comme un incident n’est rouvert que lorsqu’AppSignal envoie une notification, un incident réglé sur Never Notify reste fermé même s’il se produit à nouveau. Principalement utilisé pour les erreurs qui continueront à se produire et que vous souhaitez suivre, mais qui ne seront pas corrigées rapidement. Si vous ne souhaitez pas recevoir l’incident du tout, ignorer l’action ou ignorer l’erreur peut aider.

Every Nth per Hour or Day

Aucune notification n’est envoyée toutes les n fois par heure, ou par jour, selon vos préférences. Il existe de nombreux scénarios où cela peut être bénéfique :
  • Erreur de facturation : Imaginez qu’une erreur de facturation se produise de temps en temps, en dehors de votre contrôle. Cela se produit au maximum 5 fois par jour, et vous voulez savoir quand cela augmente soudainement. Le régler sur « toutes les 10 fois par jour » vous enverra une alerte à chaque 10e, 20e, 30e occurrence, etc.
  • Erreur d’API : Vous pouvez avoir une API que beaucoup de personnes utilisent. Lors d’expérimentations avec une API, faire des erreurs qui déclenchent des erreurs est courant. Vous pouvez vouloir n’être alerté que lorsque le nombre d’erreurs atteint un seuil. Vous pourriez, par exemple, le régler pour vous notifier toutes les 1000 fois par heure, ce qui pourrait indiquer que l’API échoue pour différentes raisons.
  • Pendant un incident : Imaginez que quelque chose soit gravement cassé. Des centaines d’erreurs par heure se produisent, mais vous êtes au courant. Il pourrait ne pas être judicieux d’ignorer complètement toutes les alertes, mais recevoir chacune d’elles vous noiera sous les notifications. C’est le moment parfait pour gérer le nombre de notifications que vous recevez en réglant temporairement vos erreurs sur N/heure.
Visualisation des notifications toutes les 100 occurrences par heure La visualisation montre quand vous recevriez des alertes. Dans ce scénario, les notifications sont définies sur « Toutes les 100 occurrences par heure ». Avant de choisir Every Nth per Hour, demandez-vous si votre cas d’usage dépend de l’accumulation des incidents au-delà des limites horaires. Le compteur est réinitialisé au début de chaque heure, de sorte que les incidents qui atteignent presque le seuil avant la fin de l’heure ne sont pas ajoutés aux incidents de l’heure suivante.

Paramètres de notification des incidents d’erreur

Les incidents d’erreur sont identifiés par le nom de la classe d’erreur, tel que ActiveRecord::RecordNotFound et si l’erreur s’est produite à l’intérieur d’une action, le nom de l’action. (par exemple, StandardError dans BlogpostsController#show). Options de notification d'incident d'erreur

Alerting de performance

Les options de notification décrites dans les sections précédentes s’appliquent aux incidents d’erreur. La performance utilise des triggers à la place. Les erreurs sont binaires : elles se produisent ou non, ce qui rend une option comme First in Deploy pertinente pour elles. La performance se comporte différemment. Si votre base de données est surchargée, déployer du nouveau code ne changera pas le temps de réponse. Une notification à propos d’une seule trace lente en dit d’ailleurs peu sur la santé de votre application. Les problèmes de performance se déroulent sur une période donnée, ce qu’un trigger mesure.

Créer un trigger pour une action lente

Ouvrez l’action de performance que vous souhaitez surveiller, comme run/shop.send_waitlist_notification, puis sélectionnez Add new dans le panneau Triggers. Panneau Triggers sur une action de performance, avec une option pour ajouter un nouveau trigger Un formulaire de trigger Slow action s’ouvre, avec Namespace et Action Name déjà renseignés. Dans le formulaire, vous définissez :
  • Alert me when : la valeur sur laquelle alerter, comme la durée moyenne, et dans Is above le seuil qu’elle doit dépasser. La valeur par défaut est 200 ms. Pour les actions censées être lentes parce qu’elles interagissent avec des tiers, définissez un seuil plus élevé que pour votre page d’accueil.
  • Alert warm-up et Alert cooldown : combien de temps la condition doit être remplie avant qu’une alerte s’ouvre, et combien de temps attendre avant de la fermer. Voir warm-up et cooldown.
  • Description et Notify me through : une note expliquant ce que le trigger surveille, et les notifiers à travers lesquels alerter.
Un aperçu du graphique à côté du formulaire montre les valeurs récentes de l’action, ce qui vous aide à choisir un seuil adapté à son comportement normal. Sélectionnez Save trigger pour le créer. Les triggers créés de cette façon sont listés avec vos autres triggers dans la section Anomaly detection, où vous pouvez aussi les modifier plus tard.

Valeurs par défaut de l’organisation et de le namespace de l’application

Les paramètres de notification sur un incident ne peuvent être modifiés qu’après qu’il se soit produit au moins une fois. Cela peut poser problème si vous ne souhaitez jamais être notifié. Il est possible de configurer les valeurs par défaut de notification par namespace d’application ou même pour l’ensemble de l’organisation. Cela facilitera l’application des paramètres de notification souhaités à tous les nouveaux incidents et à tous les incidents existants, pour lesquels les paramètres de notification n’ont pas été personnalisés.

Valeurs par défaut de notification de l’application

Chaque application a ses propres valeurs par défaut de namespace pour les paramètres de notification. Un nouvel incident dans le namespace spécifié héritera des paramètres par défaut définis sur cette page. Pour plus d’informations, consultez la section héritage des valeurs par défaut de notification. Il est recommandé de diviser l’application en namespaces qui regroupent les incidents potentiels par sévérité. De cette façon, vous pouvez configurer les paramètres de notification pour un groupe d’incidents et il n’est pas nécessaire de configurer chaque incident séparément. Par exemple, pour le panneau d’administration d’une application, vous pourriez créer un namespace appelé admin avec un paramètre de notification par défaut de « Never Notify » car les erreurs qui se produisent dans cet namespace ont moins de priorité.

Valeurs par défaut de notification de l’organisation

Il est également possible de configurer les valeurs par défaut de notification au niveau de votre organisation. Ces valeurs par défaut seront utilisées lorsqu’AppSignal détecte et crée une nouvelle application. Lorsqu’il crée la nouvelle application, il applique les valeurs par défaut de notification de l’organisation comme valeurs par défaut de notification de l’application. Les modifications apportées aux valeurs par défaut de notification de l’organisation ne s’appliquent pas aux applications existantes. Pour plus d’informations, consultez la section héritage des valeurs par défaut de notification. Ces valeurs par défaut de notification au niveau de l’organisation peuvent être configurées dans le panneau d’administration de l’organisation. Il est possible de configurer des valeurs par défaut pour chaque namespace détecté dans n’importe laquelle des applications actuelles de votre organisation.

Héritage des valeurs par défaut de notification

Les paramètres de notification remontent des paramètres d’incident aux paramètres de namespace de l’application. Si les paramètres de notification d’un incident ne sont pas modifiés, les valeurs par défaut de le namespace de l’application sont utilisées. Cela signifie que vous pouvez également modifier tous les paramètres de notification d’incident pour les incidents qui n’ont pas personnalisé leurs paramètres de notification en modifiant les valeurs par défaut de l’application.