Skip to main content
Browser monitoring ist ein Beta-Feature von AppSignal Labs. Das Paket @appsignal/browser wird unter dem beta-Tag auf npm veröffentlicht, und seine Konfiguration und API können sich zwischen Beta-Releases noch ändern. Teilen Sie Ihr Feedback in unserer Discord-Community.
Die Errors-Ansicht listet die Fehler auf, die Ihr Front end gemeldet hat, gruppiert zu Issues. Sie verwendet dasselbe Issue-Modell wie Back-end-Fehler. Sie können sie auf dieselbe Weise triagieren und zuweisen.

​
Wie Fehler gruppiert werden

AppSignal gruppiert verwandte Fehler anhand der gemeldeten Route und der Gruppierungseinstellungen Ihrer Anwendung zu Issues. Wiederholte Vorkommen können als ein einzelnes Issue zum Triagieren erscheinen. Die Route ist die, die das SDK über setRouteTemplate() gemeldet hat, oder der Pfad der Seite, wenn nichts angegeben wurde. Ohne Template sind /orders/1 und /orders/2 unterschiedliche Fehlerrouten. Ein Bug kann so zu zwei Issues werden.

​
Die Issue-Liste lesen

Jedes Issue in der Liste enthält:
  • Die Fehlerklasse und die Meldung, mit der Route, auf der der Fehler aufgetreten ist.
  • Die Version, in der er eingeführt wurde. Wenn er zuerst in Ihrem neuesten Release auftaucht, prüfen Sie dieses Deploy.
  • Einen Trend für den gewählten Zeitraum, sodass sich eine Spitze anders liest als ein gleichmäßiges Tröpfeln.
  • Die Gesamtzahl der Vorkommen im Zeitraum.
  • Wann er zuletzt gesehen wurde.
  • Wem er zugewiesen ist.
Sortieren Sie nach dem neuesten Vorkommen, um neue Fehler zu finden. Sortieren Sie nach Volumen, um häufige zu finden.

​
Nach Zeit und Version filtern

  • Zeitraum. Voreinstellungen von einer Stunde bis 30 Tage oder ein eigener Zeitraum.
  • Version. Beschränken Sie die Liste auf die Fehler, die ein einzelnes Release gemeldet hat. Kombiniert mit der Spalte „Eingeführt in” bestätigen Sie damit, ob ein Deploy verantwortlich ist.

​
Ein Issue untersuchen

Öffnen Sie ein Issue, um ein sample zu betrachten: ein Mal, als der Fehler im Browser eines Nutzers aufgetreten ist. Das sample liefert Ihnen die Fehlermeldung und was drumherum passiert ist.
  1. Lesen Sie die Meldung. Sie sagt Ihnen, was fehlgeschlagen ist. POST https://api.example.com/orders: HTTP 503 bedeutet zum Beispiel, dass die Checkout-API einen Serverfehler zurückgegeben hat.
  2. Prüfen Sie den Backtrace auf JavaScript-Fehler. Er zeigt, wo der Fehler in Ihrem Code aufgetreten ist. Wenn Sie minifizierten Code statt lesbarer Dateinamen und Zeilen sehen, laden Sie sourcemaps hoch für die in appVersion gesetzte Version.
  3. Lesen Sie die Breadcrumbs. Sie zeigen Ereignisse vor dem Fehler, etwa eine Button-Auswahl oder einen Netzwerk-Request. Wenn der Nutzer Pay ausgewählt hat, kurz bevor /orders drei Sekunden brauchte, prüfen Sie zuerst diesen API-Request.
  4. Prüfen Sie Version und Tags. Vergleichen Sie die Version des samples mit Ihren letzten Deploys. Nutzen Sie mit setTags() gesetzte Tags, um einzugrenzen, wer betroffen war.
Ein fehlgeschlagener API-Request, der als HTTPError oder TimeoutError gemeldet wird, hat keinen JavaScript-Backtrace. Wählen Sie auf der vollständigen Issue-Seite Traces und dann Fullscreen in der Karte Trace timeline, um seinen Browser-Span zu untersuchen. Hat das Back end den Trace fortgesetzt, erscheinen seine Spans dort ebenfalls. Nutzen Sie im Seitenpanel „Browser Errors” Open full trace page, um zur vollständigen Issue-Seite zu gelangen. Sie können ein sample als JSON oder Markdown exportieren, um es mit Ihrem Team zu teilen. Nutzen Sie das Logbuch des Issues, um festzuhalten, was Sie herausgefunden haben.

​
Triage und Benachrichtigungen

Sie können diese Issues zuweisen, stummschalten und ihren Status ändern. Sie unterstützen außerdem Benachrichtigungseinstellungen. Mehr dazu unter Errors. Weil Front-end-Fehler im browser-namespace liegen, sind diese Einstellungen von Ihren Back-end-Einstellungen getrennt. Wenn Sie von @appsignal/javascript migrieren, richten Sie Benachrichtigungen für browser ein. Einstellungen für frontend werden nicht übernommen. Mehr dazu im Migrationsleitfaden.

​
Fehler, die Sie hier nicht finden

Manche Fehler erreichen das SDK nie. Dazu gehören Fehler vor init() und Fehler innerhalb nicht instrumentierter iframes. Undurchsichtige Cross-Origin-Skriptfehler werden verworfen. Für jeden gibt es einen Workaround, aufgeführt unter Fehler, die nicht gemeldet werden. Wenn ein erwarteter Fehler fehlt, arbeiten Sie die Fehlerbehebung durch.