Active Job
Weitere Informationen zur Funktionsweise unserer Active-Job-Instrumentation finden Sie auf unserer Active-Job-Seite.Action Cable
Weitere Informationen zur Funktionsweise unserer Action-Cable-Instrumentation finden Sie auf unserer Action-Cable-Seite.AppSignal in einem Initializer konfigurieren
Wir empfehlen die Verwendung unsererconfig/appsignal.rb-Konfigurationsdatei oder von Umgebungsvariablen, um AppSignal zu konfigurieren.
Standardmäßig ist es nicht möglich, AppSignal aus einem Rails-Initializer heraus zu konfigurieren, da AppSignal vor den Initializern Ihrer Anwendung geladen wird, um Fehler melden zu können, die während der Initialisierung auftreten.
Um AppSignal in einem Rails-Initializer zu konfigurieren, konfigurieren Sie zunächst Rails so, dass AppSignal nach dem Ausführen der App-Initializer gestartet wird.
Appsignal.start nicht in den Initializern auf. Das Ruby-Gem startet AppSignal automatisch, wenn Rails alle Initializer ausgeführt hat.
Wenn eine Rails-App so konfiguriert ist, dass AppSignal nach dem Laden der Initializer gestartet wird, ist es nicht mehr möglich, Fehler aus Initializern beim Booten der Rails-App zu melden.
Fehlerberichterstattung aus Initializern
Standardmäßig meldet AppSignal Fehler, die in Controllern, Rake-Tasks und Active-Job-Jobs auftreten. Es meldet keine Fehler, die beim Starten der Anwendung auftreten, also vor den Rails-Initializern. Um auch über solche Fehler benachrichtigt zu werden, fügen Sie Folgendes zu Ihrerconfig.ru-Datei hinzu, in der Nähe der Zeile, die die environment.rb-Datei anfordert.
Backtrace-Cleaner
Mit der Rails-Integration lässt AppSignal den Backtrace jeder Ausnahme durch den Rails Backtrace-Cleaner laufen. Dieser Cleaner gibt Ihnen die Möglichkeit, unerwünschte Backtrace-Zeilen zu modifizieren oder herauszufiltern, um Unordnung und Rauschen aus dem Backtrace zu entfernen. Sie können Filter und Silencer zur Standardkonfiguration hinzufügen oder entfernen. Filter ändern die gegebene Zeile. Ein Beispiel wäre das Entfernen desRails.root-Präfixes.
Silencer entfernen die Zeile aus dem Backtrace, wenn der gegebene Ausdruck true zurückgibt. Sie können diese zusätzlichen Backtrace-Cleaner-Regeln in einem Initializer hinzufügen.
Zum Beispiel:
Error Reporter
AppSignal meldet standardmäßig Fehler, die überActiveSupport::ErrorReporter ausgelöst werden. ActiveSupport::ErrorReporter wurde in Rails 7.0 eingeführt, um die benutzerdefinierte Fehlerberichterstattung zu standardisieren.
Sie können diese Funktionalität mit der Konfigurationsoption enable_rails_error_reporter deaktivieren.
Wenn in dem Kontext, in dem ein Fehler über den Rails Error Reporter gemeldet wird, eine Transaktion aktiv ist, enthält dieser dieselben Metadaten und Sample-Daten wie die aktive Transaktion: Namespace, Action-Name, Tags, Custom Data, Parameter usw.
Namespace und Action aus der aktuellen Transaktion
Beim Melden von Fehlern bestimmen wir den Namespace und den Action-Namen, in dem der Fehler auftritt, wie z. B. einen Controller oder einen Background-Job, nach bestem Wissen. Der Incident-Namespace und der Action-Name werden nicht immer gesetzt oder sind genau. Wenn eine AppSignal-Transaktion aktiv ist (etwa bei einer Web-Anfrage oder einem Background-Job), hat der mitRails.error.handle/record gemeldete Fehler denselben Namespace, Action-Namen, dieselben Tags, Parameter, Custom Data usw. wie die aktive Transaktion. Wenn keine AppSignal-Transaktion aktiv ist, werden standardmäßig kein Namespace, Action-Name, keine Tags usw. gesetzt.
Namespace und Action aus dem Kontext
Wenn Sie den Namespace und den Action-Namen des gemeldeten Fehlers ändern möchten, ohne sie in der bereits aktiven AppSignal-Transaktion zu ändern, können Sie dies beim Aufruf des Error Reporters anpassen.Tags aus der aktiven Transaktion
Standardmäßig werden die Tags der Request-/Job-Transaktion aus der Request-/Job-Transaktion auf die AppSignal-Transaktion des Fehlers im Error Reporter kopiert.Tags aus dem Kontext
Sie können einem gemeldeten Fehler Tags hinzufügen, indem Siecontext im Aufruf von Rails.error.handle/record verwenden. Diese Tags werden nur für den mit den Methoden Rails.error.handle/record gemeldeten Fehler gesetzt.
Appsignal.add_tags.
Legacy-Verhalten Ruby Gem 3
In AppSignal für Ruby Gem Version 3 ist das Verhalten der Fehlerberichterstattung anders.- Mit der Methode
Rails.error.handlegemeldete Fehler werden an AppSignal gemeldet. - Mit
Rails.error.recordgemeldete Fehler werden nicht an AppSignal gemeldet, um zu vermeiden, dass der Fehler zweimal gemeldet wird, wenn er von unserer Rails-Fehlerberichterstattungs-Middleware gemeldet wird.
Einschränkungen bei der Kontextvererbung
In Ruby Gem 3 ist die Kontextvererbung aus der aktiven Transaktion eingeschränkt. Die Metadaten und einige der Sample-Daten werden nur dann kopiert, wenn sie zum Zeitpunkt des Aufrufs vonRails.error.handle/record gesetzt sind.
In der Praxis bedeutet dies, dass Rails-Controller und Active-Job-Jobs korrekt gemeldet werden. Für andere Bibliotheken wie Sidekiq-Jobs wird beim Melden von Fehlern mit Rails.error.handle kein Action-Name gesetzt.
Tags, die nach dem Aufruf von Rails.error.handle/record gesetzt werden, werden für den über diesen Helper gemeldeten Fehler nicht gemeldet.
Runners
AppSignal meldet automatisch Fehler innerhalb von Rails-Runners. Für die Instrumentation der Runner-Performance ist außerdem manuelles Setup erforderlich. Wir empfehlen, den Code des Runners in eine separate Datei zu schreiben und ihn mit dem HelperAppsignal.monitor zu umschließen, wie im folgenden Beispiel gezeigt.
Bash
enable_at_exit_hook auf true gesetzt ist (was auf Containern der Standardwert sein sollte). Dadurch wird sichergestellt, dass die Daten an den AppSignal-Agent gesendet werden, bevor der Runner beendet wird.