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. Es ist dasselbe Issue-Modell, das Ihre Back-end-Fehler verwenden, sodass alles, was Sie mit einer Exception aus Ruby oder Node.js bereits tun, auch hier funktioniert.

​
Wie Fehler gruppiert werden

Vorkommen desselben Fehlertyps auf derselben Route werden zu einem Issue. Ein Bug, der zehntausendmal auftritt, ist eine Sache zum Triagieren statt zehntausend Benachrichtigungen. Die Route ist die, die das SDK über setRouteTemplate() gemeldet hat, oder der Pfad der Seite, wenn nichts angegeben wurde. Deshalb ist das Angeben von Templates wichtig: Ohne sie sind /orders/1 und /orders/2 verschiedene Routen, und ein Bug zersplittert in ein Issue pro Bestellung.

​
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, was oft der schnellste Weg ist, eine Regression zu erkennen: ein neues Issue gegen Ihr neuestes Release ist ein Release, das Sie sich ansehen sollten.
  • 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.
Sie können nach dem neuesten Vorkommen oder nach Volumen sortieren, je nachdem, ob Sie triagieren, was gerade kaputtgegangen ist, oder was am häufigsten kaputtgeht.

​
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

Wenn Sie ein Issue öffnen, sehen Sie ein sample des Fehlers: wann er aufgetreten ist, auf welcher Seite und in welchem Deploy er zuerst erschien, dazu vier Dinge, von denen aus Sie debuggen.
  • Die Fehlermeldung, vollständig. Hier steckt die Bedeutung. TypeError sagt für sich genommen fast nichts, während Failed to fetch dynamically imported module Ihnen sagt, dass ein verzögert geladener Chunk nie angekommen ist.
  • Die Tags, die Sie mit setTags() gesetzt haben, angezeigt neben dem User Agent und der Revision, sofern Sie appVersion gesetzt haben. Einige Tag-Namen können mehr als filtern. Taggen Sie mit country_code oder browser, und Sie erhalten Attributverteilungen, die zeigen, welche Länder oder Browser die meisten Fehler sehen. Link-Templates verwandeln ein Tag in einen Link, sodass ein user_id-Tag diesen Nutzer in Ihrem eigenen Admin öffnen kann.
  • Den Backtrace, den Sie vollständig oder auf Ihre eigene Anwendung eingeschränkt lesen können. Front-end-Stacks bestehen oft fast ausschließlich aus Framework-Frames. Ein removeChild-Fehler aus React kommt als Wand von react-dom-Frames an, ohne dass etwas von Ihnen zu sehen ist, und die Anwendungsansicht schneidet genau das heraus.
  • Die Breadcrumb-Zeitleiste, die zum Fehler geführt hat, und meist ist das der Teil, der Sie rettet.
Jeder Breadcrumb enthält eigene Details. Ein Netzwerkeintrag zeigt die Methode, die URL, den Response-Status und wie lange der Request gedauert hat. Ein Klick-Eintrag zeigt, welches Element der Nutzer ausgewählt hat. Ein Long-Task-Eintrag nennt das Skript, das den Main Thread blockiert hat, und für wie lange. Eine Spur, die von einer Auswahl über einen GraphQL-Request, der fast drei Sekunden gedauert hat, bis zum Fehler selbst läuft, ist oft die ganze Erklärung, ohne dass Sie etwas reproduzieren müssen. Backtraces aus einem minifizierten Bundle werden über sourcemaps aufgelöst, abgeglichen über die App-Version. Ohne gesetzte Version bleiben Backtraces minifiziert. Ein sample lässt sich als JSON oder Markdown exportieren, was der schnellste Weg ist, es an ein Ticket zu hängen oder einem Assistenten zu übergeben. Jedes Issue hat außerdem ein Logbuch, in dem Sie und Ihr Team in Markdown notieren, was Sie herausgefunden haben.

​
Triage und Benachrichtigungen

Issues können zugewiesen, mit einem Status versehen, stummgeschaltet und mit eigenen Benachrichtigungseinstellungen konfiguriert werden, und der Rest von AppSignals Incident-Werkzeugen funktioniert ebenfalls damit. 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, beachten Sie: dessen Fehler wurden an frontend gemeldet, die dort konfigurierten Benachrichtigungseinstellungen werden also nicht übernommen. Mehr dazu im Migrationsleitfaden.

​
Fehler, die Sie hier nicht finden

Manche Fehler erreichen das SDK überhaupt nicht, darunter solche, die vor seiner Initialisierung ausgelöst werden, solche aus Cross-Origin-Skripten ohne CORS-Header und solche innerhalb von iframes. 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.