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 :- Every Occurrence
- First in Deploy
- First After Close
- Never Notify
- Every Nth per Hour
- Every Nth per Day
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.

Paramètres de notification des incidents d’erreur
Les incidents d’erreur sont identifiés par le nom de la classe d’erreur, tel queActiveRecord::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).

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, commerun/shop.send_waitlist_notification, puis sélectionnez Add new dans le panneau Triggers.

- 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.
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.- Lorsqu’une nouvelle application est détectée par AppSignal, les valeurs par défaut de namespace de l’organisation sont appliquées.
- Lorsque les valeurs par défaut de notification de namespace de l’organisation sont modifiées, elles ne s’appliquent qu’aux nouvelles applications.
- Lorsque les valeurs par défaut de notification de namespace d’une application sont modifiées, elles s’appliquent à tous les nouveaux incidents et aux incidents existants sans paramètres de notification personnalisés.
- Lorsqu’un nouvel incident est détecté par AppSignal, les valeurs par défaut de namespace de l’application sont utilisées.
- Lorsque les paramètres de notification d’un incident sont personnalisés, les paramètres de notification personnalisés de l’incident sont utilisés à partir de ce moment.