a.js:1:4523 wieder nützlich machen

Wir hatten zwei getrennte blinde Flecken. Empfangene Fehler verwiesen auf minifizierten Code wie a.js:1:4523, weil Source Maps fehlten. Andere Ereignisse kamen nie an, weil direkte Anfragen an sentry.io blockiert werden konnten.

Das waren unabhängige Fehler. Source Maps bestimmen, ob ein empfangener Stacktrace auf Quellcode zurückgeführt werden kann. Der Transport bestimmt, ob das Ereignis Sentry überhaupt erreicht. Wird nur eines behoben, bleibt der Vorfall unlesbar oder unsichtbar.

@sentry/nextjs umschloss den Build mit withSentryConfig. CI stellte SENTRY_AUTH_TOKEN, SENTRY_ORG und SENTRY_PROJECT bereit. Das Build-Plug-in lud die Source Maps hoch, erweiterte den Upload von Clientdateien für bessere Stacktraces und nutzte deleteSourcemapsAfterUpload, sodass diese Dateien nicht aus der öffentlichen Ausgabe ausgeliefert wurden.

export default withSentryConfig(nextConfig, {
  org: process.env.SENTRY_ORG,
  project: process.env.SENTRY_PROJECT,
  authToken: process.env.SENTRY_AUTH_TOKEN,
  sourcemaps: {
    disable: process.env.NODE_ENV === 'development',
    deleteSourcemapsAfterUpload: true
  },
  widenClientFileUpload: true,
  disableLogger: true,
  tunnelRoute: '/t'
})

Damit blieb die Zuordnung innerhalb des normalen Bereitstellungs-Builds. Es gab keinen getrennten sentry-cli-Uploadbefehl, an den sich ein Entwickler nach dem Release erinnern musste.

Der erste Endpunkt unter derselben Origin war /monitoring, doch Blocker erkannten ihn weiterhin. Ich kürzte die Route auf /t. Browserereignisse adressierten anschließend die Anwendungs-Origin, und der Next.js-Server leitete sie an Sentry weiter.

Für die ursprüngliche Einführung wurde nach dieser Änderung eine vollständige Erfassung dokumentiert. Das war ein Ergebnis aus dem Einführungszeitraum, kein Versprechen, dass jedes Ereignis bei jedem Blocker und in jedem Netzwerk immer zugestellt wird.

Next.js 15 verlagerte die Browsereinrichtung nach instrumentation-client.ts. Bei aktiviertem Turbopack blieb das Projekt auf Sentry v9, und der Source-Map-Upload stoppte ohne offensichtlichen Anwendungsfehler. Der Wechsel zu Sentry v10 stellte den kompatiblen Uploadweg wieder her.

Die Anwendung initialisierte Sentry außerdem für Browser-, Server- und Edge-Laufzeiten und ergänzte Fehlergrenzen auf Routen- und globaler Ebene. Die Zuordnung zum Quellcode war eine Buildfrage; die Erfassung von React-, Anfrage- und Laufzeitfehlern war eine getrennte Anwendungsfrage.

Ein beforeSend-Hook ergänzte Seitenpfad, Browserinformationen, Viewport und ein Tag für die Anwendungsversion. Er kategorisierte API-, Zeitüberschreitungs- und Netzwerkfehler und filterte bekannte Twilio-Anrufbeschränkungen vor der Aufnahme.

Session Replay erfasste 5 % der normalen Sitzungen und jede Fehlersitzung im Produktivbetrieb. Tracing lief zunächst zu 100 % im Staging und zu 10 % im Produktivbetrieb und wurde später deaktiviert, als es zu viel Kontingent verbrauchte. Sampling ist eine Betriebseinstellung, kein Wert, der blind übernommen werden sollte.

• Laden Sie private Source Maps während des Builds hoch.
• Senden Sie Browserereignisse durch einen Tunnel unter derselben Origin.
• Trennen Sie erwartete Produktbeschränkungen von Anwendungsfehlern.
• Fügen Sie Routen- und Wiedergabekontext hinzu, damit eine lesbare Zeilennummer auch den Kontext des Nutzerablaufs enthält.