De onderstaande lijst bevat alle configuratieopties met de naam van de omgevingsvariabele en de naam van de sleutel in het configuratiebestand.Voor meer informatie over hoe u AppSignal kunt configureren met een configuratiebestand of systeem-omgevingsvariabelen, zie ons onderwerp Configuratie.
Let op: Wanneer de omgevingsvariabele
APPSIGNAL_PUSH_API_KEY is ingesteld, wordt dit
standaard true. Dit kan worden overschreven door de systeemomgevingsvariabele
APPSIGNAL_ACTIVE op false te zetten: APPSIGNAL_ACTIVE=false.
Configureer of AppSignal actief is of niet voor een bepaalde omgeving. Wordt meestal gebruikt in de bestandsconfiguratie per omgeving.
De omgeving van de app die aan AppSignal wordt gerapporteerd. Deze configuratieoptie wordt automatisch gedetecteerd in Rails-apps. Voor Rails-apps wordt de variabele RAILS_ENV gebruikt om de omgeving te detecteren. Voor apps die andere frameworks of geen framework gebruiken, wordt de omgevingsvariabele RACK_ENV gebruikt.Om deze automatische detectie te overschrijven, stelt u de omgevingsvariabele APPSIGNAL_APP_ENV in.
Shell
export APPSIGNAL_APP_ENV=stagingrackup
Deze optie wordt gebruikt om de configuratie te laden uit de configuratiebestanden waarin de AppSignal-configuratie is opgeslagen.De omgevingsvariabele-optie wordt vaak gebruikt op platforms waar apps standaard in de production-omgeving draaien, zoals Heroku. Met deze instelling kunt u bijvoorbeeld een override instellen om de omgeving op staging te zetten.
Shell
heroku config:set APPSIGNAL_APP_ENV=staging
Als de omgeving wordt ingesteld met de Appsignal.configure-helper, overschrijft deze de omgevingsvariabele APPSIGNAL_APP_ENV.
Let op: Het wijzigen van de naam of omgeving van een
bestaande app maakt een nieuwe app aan op AppSignal.com.
Let op: Deze configuratieoptie heeft geen equivalent in het
configuratiebestand. Om de omgeving in te stellen bij de AppSignal-initialisatie
moet u de configuratie handmatig
initialiseren.
Er is geen env-sleutel beschikbaar in het bestand config/appsignal.yml. Als u
de omgevingsnaam voor een app dynamisch in het configuratiebestand wilt instellen, kunt u
uw configuratiebestand aanpassen om de omgeving te gebruiken om een omgeving aan te maken.
Als u een andere omgevingsvariabele dan APPSIGNAL_APP_ENV gebruikt, zorg er dan voor dat de waarde overeenkomt met een van de automatisch gedetecteerde namen van omgevingsvariabelen (RAILS_ENV en RACK_ENV) of met de waarde die aan Appsignal.configure wordt meegegeven.
Let op: Het wijzigen van de naam of omgeving van een
bestaande app maakt een nieuwe app aan op AppSignal.com.
Naam van uw applicatie zoals deze op AppSignal.com weergegeven moet worden. Als u Ruby on Rails gebruikt, zal de gem de naam automatisch detecteren en kunt u dit leeg laten. Voor andere frameworks is het instellen hiervan verplicht.
Let op: Het wijzigen van de naam of environment van een bestaande app
maakt een nieuwe app aan op AppSignal.com.
De authenticatiesleutel op organisatieniveau om te authenticeren met onze Push API.Lees meer over de AppSignal Push API key.
Let op: Wanneer de systeemomgevingsvariabele APPSIGNAL_PUSH_API_KEY
is ingesteld, krijgt de optie active standaard de waarde
true in plaats van false. Dit betekent dat AppSignal als actief
wordt beschouwd voor de geladen environment, zelfs als active op false is ingesteld in het
configuratiebestand. Zie voor meer informatie de optie active.
Configureer de rapportage van fouten die optreden in Active Job-jobs. Met deze optie kan de foutrapportage voor Active Job-jobs worden uitgeschakeld, zodat aangepaste foutrapportage kan worden toegevoegd.Geaccepteerde waarden:
all: Rapporteer alle fouten voor elke uitvoering van jobs, inclusief retries.
discard: Rapporteer fouten wanneer de job wordt verworpen vanwege de fout. Gebruik deze optie om fouten alleen te rapporteren wanneer alle job-retries zijn uitgeput.
none: Rapporteer geen fouten voor jobs, inclusief retries.
Let op: De optie discard werkt alleen op Active Job 7.1 en nieuwer. Op
lagere versies wordt discard gelezen als all.
Een geldig IPv4-adres dat de AppSignal-agent gebruikt als binding voor zijn TCP- en UDP-servers. Gebruik een specifiek adres als u alleen wilt dat de agent luistert naar verzoeken aan dat adres. Stel deze optie in op 0.0.0.0 om verzoeken te ontvangen van hosts die elk IP-adres gebruiken. Standaard luistert deze alleen naar verzoeken die op dezelfde host worden gedaan. Deze optie wordt toegepast op alle agentservers (StatsD, OpenTelemetry en NGINX).
Configureer het pad van het SSL-certificaatbestand. Standaard wijst dit naar het AppSignal meegeleverde cacert.pem-bestand in de gem zelf.Gebruik deze optie om naar een ander certificaatbestand te wijzen als er een probleem is met de verbinding naar onze API.
Let op: Het opgegeven pad mag geen besturingssysteemspecifieke
bestandssysteemabstracties bevatten, zoals het homedir-symbool ~ voor *NIX-systemen. Dit wordt
gezien als een onjuist pad.
De beschikbare CPU-capaciteit van de host, uitgedrukt in aantal CPU’s. Dit wordt gebruikt om het CPU-gebruikspercentage in de host-metrics te berekenen. Indien niet ingesteld, probeert de agent dit automatisch te detecteren via cgroups.Het aantal CPU’s kan een breuk zijn, bijv. 0.5.
Waarschuwing: Deze configuratie-optie is verouderd in Ruby gem 3.0.16. Gebruik
in plaats daarvan de log_level optie voor Ruby gem 3.0.16 en
nieuwer.
Schakel debug-logging in. Dit is meestal alleen nodig op verzoek van support. Met deze optie ingeschakeld logt AppSignal veel meer informatie over beslissingen die worden genomen tijdens het verzamelen van metrics en wanneer data naar AppSignal.com-servers wordt verzonden.Het inschakelen van debug-logging kan een lichte impact hebben op het schijfgebruik en de IO, vooral op websites met veel verkeer. De CPU-overhead is minimaal bij het inschakelen van de debug-optie.
Deze optie stelt het severity-niveau in van de interne logger van AppSignal. Deze
configuratie-optie heeft geen effect op de logging-functionaliteit.
Standaardtags die aan alle transacties worden toegevoegd. Transactie-specifieke tags die met Appsignal.add_tags worden ingesteld, overschrijven standaardtags met dezelfde sleutel.
Appsignal.configure do |config| config.dns_servers = ["8.8.8.8", "8.8.4.4"]end
Als u last heeft van onze DNS-timeouts, probeer dan handmatig een DNS-server in te stellen met deze optie die niet meer dan 4 punten in de servernaam gebruikt.
Als de DNS-server niet bereikbaar is, valt de agent terug op de DNS-configuratie van de host en wordt er een bericht naar het appsignal.log-bestand geschreven: A problem occurred while setting DNS servers.
Schakelt de integratie met ActiveSupport::EventReporterstructured event reporting in.Wanneer ingeschakeld, abonneert de AppSignal-integratie zich op events die door ActiveSupport::EventReporter worden uitgezonden en rapporteert deze als logs.
Configureer hoe AppSignal wordt afgesloten wanneer de applicatie wordt afgesloten. Dit bepaalt of Appsignal.stop automatisch wordt aangeroepen, waardoor de data naar de extensie en de agent wordt doorgespoeld.Deze optie heeft drie mogelijke waarden:
always: Roep altijd Appsignal.stop aan wanneer het programma stopt. Op (Docker-)containers wordt deze waarde automatisch ingesteld.
never: Roep nooit Appsignal.stop aan wanneer het programma stopt. De standaardwaarde wanneer het programma niet in een (Docker-)container draait.
on_error: Roep Appsignal.stop aan wanneer het programma met een fout stopt.
Stel in op true om de laatste fout te rapporteren die het proces deed afsluiten. De gerapporteerde fout is meestal de fout die het proces laat crashen. Als de Ruby gem de fout al heeft gerapporteerd, wordt deze niet opnieuw gerapporteerd.Fouten die via dit mechanisme worden gerapporteerd, worden toegevoegd aan de “unhandled”-namespace.Voeg deze code toe aan het begin van de applicatie op kortlevende containers en serverless-functies om ervoor te zorgen dat de fout wordt doorgespoeld voordat het systeem wordt afgesloten.
Schakel het experimentele front-end error catching-systeem in. Dit voegt een route aan uw app toe op /appsignal_error_catcher die kan worden gebruikt om JavaScript-fouten op te vangen en naar AppSignal te sturen. U kunt deze route configureren met frontend_error_catching_path.
Stel deze optie in op false om de GVL global timer-instrumentatie uit te schakelen. Deze configuratie-optie heeft geen effect als GVLTools niet is geïnstalleerd.
Stel deze optie in op false om de GVL waiting threads-instrumentatie uit te schakelen. Deze configuratie-optie heeft geen effect als GVLTools niet is geïnstalleerd.
Stel deze optie in op false om het verzamelen van host-metrics uit te schakelen.Op Heroku en Dokku zijn host-metrics standaard uitgeschakeld. Dit komt doordat deze systemen onnauwkeurige metrics rapporteren vanuit de containers. Het verzamelen van host-metrics op deze systemen kan niet worden ingeschakeld. Gebruik voor Heroku in plaats daarvan de Heroku log drain.
Stel in op true om de NGINX-metricsserver in te schakelen. Zie de NGINX-metricsdocumentatie voor details.Wanneer ingeschakeld, luistert de AppSignal-agent naar een server gebonden aan localhost op poort 27649. Als u meerdere AppSignal-geïnstrumenteerde applicaties op dezelfde server draait, kan deze configuratie-optie slechts in één daarvan worden ingeschakeld.
Schakelt de StatsD-server in de AppSignal-agent in.Wanneer ingeschakeld, luistert de AppSignal-agent naar een server gebonden aan localhost op poort 8125. Als u meerdere AppSignal-geïnstrumenteerde applicaties op dezelfde server draait, kan deze configuratie-optie slechts in één daarvan worden ingeschakeld.
Als dit is ingesteld op true, is de AppSignal-werkdirectory die wordt aangemaakt toegankelijk voor alle gebruikers (Unix-permissies 0666). Dit is vaak nodig omdat processen voor dezelfde app onder een andere gebruiker draaien. Stel in op false om dit gedrag uit te schakelen (Unix-permissies 0644).
De AppSignal Ruby gem slaat standaard metadata over requests en background jobs op samples op, zoals request-pad, request-methode, request-id, background-queue, job-id en job-retry-aantal. Deze metadatawaarden worden weergegeven in de tags-box. Als een van deze metadatawaarden PII of andere gevoelige data bevat, gebruik dan deze configuratie-optie om metadata op sleutel te filteren.Stel de filter_metadata-optie in op een lijst van metadatasleutels die moeten worden gefilterd. U kunt dit configureren met een lijst van sleutels in het configuratiebestand. Wanneer gefilterd is de metadata niet zichtbaar in de AppSignal UI.
Appsignal.configure do |config| config.filter_metadata += ["path", "request_id"]end
Lijst van parametersleutels die genegeerd moeten worden via AppSignal-filtering. Hun waarden worden vervangen door [FILTERED] wanneer ze naar AppSignal worden verzonden. U kunt dit configureren met een lijst van sleutels in het configuratiebestand.
Appsignal.configure do |config| config.filter_parameters += ["password", "email", "api_token", "token"]end
Lijst van session-data-sleutels die genegeerd moeten worden via AppSignal-filtering. Hun waarden worden vervangen door [FILTERED] wanneer ze naar AppSignal worden verzonden. U kunt dit configureren met een lijst van sleutels in het configuratiebestand.
Appsignal.configure do |config| config.filter_session_data += ["name", "email", "api_token", "token"]end
Groepeer hosts op rol en genereer metrics op basis van deze rol. Een voorbeeld van zo’n metric is de teller-metric reporting_hosts. Een goede rol geeft aan wat de hoofdrol van de server is, zoals “webserver”, “processor”, “api”, “database”, “loadbalancer”, enz.
Dit overschrijft de hostnaam van de server. Handig wanneer u geen aangepaste hostnaam kunt instellen of wanneer er een nietszeggend ID voor u wordt gegenereerd bij hostingdiensten.
Met deze configuratie-optie kunt u een lijst opgeven van acties die door AppSignal worden genegeerd. Alles wat gebeurt, inclusief exceptions, wordt niet naar AppSignal verzonden. Dit kan handig zijn om health check-endpoints of andere acties die u niet wilt monitoren te negeren.Lees meer over acties negeren.
Lijst van foutklassen die worden genegeerd. Elke exception die met deze foutklasse wordt opgeworpen, wordt niet naar AppSignal verzonden.Lees meer over fouten negeren.
Lijst van logberichten die worden genegeerd. Elk logbericht dat een van de elementen van de lijst bevat, wordt niet naar AppSignal verzonden. Een kleine subset van regex-syntaxis wordt ondersteund; lees daar meer over in onze Ignore Logs-handleiding.
Lijst van namespaces die worden genegeerd. Elke opgeworpen fout of trage request die in deze namespace plaatsvindt, wordt niet naar AppSignal verzonden.Lees meer over namespaces.
Deze optie configureert welke logger de interne logfunctionaliteit van AppSignal
zal gebruiken en heeft geen effect op de logging-functionaliteit.Let op: De AppSignal-agent,
die door de integratie wordt gebruikt, schrijft altijd naar het bestand “appsignal.log”.
Selecteer welke logger de AppSignal-integratie gebruikt. Geaccepteerde waarden zijn
file en stdout. Zie ook de log_path-configuratie.
file (standaard)
Schrijf alle AppSignal-logs naar het bestandssysteem.
Print AppSignal-logs naar de STDOUT van het bovenliggende proces in plaats van naar een bestand.
Handig bij hostingoplossingen zoals containersystemen en Heroku.
Deze optie stelt het severity-niveau in van de interne logger van AppSignal en heeft
geen effect op de logging-functionaliteit.
Stel het severity-niveau in van de interne logger van AppSignal. Als deze is geconfigureerd op “info”, worden alle error-, warning- en info-berichten gelogd, maar geen debug-berichten.Het instellen op de niveaus “debug” of “trace” is meestal alleen nodig op verzoek van support. Het instellen van het niveau op “debug”/“trace” kan een lichte impact hebben op het schijfgebruik en de IO, vooral op websites met veel verkeer. De CPU-overhead is minimaal bij het inschakelen van de debug-optie.Geaccepteerde waarden:
Deze optie configureert de locatie van het interne logbestand van AppSignal en
heeft geen effect op de logging-functionaliteit. Let op: Het opgegeven pad mag geen besturingssysteemspecifieke
bestandssysteemabstracties bevatten, zoals het homedir-symbool ~ voor *NIX-systemen. Dit wordt
gezien als een onjuist pad.
Overschrijf de locatie van het pad (directory) waar het appsignal.log-bestand naartoe
geschreven kan worden.
Configureer de poort waarop de NGINX-metricsserver beschikbaar is.Wanneer AppSignal NGINX-metrics ontvangt, luistert het naar een server gebonden aan localhost, standaard op poort 27649. Als u meerdere AppSignal-geïnstrumenteerde applicaties op dezelfde server draait met NGINX-metrics ingeschakeld, gebruik dan deze optie om elke applicatie te configureren om op een andere poort te luisteren.
De request_headers configuratieoptie bevat een lijst met HTTP request headers die door de AppSignal Ruby gem worden gelezen en opgeslagen.Deze request_headers configuratieoptie is een allowlist, wat betekent dat alleen de headers worden gebruikt die door deze configuratieoptie zijn opgegeven. Als deze configuratieoptie niet is ingesteld, wordt de standaardwaarde van AppSignal gebruikt.
Appsignal.configure do |config| # Add a request header config.request_headers << "PATH_INFO" # Remove a request header config.request_headers.delete("PATH_INFO")end
Houd er rekening mee dat AppSignal de headers uit uw app leest en dat deze mogelijk niet 1 op 1 overeenkomen met wat in de browser/client wordt verzonden. In Rack-apps (Rails, Sinatra, etc.) krijgen alle aangepaste headers het voorvoegsel HTTP_, worden alle headernamen in hoofdletters omgezet en worden streepjes (-) vervangen door onderstrepingstekens (_).De header X-Hub-Signature kan bijvoorbeeld door uw app en AppSignal worden benaderd met de naam HTTP_X_HUB_SIGNATURE.Om AppSignal zo te configureren dat er geen HTTP request headers worden opgeslagen bij AppSignal-transacties, configureert u de optie met een lege array.
Appsignal.configure do |config| config.request_headers = []end
Stel de app-revisie in om de momenteel actieve versie van uw app te rapporteren. AppSignal maakt een deploy marker aan wanneer deze waarde verandert en voorziet alle binnenkomende gegevens van de huidige revisie als tag.Wanneer uw applicatie wordt gedeployed met Kamal, of naar Render wordt gedeployed, of naar Heroku wordt gedeployed en de Heroku Labs: Dyno Metadata-functie is ingeschakeld, detecteert de AppSignal-integratie automatisch de Git-commit van de huidige deployment en gebruikt deze als revisie.U kunt de automatisch gedetecteerde revisies in Heroku, Render of Kamal overschrijven door handmatig de revision configuratieoptie op een aangepaste waarde in te stellen.Lees meer over deploy markers in het onderwerp deploy markers.
AppSignal verwacht tussen verschillende deploys op dezelfde machine te draaien. Stel deze sleutel in op true als de applicatie in een container draait, zoals met Docker.Nieuwere versies van de AppSignal-integratie detecteren de containeromgeving automatisch, dus handmatige configuratie is niet nodig. Als u problemen ondervindt met de automatische detectie, neem dan contact op met support.Deze optie wordt automatisch op true gezet op Heroku.
Bepaalt of het verzenden van requestparameters naar AppSignal moet worden overgeslagen.Lees voor meer informatie over send_params bij het filteren van requestparameters.
Stel deze optie in op false om geen sessiegegevens mee te sturen met exception traces en performance issue samples.Lees voor meer informatie over het filteren van request session data.
Configureer de rapportage van fouten die optreden in Sidekiq-jobs.Geaccepteerde waarden:
all: Rapporteer alle fouten voor elke uitvoering van jobs, inclusief retries.
discard: Rapporteer fouten wanneer de job vanwege de fout wordt weggegooid. Gebruik deze optie om alleen fouten te rapporteren wanneer alle retries van de job zijn uitgeput.
none: Rapporteer geen fouten voor jobs, inclusief retries. Nuttig voor aangepaste foutrapportage.
Let op: De discard-optie werkt alleen op Sidekiq 5.1 en nieuwer. Op lagere
versies wordt discard als all gelezen.
Waarschuwing: Deze configuratieoptie is verouderd in Ruby gem 3.0.20. Gebruik
in plaats daarvan de optie send_session_data voor nieuwere
versies van de Ruby gem.
Stel deze optie in om de poort van de StatsD HTTP-server van het AppSignal-agentproces te configureren. Configureer deze poort als er al een ander proces op de machine draait dat deze poort ook gebruikt, om conflicten te voorkomen.
Waarschuwing: Deze configuratieoptie is verouderd in Ruby gem 3.0.16. Gebruik
in plaats daarvan de optie log_level voor Ruby gem 3.0.16 en
nieuwer.
Schakel transaction debug mode in. Hiermee wordt zeer gedetailleerde logging van transacties en events ingeschakeld, wat handig is bij het ontwikkelen van integraties of wanneer events niet zoals verwacht worden gevolgd. De log wordt alleen geschreven als de algemene debug-optie ook is ingeschakeld.
Deze optie stelt het severity level van de interne logger van AppSignal in en
heeft geen invloed op de logging-functie.
Waarschuwing: Deze configuratieoptie is verouderd in Ruby gem 2.7.0. Gebruik
in plaats daarvan de optie working_directory_path
voor Ruby gem 2.7.0 en nieuwer.
Overschrijf de locatie waar AppSignal for Ruby een werkdirectory aanmaakt.
Zie
working_directory_path
voor het gedrag dat van toepassing is. Deze configuratieoptie voegt /appsignal toe
aan het opgegeven pad, terwijl
working_directory_path
dat niet doet.
Let op: Het opgegeven pad mag geen besturingssysteem-specifieke abstracties
voor het bestandssysteem bevatten, zoals het homedir-symbool ~ voor *NIX-systemen. Dit zal worden
gezien als een ongeldig pad.
Overschrijf de locatie waar AppSignal for Ruby tijdelijke bestanden kan opslaan. Gebruik deze optie als de standaardlocatie niet geschikt is. Zie onze pagina hoe AppSignal werkt voor meer informatie over het doel van deze werkdirectory.Als u meerdere applicaties met AppSignal op dezelfde server draait, gebruik dan deze configuratieoptie om verschillende werkdirectories voor elke AppSignal-instantie te kiezen, anders kunnen de twee instanties met elkaar conflicteren. Voor meer informatie over dit scenario zie onze documentatie meerdere applicaties op één host.
Appsignal.configure do |config| config.working_directory_path = "/tmp/project_1/"end
Let op: Het opgegeven pad mag geen besturingssysteem-specifieke abstracties
voor het bestandssysteem bevatten, zoals het homedir-symbool ~ voor *NIX-systemen. Dit zal worden
gezien als een ongeldig pad.
