Foire aux questions - AppSignal Documentation

Il n’y a pas de question stupide. Sur cette page, vous trouverez les réponses à celles qu’on nous pose le plus fréquemment. Si vous avez besoin d’une aide supplémentaire, consultez notre page d’assistance

Sommaire

Premiers pas
- J’ai besoin d’aide pour démarrer. Où commencer ?
Bibliothèques AppSignal
Compte utilisateur
Erreurs et performances
Logging
- Comment ajouter des attributs de log comme colonnes dans la vue des logs ?

Premiers pas

J’ai besoin d’aide pour démarrer. Où commencer ?

Si vous découvrez AppSignal ou souhaitez en savoir plus sur la configuration des fonctionnalités d’AppSignal, veuillez lire nos guides

Bibliothèques AppSignal

Quels langages de programmation AppSignal prend-il en charge ?

AppSignal prend en charge les langages de programmation Node.js, Ruby et Elixir. Nous proposons également des packages JavaScript pour capturer les erreurs côté client dans les navigateurs pris en charge.

Filtrer les données

Comment ignorer les actions dans mon application ?

Vous pouvez ignorer des actions pour cesser d’enregistrer les données de certaines actions, requêtes, background jobs, etc.

Comment ignorer les erreurs dans mon application ?

Vous pouvez ignorer des erreurs (en fonction de leur nom) pour empêcher AppSignal de les signaler et de vous alerter.

Comment filtrer les données envoyées à AppSignal ?

Pour découvrir comment filtrer les données envoyées à AppSignal, consultez l’un des guides suivants :

Quelle syntaxe regex ignore_logs prend-il en charge ?

ignore_logs prend en charge un sous-ensemble limité de la syntaxe des expressions régulières : ^ (début de chaîne), $ (fin de chaîne) et .* (joker). Les constructions regex complètes telles que les classes de caractères ([.]) ne sont pas valides et sont silencieusement ignorées. Pour faire correspondre une ligne de log exacte, encadrez-la avec ^ et $. Pour faire correspondre un préfixe, utilisez ^ suivi du texte littéral. Pour faire correspondre n’importe où dans le message, utilisez .* autour de celui-ci. Consultez le guide ignore logs pour la référence complète de la syntaxe.

Pourquoi les requêtes d’Uptime monitoring comptent-elles dans mon budget, et comment les exclure ?

Les moniteurs d’Uptime monitoring interrogent votre endpoint selon un calendrier régulier, et si AppSignal est installé, ces requêtes sont comptabilisées comme des transactions dans votre budget mensuel de requêtes. Pour qu’elles cessent d’être comptabilisées, ajoutez l’action de health-check à ignore_actions dans votre configuration AppSignal — AppSignal cesse alors totalement d’enregistrer ces transactions. Pour Ruby :

config.ignore_actions += ["GET /health"]

Pour Node.js :

new Appsignal({ ignoreActions: ["GET /health"] })

Pour Python (Django ou d’autres frameworks), définissez ignore_actions dans appsignal.py :

from appsignal import Appsignal
appsignal = Appsignal(
    ignore_actions=["GET /health"]
)

Pour trouver le nom exact de l’action, ouvrez Performance → Traces et copiez-le depuis la colonne Action name. Consultez le guide ignore actions pour la référence complète de la configuration.

Comment ignorer un message d’erreur spécifique dans le front-end JavaScript ?

Pour ignorer les erreurs correspondant à un modèle de message spécifique dans l’intégration JavaScript AppSignal, passez un tableau ignoreErrors lors de l’initialisation d’Appsignal. Chaque élément du tableau est une expression régulière comparée au message d’erreur.

import Appsignal from "@appsignal/javascript";
export const appsignal = new Appsignal({
  key: "<YOUR_FRONTEND_API_KEY>",
  ignoreErrors: [/Converting circular structure to JSON/],
});

Les erreurs dont les messages correspondent à un modèle de ignoreErrors ne sont pas envoyées à AppSignal. Les autres erreurs de la même classe continuent d’être signalées. Consultez les options de configuration front-end pour la liste complète des options d’initialisation.

Comment supprimer les logs envoyés par appsignal-wrap ?

appsignal-wrap transfère par défaut stdout et stderr vers AppSignal. L’option de configuration ignore_logs ne s’applique pas à appsignal-wrap. Pour supprimer la sortie, passez --no-stdout et/ou --no-stderr à la commande appsignal-wrap :

appsignal-wrap --no-stdout --no-stderr your-api-key -- your-command

Ces drapeaux sont uniquement disponibles en CLI et ne peuvent pas être définis via des variables d’environnement. Consultez la documentation appsignal-wrap pour la liste complète des options.

Comment acheminer le trafic de l’agent AppSignal via un proxy HTTP ?

Définissez l’option de configuration http_proxy (ou la variable d’environnement APPSIGNAL_HTTP_PROXY) sur l’adresse complète de votre proxy. L’agent AppSignal achemine tout le trafic sortant — transactions, erreurs, métriques et logs — via ce proxy. Pour Ruby :

Appsignal.configure do |config|
  config.http_proxy = "http://<PROXY_HOST>:<PROXY_PORT>"
end

Ou en tant que variable d’environnement :

APPSIGNAL_HTTP_PROXY=http://<PROXY_HOST>:<PROXY_PORT>

Pour Node.js, définissez httpProxy dans votre configuration :

new Appsignal({ httpProxy: "http://<PROXY_HOST>:<PROXY_PORT>" })

L’option est disponible pour les intégrations Ruby, Elixir, Node.js et Python. Votre proxy doit pouvoir établir des connexions sortantes vers les endpoints AppSignal pour que les données soient transmises. Consultez les options de configuration Ruby et les options de configuration Elixir pour la référence complète.

Comment ajouter une instrumentation supplémentaire à mon application ?

Une instrumentation supplémentaire peut être ajoutée à votre application pour vous donner plus de visibilité sur ses performances en mesurant la durée d’événements distincts. Découvrez comment dans la documentation de notre Ruby Gem et de notre package Elixir.

Quelle est la différence entre setRootName et setName ?

setName et setRootName renomment tous deux les spans, mais à des niveaux différents. setName définit le nom d’un span individuel tel qu’il apparaît dans la chronologie de la trace de performance, tandis que setRootName définit le nom de la transaction racine — ce que vous voyez dans la vue d’ensemble des performances et la liste des transactions. Un bon modèle consiste à appeler setRootName une fois sur votre gestionnaire le plus externe (par exemple, `${request.method} ${pattern}` pour produire un titre comme GET /users/:id), et à utiliser setName avec setCategory sur les spans internes tels que les middlewares, les loaders et les actions, afin qu’ils apparaissent comme des événements clairement étiquetés dans la décomposition de la chronologie. Pour en savoir plus sur le nommage et l’ajout de spans, consultez le guide d’instrumentation Node.js.

Comment exécuter plusieurs applications sur un même hôte ?

Par défaut, AppSignal est configuré en supposant qu’une seule application s’exécute sur un hôte. Si vous exécutez plusieurs applications sur un même hôte, des comportements inattendus peuvent survenir, comme des données rapportées pour une autre application. Pour configurer AppSignal pour plusieurs applications sur un même hôte, le répertoire de travail d’AppSignal doit être configuré. Pour en savoir plus sur la configuration du répertoire de travail, consultez notre guide pour exécuter plusieurs applications sur un même hôte

Quels systèmes d’exploitation AppSignal prend-il en charge ?

Veuillez consulter notre page Systèmes d’exploitation pour la liste complète des systèmes d’exploitation pris en charge et des packages requis.

Comment déboguer un problème avec l’intégration AppSignal ?

Veuillez consulter notre guide de débogage pour un guide complet sur le débogage des problèmes d’intégration AppSignal. Vous pouvez également consulter notre page Problèmes connus pour les problèmes susceptibles d’être présents dans votre version de l’intégration AppSignal.

AppSignal prend-il en charge Windows ?

AppSignal ne prend pas en charge Windows, et il n’est pas prévu d’ajouter la prise en charge de Windows. Cependant, nous nous efforçons de rendre les bibliothèques AppSignal installables sur Microsoft Windows sans erreurs ni problèmes de compilation.

Pourquoi l’installation de la gem AppSignal Ruby échoue-t-elle avec une erreur JSON::Fragment ?

Cette erreur se produit lors de l’installation d’appsignal 4.x avec Ruby 3.0 et versions antérieures. La gem json incluse comme dépendance dans AppSignal 4.x a introduit JSON::Fragment, une constante uniquement disponible à partir de Ruby 3.1. Sur les versions plus anciennes de Ruby, la compilation de l’extension native échoue avec :

uninitialized constant JSON::Fragment (NameError)

La solution recommandée est de mettre à niveau Ruby vers la version 3.1 ou ultérieure, ce qui vous permet d’utiliser la version actuelle d’AppSignal 4.x sans restrictions. Si vous ne pouvez pas mettre à niveau Ruby immédiatement, vous pouvez épingler AppSignal 3.x comme solution temporaire : ajoutez gem "appsignal", "~> 3.0" à votre Gemfile et exécutez bundle update appsignal. AppSignal 3.x fonctionne avec Ruby 2.7 et Ruby 3.0, mais ne reçoit pas les nouvelles fonctionnalités de la branche 4.x, alors prévoyez de mettre à niveau Ruby dès que possible.

Comment configurer AppSignal dans une application Hanami ?

AppSignal ne se configure pas automatiquement dans Hanami comme il le fait dans Rails. Utilisez un fichier de configuration Ruby (config/appsignal.rb) plutôt que l’ancien fichier YAML (config/appsignal.yml) — le format YAML est obsolète et sera supprimé dans la prochaine version majeure de la gem. Créez config/appsignal.rb avec :

Appsignal.configure do |config|
  config.activate_if_environment(:development, :staging, :production)
  config.name = "Your App Name"
  config.push_api_key = "your-key-here"
end

Assurez-vous ensuite que config.ru charge l’intégration après Hanami :

require "appsignal"
require "hanami/boot"

Appsignal.load(:hanami)
Appsignal.start

run Hanami.app

Si vous avez un fichier config/appsignal.yml existant, supprimez-le ou ajoutez une section development avec active: true — la présence des deux fichiers provoque des conflits. AppSignal ne démarre pas dans l’environnement development par défaut ; activate_if_environment l’active explicitement. Consultez la documentation d’intégration Hanami pour la configuration complète.

Pourquoi les erreurs dans Phoenix LiveComponent ne sont-elles pas capturées par AppSignal ?

AppSignal capture les erreurs Phoenix en écoutant les événements de télémétrie de Phoenix. Lorsqu’un LiveComponent gère directement des événements de formulaire, Phoenix utilise un chemin interne qui n’émet pas ces événements de télémétrie, de sorte que l’erreur n’est jamais signalée. Pour signaler les erreurs depuis un LiveComponent, utilisez Appsignal.send_error/2 pour les envoyer manuellement :

rescue e ->
  Appsignal.send_error(e, __STACKTRACE__)
  reraise e, __STACKTRACE__
end

Vous pouvez également déplacer la logique susceptible de lever une exception hors du template du composant vers ses callbacks handle_event/3 ou update/2, où la télémétrie de Phoenix s’active. Cette lacune a été corrigée en amont dans phoenix_live_view. Mettre à jour vers la dernière version permet à AppSignal de capturer ces erreurs automatiquement.

Compte utilisateur

Puis-je envoyer des notifications par e-mail à un membre spécifique de l’équipe ?

Les notifications par e-mail ne peuvent pas être envoyées à un membre spécifique de l’équipe. Chaque membre gère ses propres préférences de notification. Pour les mettre à jour, allez dans Account Settings → Email Settings et activez ou désactivez les notifications pour chaque application. Consultez paramètres de notification pour les options disponibles.

Comment activer l’authentification à deux facteurs (2FA) pour l’application AppSignal ?

Veuillez consulter notre page Authentification à deux facteurs pour plus d’informations sur l’activation de la 2FA.

Pourquoi mes codes d’authentification à deux facteurs (2FA) ne fonctionnent-ils pas ?

Si les codes de votre application d’authentification sont rejetés lors de la connexion, la cause la plus fréquente est un décalage d’horloge sur l’appareil qui les génère. Les codes d’authentification à deux facteurs sont basés sur le temps (TOTP), donc l’horloge de cet appareil doit être précise — cela se rompt souvent après un changement de fuseau horaire. Activez la date et l’heure automatiques (par le réseau) sur l’appareil, puis essayez le code nouvellement généré. Si vous ne parvenez toujours pas à vous connecter, utilisez l’un des cinq codes de récupération que vous avez sauvegardés lors de l’activation de la 2FA pour contourner l’authentification à deux facteurs. Consultez Authentification à deux facteurs pour en savoir plus sur les codes de récupération.

Comment réenregistrer mon appareil d’authentification à deux facteurs ?

Pour configurer la 2FA sur une nouvelle application d’authentification ou un nouvel appareil, allez dans Account Settings → Security → Two-factor authentication, désactivez la 2FA, puis réactivez-la. Un nouveau QR code apparaît pour que vous le scanniez avec votre application d’authentification. Pour accéder à l’option de désactivation, vous devez d’abord vous authentifier avec un code actuel ou un code de récupération. Consultez Authentification à deux facteurs pour les instructions de configuration complètes.

Quelles adresses IP AppSignal utilise-t-il ?

Actuellement, l’AppSignal Push API utilise les adresses IP suivantes :

191.3.93
191.3.94
191.3.125
191.3.126

Actuellement, les webhooks d’AppSignal proviennent des adresses IP suivantes :

191.3.107
191.3.72
191.3.116
191.3.84

Nous ne recommandons pas d’autoriser des adresses IP spécifiques. Elles peuvent changer, et d’autres peuvent être ajoutées à l’avenir, par exemple lorsque nous devons faire tourner nos équilibreurs de charge ou ajouter rapidement des serveurs. Si vous décidez d’autoriser nos adresses IP, veuillez envoyer un e-mail à notre équipe d’assistance, nous ferons de notre mieux pour vous avertir des changements à venir.

Erreurs et performances

Comment voir le nombre d’erreurs par namespace ?

Pour voir le nombre d’erreurs par namespace, créez un graphique Number qui utilise la métrique error_count (le décompte par AppSignal des erreurs enregistrées dans une application), filtré par le tag namespace :

Ouvrez l’application que vous souhaitez mesurer, accédez à Dashboards et ajoutez un nouveau graphique.
Sélectionnez l’onglet Number.
Définissez la métrique sur error_count.
Ajoutez le tag namespace et saisissez le nom du namespace (par exemple, web ou background).
Définissez le type d’agrégation sur Total value.
Créez le graphique.

Le graphique affiche le nombre total d’erreurs pour ce namespace sur la période sélectionnée lors de sa consultation. AppSignal stocke les données d’erreurs séparément par application, il n’y a donc pas de total unique pour toutes les applications — créez un graphique par namespace par application, et additionnez vous-même les décomptes si vous avez besoin d’un chiffre global.

Pendant combien de temps les données d’Uptime monitoring sont-elles conservées ?

Uptime monitoring stocke les métriques à la minute pendant 30 jours et les métriques horaires pendant 5 ans. Pour visualiser les tendances de disponibilité quotidiennes sur une période plus longue — par exemple, une année complète — utilisez le sélecteur de dates dans la vue Uptime monitoring pour sélectionner une plage de dates personnalisée.

Comment trouver la cause des requêtes API lentes ?

Commencez par Performance → Slow API requests. Les requêtes sont triées par impact — la combinaison de la durée et de la fréquence — donc les premières entrées sont les plus probablement responsables. La sélection d’une requête affiche sa durée moyenne, son graphique de temps de réponse, son throughput et la liste des actions qui la contiennent. Pour les requêtes de base de données, consultez Performance → Slow queries. Chaque requête est triée par impact, et en sélectionner une montre quelles actions la déclenchent. Pour trouver les requêtes N+1, ouvrez Performance → Traces. Les actions marquées du tag N+1 contiennent des appels répétés à la base de données. Ouvrez une trace et consultez la chronologie de performance — les événements marqués x2, x5, etc. indiquent que la même requête est répétée au sein d’une seule requête. Pour une procédure pas à pas guidée, consultez Trouver les requêtes de base de données lentes et Trouver les requêtes HTTP lentes.

Comment modifier la stratégie de regroupement des erreurs front-end ?

Par défaut, AppSignal regroupe les erreurs front-end par nom d’erreur. Lorsque plusieurs erreurs non capturées partagent un nom générique, elles fusionnent en un seul problème même si leurs messages et leurs stack traces diffèrent. Pour séparer les erreurs front-end trop regroupées en fonction de leur origine dans votre code, allez sur la page Settings de votre application et définissez Front-end error grouping strategy sur Relevant backtrace line strategy. Cela regroupe les erreurs par la première ligne de votre propre code dans le backtrace au lieu du nom de l’erreur. Pour que cela fonctionne, chargez les source maps de votre application — sans elles, AppSignal ne peut pas résoudre le backtrace vers vos fichiers source. Consultez Front-end source maps pour savoir comment les configurer. Vous avez besoin d’un accès owner sur l’organisation pour modifier ce paramètre. Si l’option n’est pas visible, demandez à un owner d’effectuer le changement.

Comment rechercher des erreurs par message ?

Pour rechercher des erreurs par leur texte de message, utilisez la balise message: dans la barre de recherche AppSignal. Par exemple, saisir message:"could not connect" renvoie toutes les traces d’erreurs dont le message d’erreur contient cette expression. La barre de recherche apparaît dans l’en-tête du dashboard AppSignal.

Comment recevoir les notifications d’anomalie via webhook ?

Les notifications d’anomalie via webhook sont configurées sur le trigger d’anomalie, et non sur l’écran des paramètres de webhook. Créez ou modifiez un trigger d’anomalie, faites défiler jusqu’à Notify me through, et sélectionnez le webhook que vous avez configuré dans AppSignal. L’écran des paramètres de webhook ne répertorie que les événements Deploys, Errors et Performance — la connexion pour les anomalies se trouve sur le trigger lui-même. Consultez Triggers Anomaly detection pour savoir comment configurer et modifier les triggers.

Pourquoi mon application Elixir affiche-t-elle un pic soudain d’utilisation des requêtes ?

Un pic soudain d’utilisation des requêtes après un déploiement est souvent causé par un grand nombre d’erreurs générées par votre application. Les erreurs comptent comme des requêtes dans AppSignal. Si le throughput d’erreurs affiché dans votre dashboard semble bien inférieur à l’augmentation du nombre de requêtes, il se peut que vous utilisiez une version plus ancienne de l’intégration Elixir AppSignal. Dans les versions plus anciennes, seules les erreurs échantillonnées apparaissent dans les métriques de throughput d’erreurs, mais toutes les requêtes d’erreur comptent dans votre utilisation totale des requêtes. Cet écart fait paraître le pic plus important que ne le suggère le nombre d’erreurs. Pour résoudre cet écart, mettez à jour le package Elixir appsignal vers la dernière version. Après la mise à jour, les métriques de throughput d’erreurs reflètent le nombre complet, correspondant à ce qu’AppSignal enregistre pour la facturation. Pour trouver les erreurs à l’origine du pic, allez dans Errors et filtrez par date de déploiement. Consultez le guide d’installation Elixir pour les instructions de mise à jour.

Pourquoi mes métriques personnalisées sont-elles abandonnées ?

AppSignal applique une limite stricte au nombre de combinaisons uniques de tags de métrique qu’il stocke par minute. Lorsque votre application dépasse cette limite, certaines métriques sont abandonnées selon la logique de priorisation d’AppSignal. La cause la plus fréquente est l’utilisation de valeurs à forte cardinalité comme tags de métrique — par exemple des identifiants d’utilisateur, de commande ou de requête. Chaque valeur de tag unique crée une série de métrique distincte, et un grand nombre d’utilisateurs ou de commandes peut épuiser très rapidement la limite par minute. Pour éviter que des métriques soient abandonnées, gardez des tags à faible cardinalité : utilisez des valeurs issues d’un ensemble restreint et fixe, comme le plan tarifaire, la région ou l’environnement. Les données à forte cardinalité par entité (par exemple, le suivi d’une métrique par utilisateur) ne conviennent pas au système de tags de métrique d’AppSignal. L’interface devient également inutilisable lorsqu’elle tente d’afficher des milliers de lignes sur un seul graphique. Consultez le guide sur les métriques personnalisées pour des conseils sur le tagging et la conception des métriques.

Pourquoi les requêtes ayant expiré n’apparaissent-elles pas dans les traces de performance ?

AppSignal stocke les traces de performance de manière sélective : pour chaque action et pour chaque minute donnée, il conserve les requêtes les plus lentes ainsi que celles contenant une erreur. Il ne stocke pas chaque requête. Lorsqu’une requête expire et déclenche une exception de timeout (par exemple Rack::Timeout::RequestTimeoutException), AppSignal l’enregistre comme une trace d’erreur, et non comme une trace de performance. La requête apparaît donc dans Errors, pas dans Performance, et n’est incluse ni dans la chronologie de performance ni dans la liste des requêtes lentes. Si vous souhaitez que les requêtes ayant expiré apparaissent comme des traces de performance plutôt que comme des traces d’erreur, ajoutez la classe d’exception de timeout à votre configuration ignore_errors. AppSignal cesse alors de traiter ces requêtes comme des erreurs et, si elles sont la requête la plus lente pour cette action durant cette minute, elles sont stockées comme traces de performance. Consultez le guide ignore errors pour savoir comment configurer ignore_errors.

Comment supprimer des traces pour retirer des données personnelles d’AppSignal ?

Pour supprimer toutes les traces de performance et d’erreur d’une application — par exemple pour retirer des données personnelles capturées par inadvertance dans des paramètres de requête — allez sur la page Settings de l’application et faites défiler jusqu’à la section Delete samples. Sélectionner cette option supprime toutes les traces stockées pour l’application. Après avoir supprimé les traces, déployez un correctif pour arrêter l’envoi des données personnelles. Consultez le guide de filtrage des paramètres et le guide de filtrage des données de session pour savoir comment empêcher les données sensibles d’atteindre AppSignal.

Logging

Comment ajouter des attributs de log comme colonnes dans la vue des logs ?

AppSignal stocke les métadonnées de log — par exemple request_id ou des champs personnalisés définis par votre logger — comme attributs de log. Ils s’affichent lorsque vous développez une ligne de log, mais vous pouvez aussi les faire apparaître comme colonnes persistantes dans le tableau des logs. Pour ajouter un attribut comme colonne, sélectionnez le menu à trois points (⋯) en haut à droite du tableau des logs. Choisissez l’attribut que vous souhaitez afficher, puis enregistrez la vue. La sélection des colonnes est enregistrée par vue, elle persiste donc d’une session à l’autre. Consultez le guide de gestion des logs pour en savoir plus sur l’utilisation des attributs de log et le filtrage.

⌘I

​Sommaire

​Premiers pas

​J’ai besoin d’aide pour démarrer. Où commencer ?

​Bibliothèques AppSignal

​Quels langages de programmation AppSignal prend-il en charge ?

​Filtrer les données

​Comment ignorer les actions dans mon application ?

​Comment ignorer les erreurs dans mon application ?

​Comment filtrer les données envoyées à AppSignal ?

​Quelle syntaxe regex ignore_logs prend-il en charge ?

​Pourquoi les requêtes d’Uptime monitoring comptent-elles dans mon budget, et comment les exclure ?

​Comment ignorer un message d’erreur spécifique dans le front-end JavaScript ?

​Comment supprimer les logs envoyés par appsignal-wrap ?

​Comment acheminer le trafic de l’agent AppSignal via un proxy HTTP ?

​Comment ajouter une instrumentation supplémentaire à mon application ?

​Quelle est la différence entre setRootName et setName ?

​Comment exécuter plusieurs applications sur un même hôte ?

​Quels systèmes d’exploitation AppSignal prend-il en charge ?

​Comment déboguer un problème avec l’intégration AppSignal ?

​AppSignal prend-il en charge Windows ?

​Pourquoi l’installation de la gem AppSignal Ruby échoue-t-elle avec une erreur JSON::Fragment ?

​Comment configurer AppSignal dans une application Hanami ?

​Pourquoi les erreurs dans Phoenix LiveComponent ne sont-elles pas capturées par AppSignal ?

​Compte utilisateur

​Puis-je envoyer des notifications par e-mail à un membre spécifique de l’équipe ?

​Comment activer l’authentification à deux facteurs (2FA) pour l’application AppSignal ?

​Pourquoi mes codes d’authentification à deux facteurs (2FA) ne fonctionnent-ils pas ?

​Comment réenregistrer mon appareil d’authentification à deux facteurs ?

​Quelles adresses IP AppSignal utilise-t-il ?

​Erreurs et performances

​Comment voir le nombre d’erreurs par namespace ?

​Pendant combien de temps les données d’Uptime monitoring sont-elles conservées ?

​Comment trouver la cause des requêtes API lentes ?

​Comment modifier la stratégie de regroupement des erreurs front-end ?

​Comment rechercher des erreurs par message ?

​Comment recevoir les notifications d’anomalie via webhook ?

​Pourquoi mon application Elixir affiche-t-elle un pic soudain d’utilisation des requêtes ?

​Pourquoi mes métriques personnalisées sont-elles abandonnées ?

​Pourquoi les requêtes ayant expiré n’apparaissent-elles pas dans les traces de performance ?

​Comment supprimer des traces pour retirer des données personnelles d’AppSignal ?

​Logging

​Comment ajouter des attributs de log comme colonnes dans la vue des logs ?