Skip to main content
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 section Configuration.

Options disponibles

active

Description

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.

APPSIGNAL_APP_ENV

Description

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
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
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.
YAML
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.

name

Description

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.

push_api_key

Description

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.

activejob_report_errors

Description

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.

bind_address

Description

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).

ca_file_path

Description

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é.

cpu_count

Description

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.

debug

Description

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.

default_tags

Description

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é.
Lorsque vous utilisez la variable d’environnement, fournissez une liste de paires clé-valeur séparées par des virgules.
Shell
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.

dns_servers

Description

Configurez les serveurs DNS à utiliser par l’agent AppSignal.
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 acceptables : 8.8.8.8, my.custom.local.server.
  • 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.

enable_active_support_event_log_reporter

Description

Active l’intégration de rapport d’événements structurés ActiveSupport::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.

enable_allocation_tracking

Description

Définissez cette option sur false pour désactiver le suivi du nombre d’objets alloués en Ruby.

enable_at_exit_hook

Description

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.
Pour plus d’informations, consultez notre page sur l’instrumentation pour les scripts et les tâches en arrière-plan.

enable_at_exit_reporter

Description

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.
Ruby

enable_frontend_error_catching

Description

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.

enable_gvl_global_timer

Description

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é.

enable_gvl_waiting_threads

Description

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é.

enable_host_metrics

Description

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.

enable_job_enqueue_instrumentation

Description

Active ou désactive l’enregistrement d’un événement lorsqu’un background job est mis en file d’attente. Lorsque cette option est activée, mettre en file d’attente un job depuis une transaction active enregistre un événement de mise en file d’attente dans la chronologie des événements de cette transaction. Cela s’applique à l’instrumentation de mise en file d’attente de chaque intégration de background job : Définir cette option sur false empêche l’enregistrement de ces événements de mise en file d’attente, sans affecter l’instrumentation des jobs eux-mêmes. Activé par défaut.

enable_minutely_probes

Description

Active le système de sondes à la minute.

enable_nginx_metrics

Description

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.

enable_rails_error_reporter

Description

Définissez sur false pour désactiver l’abonné au reporter d’erreurs Rails. Consultez la documentation Rails pour plus de détails.

enable_rake_performance_instrumentation

Description

Activez l’instrumentation des performances pour les tâches Rake. Par défaut, l’instrumentation Rake ne rapporte que les erreurs.

enable_statsd

Description

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.

endpoint

Description

Configurez le point de terminaison pour envoyer les données à AppSignal. Ce paramètre n’aura pas besoin d’être modifié.

files_world_accessible

Description

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).

filter_metadata

Description

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.

filter_parameters

Description

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.
En savoir plus sur le filtrage des paramètres.

filter_session_data

Description

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.
En savoir plus sur le filtrage des données de session.

host_role

Description

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.

hostname

Description

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.

http_proxy

Description

Si vous avez besoin que l’agent se connecte à Internet via un proxy, définissez l’URL complète du proxy dans cette clé de configuration.

ignore_actions

Description

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.

ignore_errors

Description

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.

ignore_logs

Description

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.

ignore_namespaces

Description

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.

instrument_active_job

Description

Active ou désactive l’instrumentation pour Active Job. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

instrument_code_ownership

Description

Indique s’il faut instrumenter automatiquement le gem CodeOwnership, peut être true ou false.

instrument_delayed_job

Description

Active ou désactive l’instrumentation pour Delayed::Job. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

instrument_excon

Description

Active ou désactive l’instrumentation pour Excon. Définir cette option sur false désactive entièrement l’intégration. Activé par défaut.

instrument_faraday

Description

Active ou désactive l’instrumentation pour la gem Faraday. Définir cette option sur false désactive entièrement l’intégration. Activé par défaut.

instrument_http_rb

Description

Activez ou désactivez l’instrumentation pour le gem Ruby http.rb. Activé par défaut.

instrument_mongo

Description

Active ou désactive l’instrumentation MongoDB, qui couvre le Mongo Ruby Driver et Mongoid. Définir cette option sur false désactive entièrement l’intégration. Activé par défaut.

instrument_net_http

Description

Indique s’il faut ajouter une instrumentation pour les appels net/http, peut être true ou false.

instrument_ownership

Description

Indique s’il faut instrumenter automatiquement le gem Ownership, peut être true ou false.

instrument_que

Description

Active ou désactive l’instrumentation pour Que. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

instrument_redis

Description

Indique s’il faut activer l’instrumentation pour les requêtes Redis à l’aide du gem Redis, peut être true ou false.

instrument_resque

Description

Active ou désactive l’instrumentation pour Resque. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

instrument_sequel

Description

Indique s’il faut ajouter une instrumentation pour les requêtes sequel à l’aide de l’intégration du gem Sequel, peut être true ou false.

instrument_shoryuken

Description

Active ou désactive l’instrumentation pour Shoryuken. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

instrument_sidekiq

Description

Active ou désactive l’instrumentation pour Sidekiq. Définir cette option sur false désactive entièrement l’intégration, y compris l’instrumentation des jobs et l’instrumentation de mise en file d’attente. Activé par défaut.

log

Description

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.
  • stdout (par défaut sur Heroku)
    • 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.

log_level

Description

Cette option définit le niveau de gravité du logger interne d’AppSignal et n’affecte pas la fonctionnalité de journalisation.
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 :
  • error
  • warning
  • info
  • debug
  • trace

log_path

Description

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.

nginx_port

Description

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.

ownership_set_namespace

Description

Indique si l’instrumentation du gem Ownership doit définir le namespace d’un échantillon sur son propriétaire, peut être true ou false.

request_headers

Description

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.
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.

revision

Description

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.

running_in_container

Description

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.

send_environment_metadata

Description

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.

send_params

Description

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.

send_session_data

Description

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.

sidekiq_report_errors

Description

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.

skip_session_data

Description

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.

statsd_port

Description

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.

transaction_debug_mode

Description

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.

working_dir_path

Description

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é.

working_directory_path

Description

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.
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é.