Fehlerbehebung für browser monitoring

​

Es kommen überhaupt keine Daten an

Arbeiten Sie diese Punkte der Reihe nach durch. Jeder davon ist ein vollständiger Stopp: Wenn er zutrifft, wird nichts gesendet.

1. active ergibt false. Loggen Sie den Wert, den Sie übergeben, nicht den Ausdruck. Ein Bundler, der process.env.NODE_ENV nicht ersetzt, lässt den Vergleich im Browser false werden.
2. init() wurde nie ausgeführt. Konfiguration zu setzen genügt nicht. Bestätigen Sie, dass Ihr Entry Point das Modul importiert, das init() aufruft. Prüfen Sie, dass Ihr Build es enthält.
3. Der Schlüssel ist falsch. Ein falscher Schlüssel führt zu 401. Verwenden Sie den Front-end API key dieser App, keinen Push key. Prüfen Sie, dass er zur richtigen Umgebung gehört.
4. Requests werden blockiert. Öffnen Sie das Netzwerk-Panel Ihres Browsers und suchen Sie nach einem Request an /ingest/browser/errors für Fehler oder /ingest/browser für web vitals. Ein blockierter Request erscheint in der Konsole als Verstoß gegen die Content Security Policy: Fügen Sie https://appsignal-endpoint.net zu Ihrer connect-src-Direktive hinzu.
5. endpoint ist nicht gesetzt. Ohne endpoint sendet das SDK an die aktuelle Origin. Das erfordert einen Proxy auf Ihrer Domain. Setzen Sie es andernfalls auf https://appsignal-endpoint.net.

​

Fehler kommen an, web vitals nicht

Web vitals werden gestapelt und nicht pro Messung gesendet. Sie werden gesendet, wenn die Seite verborgen wird, wenn sie geschlossen wird und bei einem clientseitigen Routenwechsel. Verlassen Sie die Seite oder wechseln Sie den Tab, und prüfen Sie die Performance-Ansicht erneut. Wenn sie dann noch fehlen, prüfen Sie, ob es speziell CLS und INP sind, die fehlen. Diese beiden benötigen Browser-Performance-Entries, die möglicherweise nicht verfügbar sind.

​

Ein Fehler fehlt

• Er trat auf, bevor init() lief. Nichts, was davor ausgelöst wird, wird erfasst. Importieren Sie Ihr AppSignal-Setup als ersten Import in Ihrem Entry Point.
• Er war eine Wiederholung. Prüfen Sie die Rate-Limits für identische und für alle Fehler.
• Er wurde per sampling verworfen. Prüfen Sie, ob errors.sampleRate unter 1.0 liegt.
• beforeError hat ihn verworfen. Ein Callback, der null zurückgibt, verwirft den Fehler. Loggen Sie das Event am Anfang des Callbacks, um zu bestätigen, was es erhält.
• Er wurde in einem iframe ausgelöst. Ein Same-Origin-iframe braucht seinen eigenen init()-Aufruf.
• Es war ein React-Render-Fehler. React lässt Render-Fehler nicht bis zu window durch. Fügen Sie eine Error Boundary hinzu.
• Er kam von einem Skript auf einer anderen Domain. Lesen Sie den folgenden Abschnitt.

​

Fehler von Cross-Origin-Skripten fehlen

Wenn Fehler aus einem Skript fehlen, das auf einem anderen Origin gehostet wird, prüfen Sie dessen Cross-Origin-Einstellungen. Der Browser zeigt für Cross-Origin-Skripte möglicherweise nur Script error. an. Das SDK verwirft diese nichtssagenden Fehler. Beheben Sie es, indem Sie diese Skripte mit CORS-Headern ausliefern, wie unter Assets auf einem CDN beschrieben.

​

Backtraces sind minifiziert

Backtraces werden über sourcemaps aufgelöst, abgeglichen über den Revisions-String. Setzen Sie appVersion auf denselben Wert, den Ihr Build für seine sourcemaps verwendet. Ohne appVersion gibt es nichts, worüber abgeglichen werden könnte, und Backtraces bleiben minifiziert.

​

Eine Route erzeugt Hunderte von Fehlergruppen

Das Route-Template fehlt, daher verwenden Fehler den rohen Pfad jeder Seite. Rufen Sie bei jeder Router-Navigation setRouteTemplate("/orders/:id") auf. Neue Fehler gruppieren sich dann unter diesem Template. Für web vitals leitet der Server ein angenähertes Template ab. Ein explizites Template ist zuverlässiger und hilft, das Limit für unterschiedliche Routen zu vermeiden.

​

Clientseitige Navigation wird nicht gemeldet

Das SDK und manche Router patchen beide history.pushState. Das SDK verträgt sich mit einem bereits installierten Patch. Ein Router, der den Patch des SDKs später ersetzt, kann das Tracking der Navigation unterbrechen. Importieren Sie Ihr AppSignal-Setup vor Ihrem Router. Hash-Router werden nur als Router behandelt, wenn der Hash wie eine Route aussieht, etwa #/orders. Ein bloßes #orders ist von einem Anker innerhalb der Seite nicht zu unterscheiden und wird nicht als Navigation behandelt.

​

API-Requests schlagen nach Aktivierung von verteiltem Tracing fehl

Ein Cross-Origin-Request, der traceparent mitführt, benötigt möglicherweise einen CORS-Preflight. Wenn Ihr Browser einen CORS-Fehler meldet, der traceparent nennt, erlauben Sie diesen Header in Access-Control-Allow-Headers Ihrer API. Mehr dazu unter Verteiltes Tracing für Browser.

​

Ein fehlgeschlagener Request zeigt keine Back-end-Spans

Der Fehler ist angekommen, aber sein Trace enthält nur den Browser-Span. Prüfen Sie, dass der empfangende Service über einen gehosteten Collector berichtet. Sein HTTP-Server braucht außerdem das richtige Instrumentierungspaket, um traceparent zu lesen.

​

Keine fehlgeschlagenen Requests werden gemeldet

Requests an Ihre API schlagen fehl, aber es erscheint kein HTTPError- oder TimeoutError-Issue. Prüfen Sie, dass jeder Request einem Muster in tracePropagationTargets entspricht. Ein Muster braucht einen Host und einen Pfad: Weder /api/** noch api.example.com allein passen auf irgendetwas. Manche Fehlschläge werden nie gemeldet:

• Ein Request im no-cors-Modus.
• Eine 4xx-Antwort.
• Ein Request, der auf privacy.networkBlocklist passt.
• Ein Timeout, während das Gerät offline ist.

Mehr dazu unter was gemeldet wird.

​

Netzwerk-Breadcrumbs haben keine Zeitangaben

Der Request war cross-origin und der Server hat keinen Timing-Allow-Origin-Header gesendet. Mehr dazu unter Netzwerk-Breadcrumbs lesen.

​

Hilfe bekommen

Geben Sie den Namen Ihrer App, die Version von @appsignal/browser sowie Browser und Version an, in denen Sie das Problem sehen. Erreichen Sie uns über unsere Support-Kanäle oder für Beta-Feedback in unserer Discord-Community.