La liste suivante inclut toutes les options de configuration avec le nom de la variable d’environnement et le nom de la clé dans le fichier de configuration.Pour plus d’informations sur la façon de configurer AppSignal avec un fichier de configuration ou des variables d’environnement système, consultez notre rubrique Configuration.
Note : Lorsque la variable d’environnement APPSIGNAL_PUSH_API_KEY
est définie, cela passe par défaut à true. Cela peut être remplacé
en définissant la variable d’environnement système APPSIGNAL_ACTIVE sur false :
APPSIGNAL_ACTIVE=false.
Configurez AppSignal pour qu’il soit actif ou non pour un environnement donné. Le plus souvent utilisé dans la configuration par fichier par environnement.
L’environnement de l’application à signaler à AppSignal. Cette option de configuration sera automatiquement détectée dans les applications Rails. Pour les applications Rails, la variable RAILS_ENV est utilisée pour détecter l’environnement. Pour les applications utilisant d’autres frameworks ou aucun, la variable d’environnement RACK_ENV est utilisée.Pour remplacer cette détection automatique, définissez la variable d’environnement APPSIGNAL_APP_ENV.
Shell
export APPSIGNAL_APP_ENV=stagingrackup
Cette option sera utilisée pour charger la configuration à partir des fichiers de configuration dans lesquels la configuration d’AppSignal est stockée.L’option de variable d’environnement est couramment utilisée sur les plateformes où les applications s’exécutent par défaut dans l’environnement production, telles que Heroku. Ce paramètre permet de remplacer pour définir l’environnement sur staging, par exemple.
Shell
heroku config:set APPSIGNAL_APP_ENV=staging
Si l’environnement est défini à l’aide de l’assistant Appsignal.configure, il remplacera la variable d’environnement APPSIGNAL_APP_ENV.
Note : Modifier le nom ou l’environnement d’une application existante
créera une nouvelle application sur AppSignal.com.
Note : Cette option de configuration n’a pas d’équivalent en tant que clé de fichier de configuration. Pour définir
l’environnement à l’initialisation d’AppSignal, vous devrez initialiser la
configuration
manuellement.
Environnements personnalisés dans le fichier de configuration
Il n’existe pas de clé env disponible dans le fichier config/appsignal.yml. Si vous souhaitez
définir dynamiquement le nom de l’environnement pour une application dans le fichier de configuration, il est
possible de personnaliser votre fichier de configuration pour utiliser l’environnement afin de créer un
environnement.
Si vous utilisez une autre variable d’environnement que APPSIGNAL_APP_ENV, assurez-vous que cela correspond à la valeur de l’un des noms de variables d’environnement détectés automatiquement (RAILS_ENV et RACK_ENV) ou à la valeur donnée à Appsignal.configure.
Note : Modifier le nom ou l’environnement d’une application existante
créera une nouvelle application sur AppSignal.com.
Nom de votre application tel qu’il doit être affiché sur AppSignal.com. Si vous utilisez Ruby on Rails, le gem détectera automatiquement le nom et vous pouvez laisser ce champ vide. Pour les autres frameworks, le définir est obligatoire.
Remarque : Modifier le nom ou l’environnement d’une
application existante créera une nouvelle application sur AppSignal.com.
La clé d’authentification au niveau de l’organisation pour s’authentifier auprès de notre Push API.En savoir plus sur la clé Push API d’AppSignal.
Remarque : Lorsque la variable d’environnement système
APPSIGNAL_PUSH_API_KEY est définie, l’option
active prendra par défaut la valeur true au lieu de
false. Cela signifie qu’AppSignal sera considéré comme actif pour
l’environnement chargé même si active est défini sur false dans le
fichier de configuration. Pour plus d’informations, consultez l’option
active.
Configurez le signalement des erreurs qui se produisent dans les jobs Active Job. Cette option permet de désactiver le signalement des erreurs pour les jobs Active Job, afin de permettre l’ajout d’un signalement d’erreur personnalisé.Valeurs acceptées :
all : Signale toutes les erreurs pour chaque exécution de jobs, y compris les nouvelles tentatives.
discard : Signale les erreurs lorsque le job est abandonné en raison de l’erreur. Utilisez cette option pour ne signaler les erreurs que lorsque toutes les nouvelles tentatives du job ont été épuisées.
none : Ne signale aucune erreur pour les jobs, y compris les nouvelles tentatives.
Note : L’option discard ne fonctionne que sur Active Job 7.1 et plus récent. Sur
les versions inférieures, discard est lu comme all.
Une adresse IPv4 valide que l’agent AppSignal utilise comme liaison pour ses serveurs TCP et UDP. Utilisez une adresse spécifique si vous souhaitez que l’agent n’écoute que les requêtes adressées à cette adresse. Définissez cette option sur 0.0.0.0 pour autoriser la réception de requêtes depuis des hôtes utilisant n’importe quelle adresse IP. Par défaut, il n’écoute que les requêtes provenant du même hôte. Cette option s’applique à tous les serveurs de l’agent (StatsD, OpenTelemetry et NGINX).
Configurez le chemin du fichier de certificat SSL. Par défaut, cela pointe vers le fichier cacert.pem fourni par AppSignal dans le gem lui-même.Utilisez cette option pour pointer vers un autre fichier de certificat s’il y a un problème de connexion à notre API.
Remarque : Le chemin spécifié ne peut pas contenir d’abstractions de
système de fichiers spécifiques au système d’exploitation, telles que le
symbole de répertoire personnel ~ pour les systèmes *NIX. Cela sera
considéré comme un chemin mal formé.
La capacité CPU disponible de l’hôte, en nombre de CPU. Cela est utilisé pour calculer le pourcentage d’utilisation du CPU dans les métriques de l’hôte. S’il n’est pas défini, l’agent tentera de le détecter automatiquement à partir des cgroups.Le nombre de CPU peut être une fraction, par exemple 0.5.
Avertissement : Cette option de configuration est dépréciée dans le gem
Ruby 3.0.16. Veuillez utiliser l’option log_level à la
place pour le gem Ruby 3.0.16 et versions ultérieures.
Activez la journalisation de débogage. Cela n’est généralement nécessaire qu’à la demande du support. Avec cette option activée, AppSignal enregistrera beaucoup plus d’informations sur les décisions prises lors de la collecte de métriques et lors de l’envoi de données aux serveurs AppSignal.com.L’activation de la journalisation de débogage pourrait avoir un léger impact sur l’utilisation du disque et les E/S, en particulier sur les sites à fort trafic. La surcharge CPU est minimale lorsque l’option de débogage est activée.
Cette option définit le niveau de gravité du journal interne d’AppSignal.
Cette option de configuration n’affecte pas la fonctionnalité de
journalisation.
Tags par défaut qui seront ajoutés à toutes les transactions. Les tags spécifiques à une transaction définis avec Appsignal.add_tags remplaceront les tags par défaut ayant la même clé.
Les valeurs des tags doivent être de type String, Symbol, Integer ou Boolean. Les tags avec d’autres types de valeurs seront ignorés.En savoir plus sur le tagging.
Configurez les serveurs DNS à utiliser par l’agent AppSignal.
Appsignal.configure do |config| config.dns_servers = ["8.8.8.8", "8.8.4.4"]end
Si vous êtes affecté par nos délais d’attente DNS, essayez de définir un serveur DNS manuellement à l’aide de cette option qui n’utilise pas plus de 4 points dans le nom du serveur.
Valeurs non acceptables : foo, my.awesome.custom.local.dns.server.
Si le serveur DNS ne peut pas être atteint, l’agent se rabattra sur la configuration DNS de l’hôte et affichera un message dans le fichier appsignal.log : A problem occurred while setting DNS servers.
Active l’intégration de rapport d’événements structurésActiveSupport::EventReporter.Lorsqu’elle est activée, l’intégration AppSignal s’abonne aux événements émis par ActiveSupport::EventReporter et les rapporte sous forme de logs.
Configurez la manière dont AppSignal s’arrête lorsque l’application s’arrête. Cela déterminera s’il appelle automatiquement Appsignal.stop, qui videra les données vers l’extension et l’agent.Cette option a trois valeurs possibles :
always : Toujours appeler Appsignal.stop lorsque le programme se termine. Sur les conteneurs (Docker), c’est automatiquement défini sur cette valeur.
never : Ne jamais appeler Appsignal.stop lorsque le programme se termine. La valeur par défaut lorsque le programme ne s’exécute pas sur un conteneur (Docker).
on_error : Appeler Appsignal.stop lorsque le programme se termine avec une erreur.
Définissez sur true pour signaler la dernière erreur ayant provoqué l’arrêt du processus. L’erreur signalée est généralement l’erreur qui fait planter le processus. Si le gem Ruby a déjà signalé l’erreur, elle ne sera pas signalée à nouveau.Les erreurs signalées via ce mécanisme sont ajoutées au namespace “unhandled”.Ajoutez ce code au début de l’application sur les conteneurs à courte durée de vie et les fonctions serverless pour vous assurer que l’erreur est vidée avant l’arrêt du système.
Active le système expérimental de capture d’erreurs front-end. Cela ajoutera une route à votre application sur /appsignal_error_catcher qui peut être utilisée pour capturer les erreurs JavaScript et les envoyer à AppSignal. Vous pouvez configurer cette route avec frontend_error_catching_path.
Définissez cette option sur false pour désactiver l’instrumentation du timer global GVL. Cette option de configuration n’a aucun effet si GVLTools n’est pas installé.
Définissez cette option sur false pour désactiver l’instrumentation des threads en attente GVL. Cette option de configuration n’a aucun effet si GVLTools n’est pas installé.
Définissez cette option sur false pour désactiver la collecte de métriques de l’hôte.Sur Heroku et Dokku, les métriques de l’hôte sont désactivées par défaut. Cela est fait car ces systèmes signaleront des métriques inexactes depuis l’intérieur des conteneurs. La collecte des métriques de l’hôte sur ces systèmes ne peut pas être activée. Pour Heroku, utilisez plutôt le drain de logs Heroku.
Définissez sur true pour activer le serveur de métriques NGINX. Consultez la documentation des métriques NGINX pour plus de détails.Lorsqu’il est activé, l’agent AppSignal écoutera un serveur lié à localhost sur le port 27649. Si vous exécutez plusieurs applications instrumentées par AppSignal sur le même serveur, cette option de configuration ne peut être activée que dans l’une d’entre elles.
Active le serveur StatsD dans l’agent AppSignal.Lorsqu’il est activé, l’agent AppSignal écoutera un serveur lié à localhost sur le port 8125. Si vous exécutez plusieurs applications instrumentées par AppSignal sur le même serveur, cette option de configuration ne peut être activée que dans l’une d’entre elles.
Si ceci est défini sur true, le répertoire de travail AppSignal créé est accessible à tous les utilisateurs (permissions Unix 0666). Cela est souvent nécessaire car les processus pour la même application s’exécutent sous un utilisateur différent. Définissez sur false pour désactiver ce comportement (permissions Unix 0644).
Le gem Ruby AppSignal stocke par défaut des métadonnées sur les requêtes et les tâches en arrière-plan dans les échantillons, comme le chemin de la requête, la méthode de la requête, l’identifiant de la requête, la file d’attente en arrière-plan, l’identifiant de la tâche et le nombre de nouvelles tentatives de la tâche. Ces valeurs de métadonnées seront affichées dans la zone des tags. Si l’une de ces valeurs de métadonnées contient des informations personnellement identifiables (PII) ou d’autres données sensibles, utilisez cette option de configuration pour filtrer les métadonnées par clé.Définissez l’option filter_metadata sur une liste de clés de métadonnées à filtrer. Vous pouvez configurer cela avec une liste de clés dans le fichier de configuration. Une fois filtrées, les métadonnées ne seront pas visibles dans l’interface utilisateur d’AppSignal.
Appsignal.configure do |config| config.filter_metadata += ["path", "request_id"]end
Liste de clés de paramètres qui doivent être ignorées à l’aide du filtrage AppSignal. Leurs valeurs seront remplacées par [FILTERED] lors de la transmission à AppSignal. Vous pouvez configurer cela avec une liste de clés dans le fichier de configuration.
Appsignal.configure do |config| config.filter_parameters += ["password", "email", "api_token", "token"]end
Liste de clés de données de session qui doivent être ignorées à l’aide du filtrage AppSignal. Leurs valeurs seront remplacées par [FILTERED] lors de la transmission à AppSignal. Vous pouvez configurer cela avec une liste de clés dans le fichier de configuration.
Appsignal.configure do |config| config.filter_session_data += ["name", "email", "api_token", "token"]end
Regroupez les hôtes par rôle et générez des métriques basées sur ce rôle. Une de ces métriques est la métrique de compteur reporting_hosts. Un bon rôle indique quel est le rôle principal du serveur, comme “webserver”, “processor”, “api”, “database”, “loadbalancer”, etc.
Cela remplace le nom d’hôte du serveur. Utile lorsque vous ne pouvez pas définir un nom d’hôte personnalisé ou lorsqu’un identifiant peu descriptif est généré pour vous sur des services d’hébergement.
Avec cette option de configuration, vous pouvez spécifier une liste d’actions qui seront ignorées par AppSignal. Tout ce qui se passe, y compris les exceptions, ne sera pas transmis à AppSignal. Cela peut être utile pour ignorer les points de terminaison de vérification de l’état ou d’autres actions que vous ne souhaitez pas surveiller.En savoir plus sur l’ignorance des actions.
Liste des classes d’erreurs qui seront ignorées. Toute exception levée avec cette classe d’erreur ne sera pas transmise à AppSignal.En savoir plus sur l’ignorance des erreurs.
Liste de messages de log qui seront ignorés. Tout message de log contenant l’un des éléments de la liste ne sera pas transmis à AppSignal. Un petit sous-ensemble de la syntaxe regex est pris en charge ; pour en savoir plus, consultez notre guide Ignorer les logs.
Liste de namespaces qui seront ignorés. Toute erreur levée ou requête lente qui se produit dans ce namespace ne sera pas envoyée à AppSignal.En savoir plus sur les namespaces.
Cette option configure le logger que la fonctionnalité de journalisation
interne d’AppSignal utilisera et n’affecte pas la fonctionnalité de
journalisation.Remarque : L’agent AppSignal,
qui est utilisé par l’intégration, écrira toujours dans le fichier “appsignal.log”.
Sélectionnez le logger que l’intégration AppSignal utilisera. Les valeurs acceptées sont
file et stdout. Voir aussi la configuration log_path.
file (par défaut)
Écrire tous les logs AppSignal dans le système de fichiers.
Imprimer les logs AppSignal dans la STDOUT du processus parent au lieu d’un fichier.
Utile avec des solutions d’hébergement comme les systèmes de conteneurs et Heroku.
Définit le niveau de gravité du logger interne d’AppSignal. S’il est configuré sur “info”, il enregistrera tous les messages d’erreur, d’avertissement et d’information, mais n’enregistrera pas les messages de débogage.Le régler sur les niveaux “debug” ou “trace” n’est généralement nécessaire qu’à la demande du support. Définir le niveau sur “debug”/“trace” pourrait avoir un léger impact sur l’utilisation du disque et les E/S, en particulier sur les sites à fort trafic. La surcharge CPU est minimale lorsque l’option de débogage est activée.Valeurs acceptées :
Cette option configure l’emplacement du fichier de journalisation interne
d’AppSignal et n’affecte pas la fonctionnalité de journalisation. Remarque : Le chemin spécifié ne peut pas contenir d’abstractions de
système de fichiers spécifiques au système d’exploitation, telles que le
symbole de répertoire personnel ~ pour les systèmes *NIX. Cela sera
considéré comme un chemin mal formé.
Remplacez l’emplacement du chemin (répertoire) où le fichier appsignal.log peut
être écrit.
Configurez le port sur lequel le serveur de métriques NGINX est exposé.Lorsque AppSignal reçoit des métriques NGINX, il écoute sur un serveur lié à localhost, par défaut sur le port 27649. Si vous exécutez plusieurs applications instrumentées par AppSignal sur le même serveur avec les métriques NGINX activées, utilisez cette option pour configurer chaque application à écouter sur un port différent.
L’option de configuration request_headers contient une liste d’en-têtes de requête HTTP qui sont lus et stockés par le gem AppSignal pour Ruby.Cette option de configuration request_headers est une liste d’autorisation, ce qui signifie qu’elle ne prendra en compte que les en-têtes spécifiés par cette option. Si cette option de configuration n’est pas définie, la valeur par défaut d’AppSignal sera utilisée.
Appsignal.configure do |config| # Add a request header config.request_headers << "PATH_INFO" # Remove a request header config.request_headers.delete("PATH_INFO")end
Notez qu’AppSignal lit les en-têtes depuis votre application et qu’ils peuvent ne pas correspondre exactement à ce qui est envoyé dans le navigateur/client. Dans les applications Rack (Rails, Sinatra, etc.), tous les en-têtes personnalisés sont préfixés par la chaîne HTTP_, tous les noms d’en-têtes sont en majuscules et les tirets (-) sont remplacés par des tirets bas (_).Par exemple, l’en-tête X-Hub-Signature peut être accédé par votre application et par AppSignal avec le nom HTTP_X_HUB_SIGNATURE.Pour configurer AppSignal de manière à ne stocker aucun en-tête de requête HTTP dans les transactions AppSignal, configurez l’option avec un tableau vide.
Appsignal.configure do |config| config.request_headers = []end
Définissez la révision de l’application pour signaler la version actuellement en cours d’exécution de votre application. AppSignal créera un marqueur de déploiement lorsque cette valeur change et étiquettera toutes les données entrantes avec la révision actuelle.Lorsque votre application est déployée à l’aide de Kamal, ou lorsqu’elle est déployée sur Render, ou lorsqu’elle est déployée sur Heroku et que la fonctionnalité Heroku Labs: Dyno Metadata est activée, l’intégration AppSignal détectera automatiquement le commit Git du déploiement actuel et l’utilisera comme révision.Vous pouvez écraser les révisions détectées automatiquement dans Heroku, Render ou Kamal en définissant manuellement l’option de configuration revision sur une valeur personnalisée.Pour en savoir plus sur les marqueurs de déploiement, consultez le sujet sur les marqueurs de déploiement.
AppSignal s’attend à être exécuté sur la même machine entre les différents déploiements. Définissez cette clé sur true si l’application s’exécute dans un conteneur, par exemple avec Docker.Les versions plus récentes de l’intégration AppSignal détectent automatiquement leur environnement de conteneur, aucune configuration manuelle n’est donc nécessaire. Si vous rencontrez des problèmes avec la détection automatique, veuillez contacter le support.Cette option est automatiquement définie sur true sur Heroku.
Envoie des métadonnées d’environnement concernant l’application.Pour plus d’informations, veuillez consulter la documentation sur les métadonnées d’environnement.
Indique s’il faut ignorer l’envoi des paramètres de requête à AppSignal.Pour plus d’informations, veuillez consulter la documentation sur send_params dans le filtrage des paramètres de requête.
Définissez cette option sur false pour ne pas envoyer de données de session avec les traces d’exception et les échantillons de problèmes de performance.Pour plus d’informations, veuillez consulter la documentation sur le filtrage des données de session de requête.
Configurez le signalement des erreurs qui se produisent dans les jobs Sidekiq.Valeurs acceptées :
all : Signale toutes les erreurs pour chaque exécution de jobs, y compris les nouvelles tentatives.
discard : Signale les erreurs lorsque le job est rejeté en raison de l’erreur. Utilisez cette option pour signaler les erreurs uniquement lorsque toutes les nouvelles tentatives du job ont été épuisées.
none : Ne signale aucune erreur pour les jobs, y compris les nouvelles tentatives. Utile pour le signalement d’erreurs personnalisé.
Remarque : L’option discard ne fonctionne que sur Sidekiq 5.1 et versions ultérieures. Sur les versions
antérieures, discard est interprété comme all.
Avertissement : Cette option de configuration est déconseillée dans le gem Ruby 3.0.20. Veuillez utiliser
l’option send_session_data à la place pour les versions plus récentes
du gem Ruby.
Définissez cette option pour configurer le port du serveur HTTP StatsD du processus d’agent AppSignal. Configurez ce port si un autre processus est déjà en cours d’exécution sur la machine et utilise également ce port, afin d’éviter les conflits.
Avertissement : Cette option de configuration est déconseillée dans le gem Ruby 3.0.16. Veuillez utiliser
l’option log_level à la place pour le gem Ruby 3.0.16 et
versions ultérieures.
Active le mode débogage des transactions. Cela active une journalisation très détaillée des transactions et des événements, ce qui est utile lors du développement d’intégrations ou lorsque les événements ne sont pas suivis comme prévu. Le journal n’est écrit que si l’option générale debug est également activée.
Cette option définit le niveau de gravité du journaliseur interne d’AppSignal et n’affecte
pas la fonctionnalité de journalisation.
Avertissement : Cette option de configuration est déconseillée dans le gem Ruby 2.7.0. Veuillez utiliser
l’option working_directory_path à la place
pour le gem Ruby 2.7.0 et versions ultérieures.
Remplace l’emplacement où AppSignal pour Ruby crée un répertoire de travail.
Consultez
working_directory_path
pour connaître le comportement applicable. Cette option de configuration ajoute /appsignal au
chemin spécifié, alors que
working_directory_path
ne le fait pas.
Remarque : Le chemin spécifié ne peut pas contenir d’abstractions du système de fichiers
spécifiques au système d’exploitation, telles que le symbole du répertoire personnel ~ pour les systèmes *NIX. Cela sera
considéré comme un chemin mal formé.
Remplace l’emplacement où AppSignal pour Ruby peut stocker des fichiers temporaires. Utilisez cette option si l’emplacement par défaut ne convient pas. Consultez notre page comment AppSignal fonctionne pour plus d’informations sur le rôle de ce répertoire de travail.Si vous exécutez plusieurs applications utilisant AppSignal sur le même serveur, utilisez cette option de configuration pour sélectionner des répertoires de travail différents pour chaque instance AppSignal, sinon les deux instances pourraient entrer en conflit l’une avec l’autre. Pour plus d’informations sur ce scénario, consultez notre documentation exécution de plusieurs applications sur un seul hôte.
Appsignal.configure do |config| config.working_directory_path = "/tmp/project_1/"end
Remarque : Le chemin spécifié ne peut pas contenir d’abstractions du système de fichiers
spécifiques au système d’exploitation, telles que le symbole du répertoire personnel ~ pour les systèmes *NIX. Cela sera
considéré comme un chemin mal formé.
