Active Job
Zie onze Active Job-pagina voor meer informatie over hoe onze Active Job-instrumentatie werkt.Action Cable
Zie onze Action Cable-pagina voor meer informatie over hoe onze Action Cable-instrumentatie werkt.AppSignal configureren in een initializer
We raden aan onsconfig/appsignal.rb-configuratiebestand of omgevingsvariabelen te gebruiken om AppSignal te configureren.
Standaard is het niet mogelijk om AppSignal vanuit een Rails-initializer te configureren, omdat AppSignal wordt geladen vóór de initializers van uw applicatie, om fouten te kunnen rapporteren die tijdens de initialisatie optreden.
Om AppSignal in een Rails-initializer te configureren, configureer Rails dan eerst om AppSignal te starten nadat de initializers van de app zijn uitgevoerd.
Appsignal.start niet aan in de initializers. De Ruby-gem start AppSignal automatisch wanneer Rails alle initializers heeft uitgevoerd.
Wanneer een Rails-app is geconfigureerd om AppSignal te starten nadat de initializers zijn geladen, is het niet langer mogelijk om fouten uit initializers te rapporteren bij het opstarten van de Rails-app.
Foutrapportage vanuit initializers
Standaard rapporteert AppSignal fouten die optreden in controllers, Rake-taken en Active Job-jobs. Het rapporteert geen fouten die optreden wanneer de applicatie opstart, vóór de Rails-initializers. Om op de hoogte te worden gesteld wanneer deze fouten optreden, voegt u het volgende toe aan uwconfig.ru-bestand, rond de regel die het environment.rb-bestand requireert.
Backtrace-cleaner
Met de Rails-integratie zal AppSignal de backtrace van elke exceptie door de Rails backtrace-cleaner halen. Met deze cleaner kunt u ongewenste backtrace-regels wijzigen of uitfilteren, waarmee rommel en ruis uit de backtrace worden verwijderd. U kunt filters en silencers toevoegen aan of verwijderen uit de standaardconfiguratie. Filters wijzigen de gegeven regel. Een voorbeeld hiervan is het verwijderen van hetRails.root-prefix.
Silencers verwijderen de regel uit de backtrace, als de gegeven expressie true retourneert. U kunt deze extra backtrace-cleaner-regels toevoegen in een initializer.
Bijvoorbeeld:
Error reporter
AppSignal rapporteert standaard fouten die viaActiveSupport::ErrorReporter worden gemeld. ActiveSupport::ErrorReporter is geïntroduceerd in Rails 7.0 om aangepaste foutrapportage te standaardiseren.
U kunt deze functionaliteit uitschakelen met de configuratieoptie enable_rails_error_reporter.
Als er een transactie actief is in de context waarin een fout wordt gerapporteerd via de Rails-error-reporter, bevat deze dezelfde metadata en sample-gegevens als de actieve transactie: namespace, actienaam, tags, aangepaste gegevens, parameters, enz.
Namespace en actie uit de huidige transactie
Bij het rapporteren van fouten bepalen we de namespace en actienaam waarin deze plaatsvindt, zoals een controller of background job, op basis van best effort. De incident-namespace en actienaam worden niet altijd ingesteld of zijn niet altijd accuraat. Als een AppSignal-transactie actief is (zoals bij een web request of background job) zal de fout die wordt gerapporteerd metRails.error.handle/record dezelfde namespace, actienaam, tags, parameters, aangepaste gegevens, enz. hebben als de actieve transactie. Als er geen AppSignal-transactie actief is, worden er standaard geen namespace, actienaam, tags, enz. ingesteld.
Namespace en actie uit de context
Als u de namespace en actienaam van de gerapporteerde fout wilt wijzigen zonder deze op de reeds actieve AppSignal-transactie te wijzigen, kunt u dit aanpassen bij de aanroep van de error-reporter.Tags uit de actieve transactie
Standaard worden de tags van de transactie van het request/de job gekopieerd naar de AppSignal-transactie van de fout van de error-reporter vanuit de transactie van het request/de job.Tags uit context
U kunt tags toevoegen aan een gerapporteerde fout doorcontext te gebruiken in de aanroep van Rails.error.handle/record. Deze tags worden alleen ingesteld op de fout die wordt gerapporteerd met de methoden Rails.error.handle/record.
Appsignal.add_tags.
Ruby-gem 3 legacy-gedrag
In AppSignal voor Ruby-gem versie 3 is het foutrapportagegedrag anders.- Fouten die worden gerapporteerd met de methode
Rails.error.handleworden gerapporteerd aan AppSignal. - Fouten die worden gerapporteerd met
Rails.error.recordworden niet gerapporteerd aan AppSignal om te voorkomen dat de fout twee keer wordt gerapporteerd wanneer deze door onze Rails-error-reporting-middleware wordt gerapporteerd.
Beperkingen van context-overerving
In Ruby-gem 3 is de overerving van context uit de actieve transactie beperkt. De metadata en een deel van de sample-gegevens worden alleen gekopieerd als deze zijn ingesteld op het moment datRails.error.handle/record wordt aangeroepen.
In de praktijk betekent dit dat Rails-controllers en Active Job-jobs nauwkeurig worden gerapporteerd. Bij andere bibliotheken zoals Sidekiq-jobs wordt er geen actienaam ingesteld bij het rapporteren van fouten met Rails.error.handle.
Tags die worden ingesteld nadat Rails.error.handle/record is aangeroepen, worden niet gerapporteerd voor de fout die met deze helper wordt gerapporteerd.
Runners
AppSignal rapporteert automatisch fouten binnen Rails-runners. Er is ook enige handmatige configuratie nodig om de prestaties van een runner te instrumenteren. We raden aan om de code van de runner in een apart bestand te plaatsen en in te pakken in deAppsignal.monitor-helper, zoals in het onderstaande voorbeeld.
Bash
enable_at_exit_hook op true staat (wat de standaard zou moeten zijn op containers). Dit zorgt ervoor dat de gegevens worden doorgespoeld naar de AppSignal-agent voordat de runner wordt afgesloten.