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.
Sobald init() gelaufen ist, meldet AppSignal für Browser nicht abgefangene Fehler von selbst. Es gibt nichts zu umwickeln und keinen Handler zu registrieren. Es hört auf zwei Dinge am window der Hauptseite:
  • Fehler, die Ihr Code auslöst und nie abfängt, über das error-Event.
  • Promises, die fehlschlagen, ohne dass etwas den Fehler behandelt, über das unhandledrejection-Event.
Das SDK beginnt mit dem Senden jedes Fehlers, sobald er erfasst wird, ohne auf einen Web-Vitals-Batch zu warten. Die Zustellung hängt weiterhin von Browser und Netzwerk ab.

Was gemeldet wird

  • Fehlername und Meldung. Die Art des Fehlers, zum Beispiel TypeError, und die Meldung, mit der er kam.
  • Backtrace. Der Stacktrace, eine Zeile pro Frame. Leer, wenn der Browser keinen liefert.
  • Action. Die Route, auf der der Fehler aufgetreten ist. Fehler werden danach gruppiert.
  • Revision. Die von Ihnen gesetzte appVersion. Wird verwendet, um nach Version zu filtern und die richtigen sourcemaps zu finden.
  • Tags. Alles, was Sie mit setTags() gesetzt haben.
  • Dienstname. Der von Ihnen gesetzte serviceName, oder Browser. Er kennzeichnet das Frontend unter den Services eines Trace.
  • Breadcrumbs. Bis zu 25 aktuelle Breadcrumbs, die den Fehler erklären helfen.
  • URL und User Agent. Die Seite, auf der der Fehler aufgetreten ist, mit Query-Parametern, die gemäß Ihrer Allowlist entfernt wurden, und der User Agent des Browsers.
Ein abgelehntes Promise kann einen anderen Wert als einen Error enthalten. Das SDK wandelt diesen Wert nach Möglichkeit in eine Fehlermeldung um. Fehler werden an den browser-namespace gemeldet, wodurch sie von Ihren Back-end-Fehlern und deren Benachrichtigungseinstellungen getrennt bleiben.

Wie Fehler gruppiert werden

Fehler gruppieren sich nach Action. Das ist das Template, das mit setRouteTemplate() gesetzt wurde, oder der rohe Seitenpfad, wenn keines gesetzt wurde. Ein Template anzugeben verhindert, dass eine Route voller IDs in eine Fehlergruppe pro ID zersplittert:
Rufen Sie es bei jeder Router-Navigation auf. Es ist derselbe Wert, dem web vitals zugeordnet werden, ein Aufruf deckt also beides ab.

Fehler manuell melden

Verwenden Sie captureError() für Fehler, die Sie selbst abfangen. Es läuft durch dieselbe Pipeline wie ein nicht abgefangener Fehler, einschließlich Breadcrumbs, Tags, sampling und beforeError:
Das aktuelle SDK akzeptiert ein zweites Kontext-Argument, nimmt es aber nicht in gewöhnliche Fehlerberichte auf. Verwenden Sie setTags() für Werte, die bei nachfolgenden Fehlern erscheinen sollen. React-Anwendungen können Render-Fehler mit der Error Boundary abfangen, statt Komponenten von Hand zu umwickeln.

Fehlgeschlagene Requests

Mit gesetztem tracePropagationTargets wird ein Request an Ihre API, der mit 5xx antwortet oder in ein Timeout läuft, eigenständig gemeldet. Er kommt als HTTPError oder TimeoutError an und trägt die Trace-ID, die der Request an das Back-end gesendet hat. Wenn das Back-end den Trace fortgesetzt hat, erscheinen dessen Spans in der Trace-Zeitleiste unterhalb des Browser-Fehlers. Mehr dazu unter verteiltes Tracing für Browser.

Tags

Tags sind String-Schlüssel-Wert-Paare, die von diesem Punkt an jedem gemeldeten Fehler angehängt werden. Nach ihnen filtern und suchen Sie Fehler in AppSignal:
Jeder Aufruf ergänzt die bereits gesetzten Tags, statt sie zu ersetzen. Werte werden zu Text. Ein leerer Wert entfernt das jeweilige Tag. Sie können bis zu 32 Tags gleichzeitig behalten; das älteste wird bei Bedarf entfernt. Lange Werte werden beim Eingang auf 256 Bytes gekürzt. Mehr dazu in unserem Leitfaden zum Tagging. Einige Tag-Namen können mehr als filtern. Die Tags country_code, country und browser erzeugen Attributverteilungen. Jedes Tag lässt sich mit Link-Templates in einen Link verwandeln.

Rate-Limits

Eine Seite, die in einer Schleife feststeckt, kann tausende Fehler pro Sekunde auslösen. Zwei Limits verhindern, dass das SDK zu dem Problem wird, das es melden soll:
  • Derselbe Fehler immer wieder. Die Meldung und die erste Zeile des Stacktrace bestimmen, ob zwei Fehler Wiederholungen sind. AppSignal meldet ihn höchstens fünfmal alle 10 Sekunden.
  • Zu viele Fehler auf einmal. Insgesamt werden nicht mehr als 100 Fehler alle 10 Sekunden gemeldet. Das fängt eine Seite ab, die viele verschiedene Fehler auslöst, was dem ersten Limit entgehen würde.
Wenn Fehler verloren gehen, während sich eine Seite schlecht verhält, liegt es an einem dieser beiden. Um absichtlich weniger Fehler zu senden, setzen Sie stattdessen errors.sampleRate.

Sourcemaps

Ein minifiziertes Bundle erzeugt Stacktraces voller Ein-Buchstaben-Namen und enormer Zeilennummern. Sourcemaps machen daraus wieder die Dateinamen, Funktionen und Zeilennummern, die Sie geschrieben haben. Jeder Fehler sendet appVersion als seine Revision. AppSignal nutzt sie, um die sourcemaps für diesen Build zu finden. Ohne sie bleiben Stacktraces minifiziert. Wenn Ihre sourcemaps öffentlich sind und neben Ihren JavaScript-Dateien liegen, ist nichts weiter zu tun. Wenn Sie sie lieber nicht veröffentlichen, laden Sie sie mit derselben Revision zum sourcemaps-API-Endpoint hoch.

Fehler, die nicht gemeldet werden

Manche Fehler erreichen das SDK nie. Die meisten davon sind Einschränkungen des Browsers und keine Grenzen von AppSignal, und für jeden gibt es einen Workaround.
Fehler aus Skripten auf einer anderen Domain. Wenn ein Skript, das von woanders geladen wurde, einen Fehler auslöst, verweigert der Browser die Details. Ihre Seite sieht nur die Meldung Script error., ohne Stacktrace und ohne Zeilennummer. Das SDK verwirft diese undurchsichtigen Fehler, weil sie keine brauchbaren Details enthalten. Um CDN-Skriptfehler zu erfassen, senden Sie einen Access-Control-Allow-Origin-Header vom CDN. Fügen Sie crossorigin="anonymous" zu den Script-Tags hinzu. Fehler innerhalb von iframes. Das SDK hört nur auf das window, in dem es läuft. Um ein iframe zu überwachen, das Ihnen gehört, initialisieren Sie das SDK auch in diesem Frame. Die übergeordnete Seite kann keine Fehler aus einem Cross-Origin-iframe erfassen. Fehler vor init(). Alles, was ausgelöst wird, bevor init() läuft, wird verpasst. Importieren Sie Ihr AppSignal-Setup zuerst, vor anderen Bibliotheken und Ihrem eigenen Code.

Browser-Rauschen herausfiltern

Manche Fehler stammen vom Browser oder seinen Erweiterungen, nicht von Ihrem Code, und Sie können sie nicht beheben. Die Option Error filtering im Installationsablauf verwirft sie mit beforeError:
Jedes Muster wird gegen die Meldung, den Stacktrace und den Dateinamen des Fehlers geprüft:
  • ResizeObserver loop: ein Browser-Hinweis darauf, dass Resize-Benachrichtigungen auf den nächsten Frame verschoben wurden. Meist harmlos.
  • Script error.: ein Fehler aus einem Skript auf einer anderen Domain, ohne Details zum Debuggen. Das SDK verwirft solche ohnehin bereits, wenn sie ohne Stacktrace ankommen.
  • -extension://: ein Fehler aus einer Browser-Erweiterung, etwa einem chrome-extension://- oder moz-extension://-Skript.
  • webkit-masked-url: die Adresse, die Safari anstelle des Skripts einer Erweiterung anzeigt.
Fügen Sie IGNORED ein Muster für jeden anderen Fehler hinzu, den Sie ignorieren möchten. Ein verworfener Fehler hinterlässt keinen Breadcrumb und zählt nicht als Wiederholung. Er zählt aber zum Limit von 100 Fehlern alle 10 Sekunden. Mehr dazu unter Fehler und Breadcrumbs filtern.

Fehler in AppSignal ansehen

Die Errors-Ansicht gruppiert diese zu Issues, die Sie nach Version und Zeitraum filtern, zuweisen und für die Sie sich benachrichtigen lassen können. Mehr dazu unter Front-end-Fehler in AppSignal.