Actions
Actions sind der Ort im Code, an dem eine HTTP-Anfrage, ein Background-Job, ein Cronjob oder eine Aufgabe gestartet wird. Für Apps mit Ruby on Rails und Elixirs Phoenix ist dies die Kombination aus Controller und Action, wie z. B.BlogPostsController#create oder Api::UsersController#index. Für Background-Jobs ist dies der Worker-/Job-Name, wie z. B. UserMailer#sign_up_mail.
Actions werden zusammen mit dem Namespace und Error zur Gruppierung von Issues verwendet.
Agent
AppSignal verwendet einen “Agent”, um mit den AppSignal-Servern zu kommunizieren und die Hosts zu instrumentieren, auf denen eine Anwendung läuft. Die Host-Daten werden in unserer Host-Metriken-Funktion verwendet. Der Agent wird von der sprachspezifischen Bibliothek gestartet und läuft als separater UNIX-Prozess auf dem Host der Anwendung. Die Sprachbibliothek und der Agent kommunizieren miteinander über einen UNIX-Socket mithilfe einer Erweiterung. Die vom Agent gesammelten Transaktions-Instrumentierungsdaten werden an die AppSignal-Server gesendet. Die Transaktions-Daten werden verarbeitet und verwendet, um Ereignisse zu erkennen, die es wert sind, Benutzer zu alarmieren. Lesen Sie mehr darüber, wie der AppSignal-Agent funktioniert und über den Lebenszyklus einer AppSignal-Anfrage.Allocations
Während einer HTTP-Anfrage oder eines Background-Jobs verwendet eine Anwendung Speicher. Jede Datenstruktur, die geladen wird, und jedes Objekt, das instanziiert wird, beansprucht Speicher. Wenn eine Anfrage oder ein Job viele Daten verarbeitet, kann viel mehr Speicher verwendet werden, als normal ist. Die AppSignal-Integrationsbibliotheken verfolgen Allokationen pro Transaktion. Die Integration verfolgt auch, welcher Teil der Anwendung mehr Speicherobjekte allokiert als andere, sodass sichtbar ist, ob das ORM oder die Template-Bibliothek der Anwendung mehr Speicher beansprucht. Auf AppSignal.com wird die Anzahl der Allokationen als Integer für eine Action, Event-Gruppen und spezifische Events angezeigt. Diese Allokationszahl ist die Anzahl der Objekte, die während einer Action/Gruppe/eines Events im Speicher erstellt wurden. Die Größe des erstellten Objekts wird nicht verfolgt.Anomaly Detection
Anomaly Detection ist eine AppSignal-Funktion, mit der Benutzer Anomalien in ihren Apps erkennen können. Eine Anomalie könnte z. B. eine erhöhte Fehlerrate oder eine begrenzte Menge an freiem Speicher auf dem Host der App sein. Anomaly Detection funktioniert mit Trigger-Schwellenwertbedingungen, die Alerts erstellen, wenn ihr Schwellenwert erreicht wird. Wenn ein Alert geöffnet wird, sendet AppSignal Benachrichtigungen an die für den jeweiligen Trigger ausgewählten Notifier. Weitere Informationen finden Sie in unserer Dokumentation zu Anomaly Detection.API
Eine API ist eine “Application Programming Interface”. Der Begriff API ist weit gefasst und wird auf viele Arten verwendet. Im Kontext unserer Dokumentation beziehen wir uns mit “API” auf die AppSignal HTTP REST API. Die AppSignal API ist eine HTTP REST API, die verwendet werden kann, um Daten von den AppSignal-Servern abzurufen und die vorhandenen Daten mit weiteren Informationen wie Markers zu ergänzen. Die API unterscheidet sich von der Push-API in ihrem Zweck. Während die Push- API verwendet wird, um Daten vom Agent an AppSignal zu senden, wird die HTTP REST API hauptsächlich verwendet, um Daten von AppSignal abzurufen. Dies ermöglicht es Benutzern, die verfügbaren Daten in anderen Tools zu verwenden. Sie können mehr über unsere API in unserer API-Dokumentation lesen.API-Schlüssel
Um sich mit der AppSignal-API zu verbinden, ist es notwendig, authentifiziert zu sein. Jeder Benutzer hat seinen API-Schlüssel zur Authentifizierung bei AppSignal. Ihr API-Schlüssel kann auf Ihrem Benutzer- profil gefunden werden. Dieser Schlüssel sollte nicht mit dem Push-API-Schlüssel verwechselt werden, der von Anwendungen mit einem installierten AppSignal-Agent verwendet wird.Applications
Applications (früher bekannt als “Sites”, auch als “Apps” bezeichnet) sind Ruby- und Elixir-Anwendungen, die von AppSignal überwacht werden. Nach der Installation der AppSignal-Bibliothek in einer Anwendung beginnt AppSignal mit der Überwachung dieser Anwendungen. Sobald wir Daten von einer Anwendung empfangen, registrieren wir sie unter dem Anwendungsnamen und der Umgebung, in der sie läuft. Eine Anwendung kann mehrere Umgebungen haben, solange jede Umgebung denselben Namen verwendet.- “Demo-Anwendung” - Development
- “Demo-Anwendung” - Production
- “Demo-Anwendung” - Staging
- “Demo-Anwendung” - Test
AppSignal vs Appsignal vs appsignal
Moment, sind das drei verschiedene Schreibweisen des AppSignal-Namens? Ja! Lassen Sie uns das erklären:| Schreibweise | Verwendung |
|---|---|
AppSignal | Der Markenname des Unternehmens, der Anwendung und fast aller anderen Dinge im Zusammenhang mit AppSignal. Dies ist die Version, die Sie verwenden sollten, wenn Sie über AppSignal als Marke, Produkt oder Dienst oder Stroopwafel-Lieferant sprechen. |
Appsignal | Der Bibliotheksname unserer AppSignal-Integrationen (Ruby-Integration, Elixir-Integration, Node.js-Integration, Front-End-Integration usw.). Wird nur im Code-Kontext verwendet. |
appsignal | Die AppSignal-Integrationspaketnamen, wie sie in Paketverwaltungs-Registries veröffentlicht sind, für das Ruby-Gem, den Elixir-Paket- und Paketpräfix--Namen, den Node.js-Paketpräfix und den Front-End-Paketpräfix usw. |
Blog
Wir haben einen Blog unter blog.appsignal.com! In unserem Blog veröffentlichen wir alle Dinge, die für AppSignal relevant sind, wie neue Funktionen, neue große Agent-Releases, Ruby Magic-Artikel und andere großartige Geschichten aus unserem internen Prozess. Wie zum Beispiel wie man Stroopwafels isst.Changelog
Wir führen einen vollständigen Produkt-Changelog auf appsignal.com/changelog. Alle unsere neuen Funktionen, Agent-Releases und anderen Änderungen am Produkt sind in dieser ordentlich organisierten Liste zu finden. Wir haben auch einen kleinen Indikator in unserer oberen Navigation, der Sie benachrichtigt, wenn es einen neuen Eintrag im Changelog gibt.Configuration
Die Konfiguration ist Teil der Bibliotheken, die in Anwendungen laufen. Sie teilt den AppSignal-Bibliotheken mit, was in einer Anwendung zu instrumentieren ist, um welche Anwendung es sich handelt und in welcher Umgebung sie läuft. Die AppSignal-Bibliotheken haben mehrere Konfigurationsmethoden. Die häufigste Konfigurationsmethode ist die Verwendung einerappsignal.yml-Konfigurationsdatei.
Die Verwendung von Umgebungsvariablen wird ebenfalls empfohlen.
Für die Konfiguration des Ruby-Agents empfehlen wir Ihnen, das
Konfigurations-Topic zu lesen, um loszulegen.
CPU-Auslastung
Während des Betriebs einer Anwendung kann die CPU-Auslastung stark variieren. Einige Operationen einer Anwendung können mehr CPU-Zeit anfordern als andere. Andere Faktoren können die CPU-Auslastung ebenfalls beeinflussen. Wenn die überwachte Anwendung nicht der einzige Prozess auf der Host-Maschine ist, können auch andere Prozesse die CPU-Auslastungsmetrik beeinflussen. Wenn zum Beispiel eine auf derselben Maschine laufende Datenbank eine komplizierte Abfrage durchführen muss, fordert sie mehr CPU-Zeit an. Auf AppSignal.com wird die CPU-Auslastung einer Anwendung auf zwei Arten angezeigt. Für eine Action, bei der ein Fehler/Performance-Problem aufgetreten ist, und für Host-Metriken. Auf diese Weise ist es möglich zu sehen, ob die Performance einer Action direkt durch eine ausgelastete CPU beeinflusst wurde oder ob der gesamte Host für längere Zeit betroffen war. Erfahren Sie mehr darüber, was CPU-Metriken in unserem Blog bedeuten.Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) ist ein Angriff, der einen Endbenutzer dazu zwingt, ungewollte Aktionen in einer Webanwendung auszuführen, in der er authentifiziert ist. Ein Opfer kann auf einen Link klicken, der ihm per E-Mail oder Webchat zugesendet wurde, sodass der Angreifer die Anmeldedaten des Opfers stehlen und verwenden kann. Die Schwere des Angriffs kann je nach Anwendung und Berechtigungsstufe des Opferkontos variieren. Ein Angreifer kann zustandsändernde Aktionen am Konto eines Benutzers vornehmen, z. B. die Anmeldedaten ändern, und kann in schweren Fällen eine gesamte Anwendung kompromittieren, z. B. wenn ein Opfer ein Administrator ist.Elixir Alchemy
Möchten Sie mehr über Elixir erfahren? In unserer E-Mail-Serie Elixir Alchemy (1x p/Mo) tauchen wir tiefer in Elixir und Erlang ein. Sie können sich hier anmelden: appsignal.com/elixir-alchemy.Environments
Die meisten Anwendungen können in verschiedenen Modi ausgeführt werden. Während der Entwicklung einer Anwendung gelten andere Regeln, und Fehler werden normalerweise nicht in Form einer “500 internal server error”-Seite angezeigt, wie sie es in “production” tun. AppSignal versteht ebenfalls das Konzept einer Umgebung und ermöglicht es, unterschiedliche Einstellungen pro Umgebung zu konfigurieren. Für jede Umgebung wird eine separate Anwendung auf AppSignal.com erstellt, die mit eigenen Alarmierungsregeln und Drittanbieter- Integrationen konfiguriert werden kann.Errors
Fehler sind Probleme, die während der Laufzeit einer Anwendung auftreten. Dies kann alles sein, von einem katastrophalen Ausfall, der die Anwendung zum Absturz bringt, bis zu einem einfachen Tippfehler, der eine Fehlerseite verursacht. Sobald ein Fehler in einer Anwendung auftritt, sendet AppSignal einen Alert und zeichnet die Details des Fehlers zur späteren Ansicht auf AppSignal.com auf. Lesen Sie mehr über die Fehlerfunktion auf unserer Tour-Seite. Um mehr über die Fehlerbehandlung in Ruby zu erfahren, lesen Sie unser Exception Handling-Thema, das beschreibt, wie Sie Fehler mit AppSignal effektiv verfolgen. Fehler werden als Issues gemeldet. Erfahren Sie mehr darüber, was Issues sind.Events
Ein Event ist etwas, das passiert ist. Dies ist eine sehr vage Aussage, denn das Konzept eines Events ist etwas sehr Hochrangiges. Ein Error ist ein Event, und ein Performance-Issue ebenfalls. AppSignal überwacht viele Events innerhalb einer Anwendung und auf einem Server mithilfe von Host- Metriken. Durch das Sammeln vieler verschiedener Arten von Events und das Kombinieren der Daten hoffen wir, ein möglichst vollständiges Bild zu liefern, um mehr Einblicke in die Performance von Anwendungen zu gewinnen. Siehe auch Dokumentation zu Instrumentierungs-Events.Extension
Die AppSignal-Bibliotheken und der Agent stehen in ständiger Kommunikation miteinander. Die Bibliotheken senden Daten über einen UNIX-Socket an den Agent. Dazu verwenden die Bibliotheken eine Erweiterung für die Programmiersprache, in der sie geschrieben sind. Diese Erweiterung ist in C und Rust geschrieben und wird installiert, wenn der sprachspezifische Agent installiert wird. Lesen Sie mehr darüber, wie die AppSignal-Erweiterung funktioniert und über den Lebenszyklus einer AppSignal-Anfrage.Impact
Der Impact einer Action auf eine Anwendung basiert auf ihrer Nutzung im Vergleich zu anderen Actions. Wenn eine Controller-Action oder ein Job mehr Zeit benötigt oder häufiger ausgeführt wird als andere, wächst sein Impact. Zum Beispiel:- Action A wird 1000 Mal ausgelöst mit einer durchschnittlichen Dauer von 0,5 Sekunden. Die kombinierte Dauer beträgt 500 Sekunden.
- Action B wird 500 Mal ausgelöst mit einer durchschnittlichen Dauer von 3 Sekunden. Die kombinierte Dauer beträgt 1500 Sekunden.
- Action A hat einen Impact von 25 % (500 / 2000).
- Action B hat einen Impact von 75 % (1500 / 2000).
Instrumentation
Instrumentation ist das, was AppSignal antreibt. Ohne sie wüssten wir nichts darüber, was in Anwendungen vor sich geht. Instrumentation sind Hooks innerhalb oder um Frameworks und Bibliotheken, die AppSignal verwendet, um Anwendungscode zu überwachen. Diese Instrumentation meldet Fehler und langsamen Code, der zur Analyse an AppSignal gesendet wird. Sobald ein Problem erkannt wird, wird ein Alert gesendet. Erfahren Sie mehr über Ruby Instrumentation.Instrumentation-Events
Events sind Codeblöcke, die ausgeführt werden. Dies können Methoden, Funktionen oder kleinere Teile davon sein. Events können verschachtelt werden, um Hierarchien und die Gesamtdauer von Operationen darzustellen. Diese einzelnen Events ermöglichen es zu sehen, welche Teile des Codes langsamer sind als andere. Oben auf den Issue-Seiten gruppieren wir die Event-Dauern auch nach Gruppennamen, gemäß unserer Event-Benennung, um Einblicke zu geben, welcher Teil der App am längsten dauert. Einige Arten von Events, die angezeigt werden können, sind Datenbankabfragen, JSON-Parsing, View-Rendering, HTTP-Anfragen, benutzerdefinierte Instrumentation usw. Jedes Event wird auf den Detailseiten von Performance-Issues in der “Performance Timeline” angezeigt. Wenn wir erkennen, dass dasselbe Event mehrmals hintereinander wiederholt wird, markieren wir sie als potenzielle N+1-Events, wie z. B. N+1-Queries. Siehe auch Instrumentation.Issues
Wann immer AppSignal einen neuen Fehler erkennt, wird ein Issue erstellt. Wann immer AppSignal eine neue potenziell langsame Anfrage, einen Background-Job usw. erkennt, wird ein neues Issue erstellt. Dieses Issue wird nach Action, Namespace und Error gruppiert. Error-Issues unterstützen auch Fehler ohne Action, da ein Fehler außerhalb einer Action auftreten kann, z. B. im Framework der App, bevor der eigene Code der App erreicht wird. Performance-Issues ohne Action werden stillschweigend ignoriert. Die Action, der Namespace und der Fehlertyp sind die Art und Weise, wie wir Issues gruppieren. Wenn ein Fehler eines neuen Typs in derselben Action im selben Namespace auftritt wie ein anderer Error-Issue, wird ein neues Issue für diesen Fehler erstellt. Wenn eine weitere potenziell langsame Anfrage auf einem anderen Endpoint oder Background-Job erkannt wird, wird ein neues Issue für diesen Endpoint/Job erstellt. Pro Issue ist es möglich, Benachrichtigungseinstellungen, Zuweisungen, Status (offen/geschlossen/in Bearbeitung) und Schweregrad zu konfigurieren.Libraries
AppSignal verwendet sprachspezifische Bibliotheken zur Überwachung von Anwendungen. Derzeit haben wir ein Ruby-Gem und ein Elixir- Paket. Diese Bibliotheken enthalten Hooks in Frameworks und Bibliotheken, um Codeblöcke wie Datenbankaufrufe, Dateisystemaufrufe und View- Rendering zu instrumentieren. Jede Bibliothek ist auf die Instrumentation ihrer jeweiligen Sprache spezialisiert. Die meisten AppSignal-Bibliotheken enthalten auch einen “Agent”, den die Bibliotheken verwenden, um mit den AppSignal-Servern zu kommunizieren. Lesen Sie mehr darüber, wie der AppSignal-Agent funktioniert und über den Lebenszyklus einer AppSignal-Anfrage.Bibliotheksintegrationen
AppSignal-Bibliotheken integrieren sich mit einer Vielzahl von verschiedenen Bibliotheken und Frameworks, die für die Programmiersprache spezifisch sind. Das Ruby-Gem integriert sich mit reinem Ruby, Rails, Sinatra und anderen verfügbaren Frameworks. Das Elixir-Paket integriert sich mit reinem Elixir und Phoenix. Diese automatischen Integrationen erleichtern es, mehr Einblicke in Anwendungen zu erhalten, ohne AppSignal-Instrumentation manuell hinzufügen zu müssen. Lesen Sie mehr darüber, welche Ruby-Integrationen wir anbieten.Markers
Markers sind kleine Icons, die in Grafiken auf AppSignal.com verwendet werden, um eine Änderung anzuzeigen. Dies kann ein Code-Deploy mit einem “Deploy-Marker” oder ein besonderes Ereignis mit einem “Custom-Marker” sein. Diese Custom-Marker können alles sein, von Skalierungsoperationen, plötzlichen Traffic-Spitzen oder wenn eine Datenbank Probleme hat. Lesen Sie mehr über Markers.Metadaten
Metadaten sind Daten, die Informationen über andere Daten geben. Metadaten sind Informationen über einen Fehler oder ein Performance-Issue, die mehr Kontext zu den gesammelten Daten liefern. Indem zusätzliche Metadaten zu einem Sample gesendet werden, ist es einfacher, die Umstände des jeweiligen Problems nachzuvollziehen. Standardmäßig enthalten die Metadaten einer Anfrage den Hostnamen, auf dem das Problem aufgetreten ist, die SCM-Revision, auf der die Anwendung läuft, und die Request-ID der Anfrage, von der das Sample abgeleitet wurde. Sie enthalten auch Daten wie den Anfragepfad und die Anfragemethode für Webanfragen.Metrics
AppSignal bietet zwei Arten von Metriken. Custom Metrics ermöglichen die Erfassung von Daten aus nahezu allem. Mit ein paar Zeilen Code ist es möglich, Daten wie die Anzahl der registrierten Benutzer, Seitenaufrufe, Datenbankgrößen usw. zu verfolgen und zu grafisch darzustellen. Host Metrics beziehen sich auf Daten vom Server, auf dem eine Anwendung läuft. Daten wie CPU-Auslastung, Load Averages, Speichernutzung usw. geben mehr Einblick in Performance-Probleme als nur der Code selbst. Vielleicht geht der Speicherplatz zur Neige und verursacht, dass die Anwendung viel langsamer läuft. Lesen Sie mehr über Metrics auf unserer Tour-Seite.Namespace
Namespaces sind Gruppierungsmechanismen, die von AppSignal verwendet werden, um zwischen verschiedenen Teilen derselben Anwendung zu unterscheiden. Standardmäßig teilt AppSignal eine Anwendung in zwei Namespaces auf: “Web” und “Background”. HTTP-Anfragen, die von AppSignal überwacht werden, werden dem “Web”- Namespace hinzugefügt, und Jobs, die von Background-Job-Bibliotheken ausgeführt werden, werden dem “Background”-Namespace hinzugefügt. Es ist auch möglich, Ihre Namespaces so zu konfigurieren, dass sie zwischen Anfragen an eine Anwendung und einem privaten Administrationspanel unterscheiden. Weitere Informationen zu Namespaces finden Sie in unserer Namespaces-Dokumentation.Benachrichtigungen
AppSignal sendet Benachrichtigungen, wenn ein Problem mit einer Anwendung erkannt wird. Diese Benachrichtigungen können E-Mail-Nachrichten, Slack-Nachrichten, eine PagerDuty-Benachrichtigung und mehr sein, abhängig davon, welche Drittanbieter-Integrationen konfiguriert sind. Wir senden Benachrichtigungen über Errors, Slow Requests und Anomaly Detection-Alerts, die in einer Anwendung mit einer AppSignal-Bibliothek auftreten. Sobald ein problematisches Ereignis erkannt wird, wird eine Benachrichtigung gesendet, um Benutzer auf ein Problem aufmerksam zu machen.Organizations
Organisationen werden verwendet, um Anwendungen und Benutzer für ein Unternehmen zu gruppieren. Ein Unternehmen kann viele Benutzer und Kunden haben, die benachrichtigt werden können, wann immer es ein Problem mit ihren Anwendungen gibt. Die Abrechnung für Anwendungen erfolgt auf Organisationsebene und nicht pro Anwendung. Die Team-Verwaltung wird mit Organisationen einfach gemacht. Ganze Teams können in eine Organisation eingeladen werden, sodass keine Anmeldedaten geteilt werden müssen. Lesen Sie mehr über Organisationen in unserer Organisations- Dokumentation.Owners
Organisationen haben Personen, die die Organisation verwalten. Diese Owners entscheiden, wer Mitglied einer Organisation ist, in welchem Team sie sich befinden oder nicht, und entscheiden, wie die Abrechnung erfolgt. Organisations-Owners können alles über eine Organisation und die dazugehörigen Anwendungen verwalten. Wenn Sie keine Berechtigung haben, etwas anzuzeigen oder zu ändern, bitten Sie den Owner Ihrer Organisation, es für Sie zu ändern oder Ihnen mehr Berechtigungen zu geben.Performance-Issues
Mit Performance-Monitoring ist es möglich, in einzelne Anfragen einzutauchen und zu sehen, welche Teile einer Anwendung langsam sind. Mit diesen Informationen ist es möglich, Problembereiche zu finden und zu verbessern. Wenn AppSignal eine langsame Webanfrage oder Operation erkennt, sendet es Benachrichtigungen, da langsamer Code genauso schädlich sein kann wie ein erscheinender Error. Performance-Issues werden nach Action und Namespace gruppiert. Auf den Detailseiten von Performance-Issues sind weitere Informationen zu jeder Action verfügbar. Nicht alle Issues sind ein “Issue”. Es liegt an Ihnen zu bestimmen, ob eine HTTP-Anfrage von 200ms zu langsam ist. Potenziell langsame Anfragen und Background-Jobs werden als Performance-Issues gemeldet. Erfahren Sie mehr darüber, was Issues sind. Lesen Sie mehr über die Performance-Funktion auf unserer Tour-Seite.Push-API
Die AppSignal “Push-API” ist der API-Endpunkt, der vom AppSignal- Agent verwendet wird, um die gesammelten Daten zu senden. Dies unterscheidet sich von der normalen AppSignal-API, die hauptsächlich zum Lesen von Daten und zum Hinzufügen von mehr Kontext zu den an AppSignal gesendeten Daten verwendet wird. Diese Push-API ist die API, an die Anwendungs-Instrumentation von Anwendungen gesendet wird, die den Push-API-Schlüssel verwenden.Push-API-Schlüssel
Der “Push-API-Schlüssel” ist ein Nur-Schreib-API-Schlüssel, der von Anwendungen verwendet wird, um sich beim Senden von Daten an die AppSignal-Server zu authentifizieren. Apps melden Daten an die Push-API und authentifizieren sich mit diesem Schlüssel. Es gibt verschiedene Arten von Push-API-Schlüsseln, die Apps für unterschiedliche Anwendungsfälle verwenden können. Alle Push-API-Schlüssel sind auf der Push & Deploy-Einstellungsseite zu finden.- Push-API-Schlüssel auf Organisationsebene: Der empfohlene Push-API-Schlüssel für Back-End-Integrationen wie Ruby, Elixir, Node.js, Python und Go. Wir erkennen Apps anhand einer Kombination aus Push-API-Schlüssel, App-Name und App-Umgebung und erstellen Apps anhand dieser Informationen, wenn sie noch nicht existieren.
- Push-API-Schlüssel auf App-Ebene: Nach der Erstellung wird einer App auch ihr Push-API-Schlüssel auf App-Ebene zugewiesen. Dieser Schlüssel kann verwendet werden, um Daten an eine bestimmte App zu senden, auch wenn die App so konfiguriert ist, dass sie einen anderen App-Namen oder eine andere App-Umgebung verwendet. Dies wird verwendet, wenn Apps ohne Datenverlust zwischen Organisationen verschoben werden oder wenn kein App-Name oder keine App-Umgebung gesetzt werden kann, wie z. B. bei der Vector-Integration.
- Front-End-API-Schlüssel: Dieser Schlüssel wird von Apps verwendet, die unsere Front-End-Integration verwenden, um Daten zu melden, und ist im Abschnitt “Front-end error monitoring” zu finden.