Verfügbare Optionen
- Erforderliche Optionen
- Optionen
activejob_report_errorsbind_addressca_file_pathcollector_endpointcpu_countdebugdefault_tagsdns_serversenable_active_support_event_log_reporterenable_allocation_trackingenable_at_exit_hookenable_at_exit_reporterenable_frontend_error_catchingenable_gvl_global_timerenable_gvl_waiting_threadsenable_host_metricsenable_job_enqueue_instrumentationenable_minutely_probesenable_nginx_metricsenable_rails_error_reporterenable_rake_performance_instrumentationenable_statsdendpointfiles_world_accessiblefilter_attributesfilter_function_parametersfilter_metadatafilter_parametersfilter_request_payloadfilter_request_query_parametersfilter_session_datahost_rolehostnamehttp_proxyignore_actionsignore_errorsignore_logsignore_namespacesinstrument_active_jobinstrument_code_ownershipinstrument_delayed_jobinstrument_exconinstrument_faradayinstrument_http_rbinstrument_mongoinstrument_net_httpinstrument_ownershipinstrument_queinstrument_redisinstrument_resqueinstrument_sequelinstrument_shoryukeninstrument_sidekiqkeep_request_environmentkeep_request_headersloglog_levellog_pathlogging_endpointnginx_portownership_set_namespacerequest_headersresponse_headersrevisionrunning_in_containersend_environment_metadatasend_function_parameterssend_paramssend_request_payloadsend_request_query_parameterssend_session_dataservice_namesidekiq_report_errorsskip_session_datastatsd_porttransaction_debug_modeworking_dir_pathworking_directory_path
active
Beschreibung
Hinweis: Wenn die Umgebungsvariable
APPSIGNAL_PUSH_API_KEY gesetzt ist, ist der Standardwert
true. Dies kann überschrieben werden, indem die System-Umgebungsvariable
APPSIGNAL_ACTIVE auf false gesetzt wird: APPSIGNAL_ACTIVE=false.APPSIGNAL_APP_ENV
Beschreibung
Die Umgebung der App, die an AppSignal gemeldet werden soll. Diese Konfigurationsoption wird in Rails-Apps automatisch erkannt. Bei Rails-Apps wird die VariableRAILS_ENV zur Erkennung der Umgebung verwendet. Bei Apps, die andere Frameworks oder gar keines verwenden, wird die Umgebungsvariable RACK_ENV verwendet.
Um diese automatische Erkennung zu überschreiben, setzen Sie die Umgebungsvariable APPSIGNAL_APP_ENV.
Shell
production-Umgebung laufen, wie z. B. Heroku. Diese Einstellung ermöglicht es, die Umgebung beispielsweise auf staging zu setzen.
Shell
Appsignal.configure-Helfer gesetzt wird, überschreibt dies die Umgebungsvariable APPSIGNAL_APP_ENV.
Hinweis: Wenn Sie den Namen oder die Umgebung einer
bestehenden App ändern, wird auf AppSignal.com eine neue App erstellt.
Hinweis: Diese Konfigurationsoption hat keinen Entsprechung als
Konfigurationsdatei-Schlüssel. Um die Umgebung bei der
AppSignal-Initialisierung zu setzen, müssen Sie die Konfiguration manuell
initialisieren.
Benutzerdefinierte Umgebungen in der Konfigurationsdatei
In der Dateiconfig/appsignal.yml ist kein Schlüssel env verfügbar. Wenn Sie
den Umgebungsnamen für eine App dynamisch in der Konfigurationsdatei festlegen
möchten, können Sie Ihre Konfigurationsdatei so anpassen, dass die Umgebung
verwendet wird, um eine Umgebung zu erstellen.
YAML
APPSIGNAL_APP_ENV verwenden, stellen Sie sicher, dass der Wert mit einem der automatisch erkannten Umgebungsvariablennamen (RAILS_ENV und RACK_ENV) übereinstimmt oder mit dem an Appsignal.configure übergebenen Wert.
Hinweis: Wenn Sie den Namen oder die Umgebung einer
bestehenden App ändern, wird auf AppSignal.com eine neue App erstellt.
name
Beschreibung
Name Ihrer Anwendung, wie er auf AppSignal.com angezeigt werden soll. Wenn Sie Ruby on Rails verwenden, erkennt das Gem den Namen automatisch und Sie können dies leer lassen. Für andere Frameworks ist das Setzen dieses Werts zwingend erforderlich.Hinweis: Das Ändern des Namens oder der Umgebung einer bestehenden App erstellt eine neue App auf AppSignal.com.
push_api_key
Beschreibung
Der Authentifizierungsschlüssel auf Organisationsebene zur Authentifizierung gegenüber unserer Push API. Lesen Sie mehr über den AppSignal Push API key.Hinweis: Wenn die Systemumgebungsvariable
APPSIGNAL_PUSH_API_KEY gesetzt ist, wird die Option active standardmäßig auf true statt auf false gesetzt. Das bedeutet, AppSignal wird für die geladene Umgebung als aktiv betrachtet, auch wenn active in der Konfigurationsdatei auf false gesetzt ist. Weitere Informationen finden Sie unter der Option active.activejob_report_errors
Beschreibung
Konfigurieren Sie das Melden von Fehlern, die in Active Job-Jobs auftreten. Diese Option ermöglicht es, die Fehlermeldung für Active Job-Jobs zu deaktivieren, um eine benutzerdefinierte Fehlermeldung hinzuzufügen. Akzeptierte Werte:all: Alle Fehler bei jeder Ausführung von Jobs melden, einschließlich Wiederholungen.discard: Fehler melden, wenn der Job aufgrund des Fehlers verworfen wird. Verwenden Sie diese Option, um Fehler nur dann zu melden, wenn alle Job-Wiederholungen erschöpft sind.none: Keine Fehler für Jobs melden, einschließlich Wiederholungen.
Hinweis: Die Option
discard funktioniert nur mit Active Job 7.1 und neuer.
Auf niedrigeren Versionen wird discard als all gelesen.bind_address
Beschreibung
Eine gültige IPv4-Adresse, die der AppSignal-Agent als Bindung für seine TCP- und UDP-Server verwendet. Verwenden Sie eine bestimmte Adresse, wenn der Agent nur Anfragen an diese Adresse abhören soll. Setzen Sie diese Option auf0.0.0.0, um Anfragen von Hosts unter jeder beliebigen IP-Adresse zuzulassen. Standardmäßig hört er nur auf Anfragen, die auf demselben Host gestellt werden. Diese Option wird auf alle Agent-Server angewendet (StatsD, OpenTelemetry und NGINX).
ca_file_path
Beschreibung
Konfigurieren Sie den Pfad der SSL-Zertifikatsdatei. Standardmäßig zeigt dies auf die von AppSignal mitgeliefertecacert.pem-Datei im Gem selbst.
Verwenden Sie diese Option, um auf eine andere Zertifikatsdatei zu verweisen, falls es Probleme bei der Verbindung mit unserer API gibt.
Hinweis: Der angegebene Pfad darf keine betriebssystemspezifischen Dateisystem-Abstraktionen enthalten, wie zum Beispiel das Homedir-Symbol
~ auf *NIX-Systemen. Dies wird als fehlerhafter Pfad gewertet.collector_endpoint
Beschreibung
Die Adresse eines extern bereitgestellten AppSignal Collectors. Wenn diese Option gesetzt ist, werden OpenTelemetry-Traces, -Metriken und -Logs an den Collector unter dieser Adresse gesendet.Dies ist eine experimentelle Konfigurationsoption.
Verteiltes Tracing ist
nur verfügbar, wenn Sie den gehosteten AppSignal Collector verwenden.
Gemfile Ihrer Anwendung hinzugefügt werden
müssen. Die erforderlichen Gems und Mindestversionen finden Sie in der
Collector-Konfigurationsanleitung. Bei älteren Ruby-Versionen
oder wenn die Gems fehlen oder zu alt sind, wird diese Option ignoriert.
cpu_count
Beschreibung
Die verfügbare CPU-Kapazität des Hosts, ausgedrückt als Anzahl der CPUs. Dies wird verwendet, um den CPU-Auslastungsprozentsatz in den Host-Metriken zu berechnen. Wenn nicht gesetzt, versucht der Agent, dies automatisch aus cgroups zu erkennen. Die Anzahl der CPUs kann ein Bruchwert sein, z. B.0.5.
debug
Beschreibung
Aktiviert das Debug-Logging. Dies wird in der Regel nur auf Anfrage des Supports benötigt. Mit dieser aktivierten Option protokolliert AppSignal deutlich mehr Informationen über Entscheidungen, die während der Metrikerfassung getroffen werden, sowie über das Senden von Daten an die AppSignal.com-Server. Das Aktivieren des Debug-Loggings kann sich leicht auf die Festplattennutzung und das IO auswirken, besonders auf stark frequentierten Seiten. Der CPU-Overhead ist mit aktivierter Debug-Option minimal.Diese Option legt die Schweregradstufe des internen Loggers von AppSignal fest. Diese Konfigurationsoption hat keinen Einfluss auf die Logging-Funktion.
default_tags
Beschreibung
Standard-Tags, die allen Transaktionen hinzugefügt werden. Transaktionsspezifische Tags, die mitAppsignal.add_tags gesetzt werden, überschreiben Standard-Tags mit demselben Schlüssel.
Shell
dns_servers
Beschreibung
Konfigurieren Sie DNS-Server, die der AppSignal-Agent verwenden soll.- Akzeptable Werte:
8.8.8.8,my.custom.local.server. - Nicht akzeptable Werte:
foo,my.awesome.custom.local.dns.server.
appsignal.log aus: A problem occurred while setting DNS servers.
enable_active_support_event_log_reporter
Beschreibung
Aktiviert die Integration für strukturiertes Event-Reporting vonActiveSupport::EventReporter.
Wenn aktiviert, abonniert die AppSignal-Integration die von ActiveSupport::EventReporter ausgegebenen Events und meldet sie als Logs.
enable_allocation_tracking
Beschreibung
Setzen Sie diese Option auffalse, um die Verfolgung der Anzahl der allokierten Objekte in Ruby zu deaktivieren.
enable_at_exit_hook
Beschreibung
Konfigurieren Sie, wie AppSignal heruntergefahren wird, wenn die Anwendung beendet wird. Dies bestimmt, obAppsignal.stop automatisch aufgerufen wird, wodurch die Daten an die Extension und den Agent geflusht werden.
Diese Option hat drei mögliche Werte:
always: RuftAppsignal.stopimmer auf, wenn das Programm beendet wird. Auf (Docker-)Containern wird dieser Wert automatisch gesetzt.never: RuftAppsignal.stopniemals auf, wenn das Programm beendet wird. Der Standardwert, wenn das Programm nicht in einem (Docker-)Container ausgeführt wird.on_error: RuftAppsignal.stopauf, wenn das Programm mit einem Fehler beendet wird.
enable_at_exit_reporter
Beschreibung
Auftrue setzen, um den letzten Fehler zu melden, der das Beenden des Prozesses verursacht hat. Der gemeldete Fehler ist in der Regel der Fehler, der den Prozess abstürzen lässt. Wenn das Ruby-Gem den Fehler bereits gemeldet hat, wird er nicht erneut gemeldet.
Über diesen Mechanismus gemeldete Fehler werden dem Namespace „unhandled“ hinzugefügt.
Fügen Sie diesen Code am Anfang der Anwendung in kurzlebigen Containern und serverlosen Funktionen ein, um sicherzustellen, dass der Fehler geflusht wird, bevor das System heruntergefahren wird.
Ruby
enable_frontend_error_catching
Beschreibung
Aktiviert das experimentelle Frontend-Fehlerabfangsystem. Dadurch wird Ihrer App eine Route unter/appsignal_error_catcher hinzugefügt, mit der JavaScript-Fehler abgefangen und an AppSignal gesendet werden können. Sie können diese Route mit frontend_error_catching_path konfigurieren.
enable_gvl_global_timer
Beschreibung
Setzen Sie diese Option auffalse, um die Instrumentierung des GVL Global Timers zu deaktivieren. Diese Konfigurationsoption hat keine Auswirkung, wenn GVLTools nicht installiert ist.
enable_gvl_waiting_threads
Beschreibung
Setzen Sie diese Option auffalse, um die Instrumentierung der wartenden GVL-Threads zu deaktivieren. Diese Konfigurationsoption hat keine Auswirkung, wenn GVLTools nicht installiert ist.
enable_host_metrics
Beschreibung
Setzen Sie diese Option auffalse, um die Erfassung von Host-Metriken zu deaktivieren.
Auf Heroku und Dokku sind Host-Metriken standardmäßig deaktiviert. Dies geschieht, weil diese Systeme ungenaue Metriken aus den Containern heraus melden. Die Erfassung von Host-Metriken auf diesen Systemen kann nicht aktiviert werden. Verwenden Sie für Heroku stattdessen den Heroku Log Drain.
enable_job_enqueue_instrumentation
Beschreibung
Aktiviert oder deaktiviert das Aufzeichnen eines events, wenn ein background job eingereiht wird. Wenn aktiviert, wird beim Einreihen eines Jobs innerhalb einer aktiven transaction ein enqueue-event in der event-timeline dieser transaction aufgezeichnet. Dies gilt für die enqueue-instrumentation jeder background-job-integration: Wenn Sie dies auffalse setzen, werden diese enqueue-events nicht mehr aufgezeichnet, ohne die instrumentation der Jobs selbst zu beeinflussen. Standardmäßig aktiviert.
enable_minutely_probes
Beschreibung
Aktiviert das System der minütlichen Probes.enable_nginx_metrics
Beschreibung
Auftrue setzen, um den NGINX-Metrik-Server zu aktivieren. Details finden Sie in der NGINX-Metrik-Dokumentation.
Wenn aktiviert, hört der AppSignal-Agent auf einem an localhost gebundenen Server auf Port 27649. Wenn Sie mehrere mit AppSignal instrumentierte Anwendungen auf demselben Server ausführen, kann diese Konfigurationsoption nur in einer davon aktiviert werden.
enable_rails_error_reporter
Beschreibung
Auffalse setzen, um den Subscriber des Rails Error Reporters zu deaktivieren. Details finden Sie in der Rails-Dokumentation.
enable_rake_performance_instrumentation
Beschreibung
Aktiviert die Performance-Instrumentierung für Rake-Tasks. Standardmäßig meldet die Rake-Instrumentierung nur Fehler.enable_statsd
Beschreibung
Aktiviert den StatsD-Server im AppSignal-Agent. Wenn aktiviert, hört der AppSignal-Agent auf einem anlocalhost gebundenen Server auf Port 8125. Wenn Sie mehrere mit AppSignal instrumentierte Anwendungen auf demselben Server ausführen, kann diese Konfigurationsoption nur in einer davon aktiviert werden.
endpoint
Beschreibung
Konfigurieren Sie den Endpunkt, an den Daten an AppSignal gesendet werden. Diese Einstellung muss in der Regel nicht geändert werden.files_world_accessible
Beschreibung
Wenn dies auftrue gesetzt ist, ist das erstellte AppSignal-Arbeitsverzeichnis für alle Benutzer zugänglich (Unix-Berechtigungen 0666). Dies ist oft notwendig, da Prozesse derselben App unter unterschiedlichen Benutzern laufen. Auf false setzen, um dieses Verhalten zu deaktivieren (Unix-Berechtigungen 0644).
filter_attributes
Beschreibung
Liste von OpenTelemetry-Span-Attributen, die mit AppSignal gefiltert werden. Übereinstimmende Werte werden durch[FILTERED] ersetzt.
Lesen Sie mehr über Parameter-Filterung.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption filter_parameters
zum Filtern von Daten bei Verwendung des Agents.
filter_function_parameters
Beschreibung
Liste der Funktionsparameter-Attribute, die mit AppSignal gefiltert werden. Übereinstimmende Werte werden durch[FILTERED] ersetzt.
Lesen Sie mehr über Parameter-Filterung.
Bis diese Option festgelegt ist, wird ihr Wert von der Konfigurationsoption filter_parameters abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption filter_parameters
zum Filtern von Daten bei Verwendung des Agents.
filter_metadata
Beschreibung
Das AppSignal Ruby-Gem speichert standardmäßig Metadaten über Anfragen und Hintergrund-Jobs in Traces, wie zum Beispiel Anfragepfad, Anfragemethode, Anfrage-ID, Hintergrund-Queue, Job-ID und Wiederholungsanzahl des Jobs. Diese Metadatenwerte werden in der Tag-Box angezeigt. Wenn einer dieser Metadatenwerte PII oder andere sensible Daten enthält, verwenden Sie diese Konfigurationsoption, um Metadaten nach Schlüssel herauszufiltern. Setzen Sie die Optionfilter_metadata auf eine Liste von Metadaten-Schlüsseln, die herausgefiltert werden sollen. Sie können dies mit einer Liste von Schlüsseln in der Konfigurationsdatei konfigurieren. Wenn gefiltert, werden die Metadaten in der AppSignal-UI nicht sichtbar sein.
filter_parameters
Beschreibung
Liste von Parameter-Schlüsseln, die mittels AppSignal-Filterung ignoriert werden sollen. Ihre Werte werden bei der Übertragung an AppSignal durch[FILTERED] ersetzt. Sie können dies mit einer Liste von Schlüsseln in der Konfigurationsdatei konfigurieren.
Nur Agent: Bei Verwendung eines externen Collectors legt diese Konfigurationsoption den Standardwert für die folgenden Optionen fest und hat sonst keine Wirkung.Verwenden Sie die folgenden Konfigurationsoptionen, um zu steuern, wie Request-Payload, Request-Query-Parameter und Funktionsparameter gefiltert werden:
filter_request_payload
Beschreibung
Liste der Request-Payload-Attribute, die mit AppSignal gefiltert werden sollen. Übereinstimmende Werte werden durch[FILTERED] ersetzt.
Lesen Sie mehr über Parameter-Filterung.
Bis diese Option festgelegt ist, wird ihr Wert von der Konfigurationsoption filter_parameters abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption filter_parameters
zum Filtern von Daten bei Verwendung des Agents.
filter_request_query_parameters
Beschreibung
Liste der Request-Query-Parameter-Attribute, die mit AppSignal gefiltert werden. Übereinstimmende Werte werden durch[FILTERED] ersetzt.
Lesen Sie mehr über Parameterfilterung.
Solange diese Option nicht festgelegt ist, wird ihr Wert von der Konfigurationsoption filter_parameters abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption filter_parameters
zum Filtern von Daten bei Verwendung des Agents.
filter_session_data
Beschreibung
Liste von Sessiondaten-Schlüsseln, die mittels AppSignal-Filterung ignoriert werden sollen. Ihre Werte werden bei der Übertragung an AppSignal durch[FILTERED] ersetzt. Sie können dies mit einer Liste von Schlüsseln in der Konfigurationsdatei konfigurieren.
host_role
Beschreibung
Gruppieren Sie Hosts nach Rolle und generieren Sie auf Basis dieser Rolle Metriken. Eine solche Metrik ist die Counter-Metrikreporting_hosts. Eine gute Rolle gibt an, was die Hauptrolle des Servers ist, wie zum Beispiel „webserver“, „processor“, „api“, „database“, „loadbalancer“ usw.
hostname
Beschreibung
Dies überschreibt den Hostnamen des Servers. Nützlich, wenn Sie keinen benutzerdefinierten Hostnamen festlegen können oder wenn auf Hosting-Diensten eine nichtssagende ID für Sie generiert wird.http_proxy
Beschreibung
Wenn der Agent die Verbindung zum Internet über einen Proxy herstellen muss, geben Sie in diesem Konfigurationsschlüssel die vollständige Proxy-URL an.ignore_actions
Beschreibung
Mit dieser Konfigurationsoption können Sie eine Liste von Aktionen angeben, die von AppSignal ignoriert werden. Alles, was passiert, einschließlich Exceptions, wird nicht an AppSignal übertragen. Dies kann nützlich sein, um Health-Check-Endpunkte oder andere Aktionen zu ignorieren, die Sie nicht überwachen möchten. Lesen Sie mehr über das Ignorieren von Aktionen.ignore_errors
Beschreibung
Liste von Fehlerklassen, die ignoriert werden. Jede mit dieser Fehlerklasse ausgelöste Exception wird nicht an AppSignal übertragen. Lesen Sie mehr über das Ignorieren von Fehlern.ignore_logs
Beschreibung
Liste von Log-Nachrichten, die ignoriert werden. Jede Log-Nachricht, die eines der Elemente der Liste enthält, wird nicht an AppSignal übertragen. Eine kleine Teilmenge der Regex-Syntax wird unterstützt. Lesen Sie mehr dazu in unserem Leitfaden zum Ignorieren von Logs.ignore_namespaces
Beschreibung
Liste von Namespaces, die ignoriert werden. Jeder ausgelöste Fehler oder jede langsame Anfrage, die in diesem Namespace auftritt, wird nicht an AppSignal gesendet. Lesen Sie mehr über Namespaces.instrument_active_job
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Active Job. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
instrument_code_ownership
Beschreibung
Ob das CodeOwnership-Gem automatisch instrumentiert werden soll, kanntrue oder false sein.
instrument_delayed_job
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Delayed::Job. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
instrument_excon
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Excon. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert. Standardmäßig aktiviert.
instrument_faraday
Beschreibung
Aktiviert oder deaktiviert die instrumentation für das Faraday-gem. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert. Standardmäßig aktiviert.
instrument_http_rb
Beschreibung
Aktiviert oder deaktiviert die Instrumentierung für das http.rb Ruby-Gem. Standardmäßig aktiviert.instrument_mongo
Beschreibung
Aktiviert oder deaktiviert die MongoDB-instrumentation, die den Mongo Ruby Driver und Mongoid abdeckt. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert. Standardmäßig aktiviert.
instrument_net_http
Beschreibung
Ob Instrumentierung fürnet/http-Aufrufe hinzugefügt werden soll, kann true oder false sein.
instrument_ownership
Beschreibung
Ob das Ownership-Gem automatisch instrumentiert werden soll, kanntrue oder false sein.
instrument_que
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Que. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
instrument_redis
Beschreibung
Ob die Instrumentierung für Redis-Abfragen mit dem Redis-Gem aktiviert werden soll, kanntrue oder false sein.
instrument_resque
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Resque. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
instrument_sequel
Beschreibung
Ob Instrumentierung fürsequel-Abfragen mithilfe der Sequel-Gem-Integration hinzugefügt werden soll, kann true oder false sein.
instrument_shoryuken
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Shoryuken. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
instrument_sidekiq
Beschreibung
Aktiviert oder deaktiviert die instrumentation für Sidekiq. Wenn Sie dies auffalse setzen, wird die integration vollständig deaktiviert, einschließlich sowohl der Job-instrumentation als auch der enqueue-instrumentation. Standardmäßig aktiviert.
keep_request_environment
Beschreibung
Liste von Rack-Environment-Werten, die gemeldet werden sollen und die keine HTTP-Request-Header sind, wieREMOTE_ADDR und QUERY_STRING. Rack-Environment-Schlüssel werden großgeschrieben und mit Unterstrichen getrennt.
Diese Konfigurationsoption ist eine Allowlist, sodass nur die darin aufgeführten Werte gemeldet werden. Setzen Sie sie auf eine leere Liste, um keine Environment-Werte zu melden.
Verwenden Sie keep_request_headers für die Request-Header.
Solange diese Option nicht gesetzt ist, wird ihr Wert aus der Konfigurationsoption request_headers abgeleitet.
Lesen Sie unseren Leitfaden zur Erfassung von Request-Headern für weitere Informationen.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption request_headers für
die Request-Header und Rack-Umgebungswerte, die bei Verwendung des Agents
gemeldet werden.
keep_request_headers
Beschreibung
Liste der HTTP-Request-Header, die gemeldet werden. Header-Namen sind klein geschrieben und durch Bindestriche getrennt, so wie OpenTelemetry sie benennt: Melden Sie den HeaderX-Hub-Signature, indem Sie x-hub-signature zu dieser Liste hinzufügen.
Diese Konfigurationsoption ist eine Allowlist, sodass nur die dort aufgeführten Header gemeldet werden. Setzen Sie sie auf eine leere Liste, um keine Request-Header zu melden.
Verwenden Sie keep_request_environment für die Werte der Rack-Environment, die keine Request-Header sind.
Bis diese Option gesetzt ist, wird ihr Wert von der Konfigurationsoption request_headers abgeleitet.
Lesen Sie unseren Leitfaden zur Erfassung von Request-Headern für weitere Informationen.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption request_headers für
die Request-Header und Rack-Umgebungswerte, die bei Verwendung des Agents
gemeldet werden.
log
Beschreibung
Diese Option konfiguriert, welchen Logger die interne Logging-Funktionalität von AppSignal verwendet, und beeinflusst die Logging-Funktion nicht.Hinweis: Der AppSignal-Agent,
der von der Integration verwendet wird, schreibt immer in die Datei „appsignal.log“.
file und stdout. Siehe auch die Konfiguration log_path.
file(Standard)- Schreibt alle AppSignal-Logs in das Dateisystem.
stdout(Standard auf Heroku)- Gibt AppSignal-Logs in STDOUT des Elternprozesses anstatt in eine Datei aus. Nützlich bei Hosting-Lösungen wie Container-Systemen und Heroku.
log_level
Beschreibung
Diese Option legt die Schweregradstufe des internen Loggers von AppSignal fest und beeinflusst die Logging-Funktion nicht.
- error
- warning
- info
- debug
- trace
log_path
Beschreibung
Diese Option konfiguriert den Speicherort der internen Logging-Datei von AppSignal und beeinflusst die Logging-Funktion nicht.
Hinweis: Der angegebene Pfad darf keine betriebssystemspezifischen Dateisystem-Abstraktionen enthalten, wie zum Beispiel das Homedir-Symbol
Hinweis: Der angegebene Pfad darf keine betriebssystemspezifischen Dateisystem-Abstraktionen enthalten, wie zum Beispiel das Homedir-Symbol
~ auf *NIX-Systemen. Dies wird als fehlerhafter Pfad gewertet.appsignal.log
geschrieben werden kann.
logging_endpoint
Beschreibung
Konfigurieren Sie den Endpunkt, an den AppSignal Logs und Check-ins sendet. Diese Einstellung muss in der Regel nicht geändert werden.nginx_port
Beschreibung
Konfigurieren Sie den Port, auf dem der NGINX-Metrik-Server bereitgestellt wird. Wenn AppSignal NGINX-Metriken empfängt, hört es auf einem anlocalhost gebundenen Server, standardmäßig auf Port 27649. Wenn Sie mehrere mit AppSignal instrumentierte Anwendungen auf demselben Server mit aktivierten NGINX-Metriken ausführen, verwenden Sie diese Option, um jede Anwendung so zu konfigurieren, dass sie auf einem anderen Port hört.
ownership_set_namespace
Beschreibung
Ob die Ownership-Gem-Instrumentierung den Namespace eines Samples auf seinen Owner setzen soll, kanntrue oder false sein.
request_headers
Beschreibung
Nur Agent: Bei Verwendung eines externen Collectors legt diese Konfigurationsoption die Standardeinstellung für die folgenden Optionen fest und hat ansonsten keine Wirkung.Im Collector-Modus empfehlen wir, stattdessen die folgenden Konfigurationsoptionen zu verwenden:
request_headers enthält eine Liste von Schlüsseln der Rack-Umgebung, die vom AppSignal-Ruby-Gem gelesen und gespeichert werden. Einige dieser Schlüssel enthalten einen HTTP-Request-Header, andere einen Wert, der die Anfrage beschreibt, etwa ihre Methode oder den Host, an den sie gesendet wurde.
Diese Konfigurationsoption request_headers ist eine Allowlist, was bedeutet, dass nur die durch diese Konfigurationsoption angegebenen Schlüssel der Rack-Umgebung gemeldet werden. Wenn diese Konfigurationsoption nicht gesetzt ist, wird der AppSignal-Standard verwendet.
Lesen Sie unseren Leitfaden zur Erfassung von Request-Headern, um zu erfahren, wie Rack den Schlüssel eines Headers benennt.
response_headers
Beschreibung
Die Konfigurationsoptionresponse_headers enthält eine Liste von HTTP-Response-Headern, die vom AppSignal-Ruby-Gem gelesen und gespeichert werden.
Diese Konfigurationsoption response_headers ist eine Allowlist, was bedeutet, dass nur Header gemeldet werden, die durch diese Konfigurationsoption angegeben sind. Standardmäßig sind keine Header angegeben, sodass keine Response-Header gemeldet werden, bis welche hinzugefügt werden.
Um diese Liste anzupassen, fügen Sie die Konfigurationsoption mit allen Headern hinzu, die gemeldet werden sollen. Alle Header-Namen sollten in Kleinbuchstaben geschrieben werden. Wenn der Header-Name X-Custom-Header ist, fügen Sie ihn dieser Liste als x-custom-header hinzu.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.
revision
Beschreibung
Legen Sie die App-Revision fest, um die aktuell laufende Version Ihrer Anwendung zu melden. AppSignal erstellt einen Deploy-Marker, wenn sich dieser Wert ändert, und versieht alle eingehenden Daten mit der aktuellen Revision. Die AppSignal-Integration erkennt automatisch den Git-Commit der Bereitstellung und verwendet ihn als Revision, wenn Sie mit einem der folgenden Tools oder Anbieter bereitstellen:- Kamal
- Render
- Scalingo
- Heroku, wenn die Funktion Heroku Labs: Dyno Metadata aktiviert ist
revision fest, um die erkannte Revision zu überschreiben.
Verwenden Sie einen einzelnen Wert ohne Leerzeichen, zum Beispiel einen Git-Commit-SHA (abc0123) oder eine Versionsnummer (1.2.3). AppSignal erstellt anhand dieses Werts Links zu Ihrem Quellcode. Weitere Informationen finden Sie unter Revisionswert wählen.
Weitere Informationen zu Deploy-Markern finden Sie im Thema Deploy-Marker.
Wenn mehr als eine Quelle die Revision festlegt, verwendet das Ruby-Gem die erste Quelle aus dieser Liste, die gesetzt ist:
- Die Konfigurationsoption
revisionoder die UmgebungsvariableAPP_REVISION. - Die von Heroku (
HEROKU_SLUG_COMMIT), Render (RENDER_GIT_COMMIT), Kamal (KAMAL_VERSION) oder Scalingo (CONTAINER_VERSION) gesetzte Umgebungsvariable, in dieser Reihenfolge. - Die Datei
REVISIONim Stammverzeichnis der Anwendung.
running_in_container
Beschreibung
AppSignal erwartet, dass es zwischen verschiedenen Deployments auf derselben Maschine läuft. Setzen Sie diesen Schlüssel auftrue, wenn die Anwendung in einem Container ausgeführt wird, beispielsweise mit Docker.
Neuere Versionen der AppSignal-Integration erkennen ihre Container-Umgebung automatisch, sodass keine manuelle Konfiguration erforderlich ist. Wenn Sie Probleme mit der automatischen Erkennung haben, kontaktieren Sie bitte den Support.
Diese Option wird auf Heroku automatisch auf true gesetzt.
send_environment_metadata
Beschreibung
Sendet Umgebungsmetadaten über die Anwendung. Weitere Informationen finden Sie unter Umgebungsmetadaten.send_function_parameters
Beschreibung
Ob Funktionsparameter an AppSignal gesendet werden sollen. Solange diese Option nicht festgelegt ist, wird ihr Wert von der Konfigurationsoptionsend_params abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption send_params
zum Senden von Daten, wenn der Agent nicht verwendet wird.
send_params
Beschreibung
Legt fest, ob das Senden von Request-Parametern an AppSignal übersprungen werden soll. Weitere Informationen finden Sie unter send_params im Abschnitt zur Filterung von Request-Parametern.Nur Agent: Bei Verwendung eines externen Collectors legt diese Konfigurationsoption den Standardwert für die folgenden Optionen fest und hat ansonsten keine Wirkung.Legen Sie die folgenden Konfigurationsoptionen fest, um zu steuern, ob Request-Payloads, Request-Query-Parameter und Funktionsparameter gesendet werden:
send_request_payload
Beschreibung
Ob das Request-Payload an AppSignal gesendet werden soll. Bis diese Option gesetzt ist, wird ihr Wert von der Konfigurationsoptionsend_params abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption send_params
zum Senden von Daten, wenn der Agent nicht verwendet wird.
send_request_query_parameters
Beschreibung
Ob Request-Query-Parameter an AppSignal gesendet werden sollen. Solange diese Option nicht gesetzt ist, wird ihr Wert von der Konfigurationsoptionsend_params abgeleitet.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.Siehe die Konfigurationsoption send_params
zum Senden von Daten, wenn der Agent nicht verwendet wird.
send_session_data
Beschreibung
Setzen Sie diese Option auffalse, um keine Session-Daten mit Exception-Traces und Performance-Issue-Samples zu senden.
Weitere Informationen finden Sie unter Filterung von Request-Session-Daten.
service_name
Beschreibung
Der Service-Name hilft AppSignal, verschiedene Services für Traces zu erkennen, und gruppiert die Traces automatisch in einem Namespace basierend auf dem Service-Namen. Wählen Sie einen Namen, der zu Ihrer Anwendung passt, wieweb-server, background-worker, email-service oder authentication-service.
Nur Collector: Diese Konfigurationsoption hat nur eine Wirkung, wenn Sie
einen externen Collector verwenden.
sidekiq_report_errors
Beschreibung
Konfigurieren Sie die Meldung von Fehlern, die in Sidekiq-Jobs auftreten. Akzeptierte Werte:all: Alle Fehler bei jeder Job-Ausführung melden, einschließlich Wiederholungen.discard: Fehler melden, wenn der Job aufgrund des Fehlers verworfen wird. Verwenden Sie diese Option, um nur dann Fehler zu melden, wenn alle Job-Wiederholungen ausgeschöpft sind.none: Keine Fehler für Jobs melden, einschließlich Wiederholungen. Nützlich für benutzerdefinierte Fehlerberichterstattung.
Hinweis: Die Option
discard funktioniert nur in Sidekiq 5.1 und neuer. In
niedrigeren Versionen wird discard als all interpretiert.skip_session_data
Beschreibung
statsd_port
Beschreibung
Setzen Sie diese Option, um den StatsD-HTTP-Server-Port des AppSignal-Agent-Prozesses zu konfigurieren. Konfigurieren Sie diesen Port, wenn auf der Maschine bereits ein anderer Prozess läuft, der ebenfalls diesen Port verwendet, um Konflikte zu vermeiden.transaction_debug_mode
Beschreibung
Aktiviert den Transaktions-Debug-Modus. Dies aktiviert eine sehr detaillierte Protokollierung von Transaktionen und Ereignissen, was bei der Entwicklung von Integrationen oder wenn Ereignisse nicht wie erwartet erfasst werden, nützlich ist. Das Log wird nur geschrieben, wenn auch die allgemeine Optiondebug aktiviert ist.
Diese Option legt den Schweregrad des internen Loggers von AppSignal fest und
hat keinen Einfluss auf die Logging-Funktion.
working_dir_path
Beschreibung
Überschreibt den Ort, an dem AppSignal für Ruby ein Arbeitsverzeichnis
erstellt. Siehe
working_directory_path
für das anwendbare Verhalten. Diese Konfigurationsoption hängt /appsignal an
den angegebenen Pfad an, während
working_directory_path
dies nicht tut.Hinweis: Der angegebene Pfad darf keine betriebssystemspezifischen
Dateisystem-Abstraktionen enthalten, wie etwa das Homedir-Symbol
~ für
*NIX-Systeme. Dies wird als fehlerhafter Pfad interpretiert.working_directory_path
Beschreibung
Überschreibt den Ort, an dem AppSignal für Ruby temporäre Dateien speichern kann. Verwenden Sie diese Option, wenn der Standardort nicht geeignet ist. Weitere Informationen zum Zweck dieses Arbeitsverzeichnisses finden Sie auf unserer Seite Wie AppSignal funktioniert. Wenn Sie mehrere Anwendungen mit AppSignal auf demselben Server ausführen, verwenden Sie diese Konfigurationsoption, um für jede AppSignal-Instanz unterschiedliche Arbeitsverzeichnisse auszuwählen, da die beiden Instanzen sonst miteinander in Konflikt geraten könnten. Weitere Informationen zu diesem Szenario finden Sie in unserer Dokumentation Mehrere Anwendungen auf einem Host ausführen.Hinweis: Der angegebene Pfad darf keine betriebssystemspezifischen
Dateisystem-Abstraktionen enthalten, wie etwa das Homedir-Symbol
~ für
*NIX-Systeme. Dies wird als fehlerhafter Pfad interpretiert.