Überprüfung und typische Probleme - Nuxt

Ein kontrolliertes Testereignis

export default defineEventHandler(() => {
    throw createError({ statusCode: 500, statusMessage: 'DockRay-Kontrollfehler' });
});

Rufe diese Route einmal auf und entferne sie gleich nach dem erfolgreichen Test. Der Eintrag sollte im Panel unter Fehler des Projekts erscheinen, auf das der Token zeigt.

Typische Probleme

Zugangsdaten im falschen Teil der Konfiguration

Token und Schlüssel müssen im privaten Teil der Runtime-Konfiguration landen - über NUXT_RAY_TOKEN/NUXT_RAY_PRIVATE_KEY oder direkt unter dem Schlüssel ray in nuxt.config.ts. Unter runtimeConfig.public.ray eingetragen landen sie im Client-Bundle - dasselbe Risiko wie ein Next.js-Schlüssel mit NEXT_PUBLIC_-Präfix.

404-Fehler tauchen nicht im Panel auf

So ist es gewollt. Es werden nur 5xx-Codes gemeldet - createError({ statusCode: 404 }) und jeder andere 4xx ist ein normales Ergebnis, keine Störung.

Ein Vue-Komponentenfehler taucht nicht im Panel auf

Prüfe, ob browser.enabled aktiviert ist und ob die Seite das Client-Plugin tatsächlich geladen hat - Vue verschluckt Komponentenfehler im eigenen Handler, ohne die eingebundenen Hooks vue:error/app:error erreicht ein Fehler nie window.onerror und von dort den Kollektor.

Transaktionen fehlen trotz korrekter Einrichtung

Zwei unabhängige Ursachen: tracesSampleRate bei 0, oder der Pfad passt zu einem der ignorePaths-Einträge (standardmäßig /_nuxt, /__nuxt, /health, /metrics) und wird absichtlich übersprungen.

JavaScript-Fehler aus dem Browser kommen nicht an

Die Nitro-Route entsteht nur, wenn browser.enabled zur Build-Zeit gesetzt war - das Einschalten allein über eine Umgebungsvariable zur Laufzeit reicht nicht, das Modul muss es während setup() wissen. Prüfe auch, ob der Server NUXT_RAY_TOKEN und NUXT_RAY_PRIVATE_KEY gesetzt hat: die Route antwortet trotzdem mit 202, leitet aber nichts weiter.

Ein Worker-Deployment (Cloudflare) meldet nicht

Das Modul liest das Ereignis auf Node und auf Workern über denselben Pfad, ein zweiter Codepfad ist also nicht nötig - kommt trotzdem nichts an, prüfe, ob die NUXT_RAY_*-Variablen in der Umgebung genau dieses Deployments überhaupt verfügbar sind, nicht nur lokal.

Ein Fehler zerfällt in viele Einträge

Das Panel gruppiert über den Fingerabdruck sha256(Projekt-Token + Typ + Meldung). Eine in die Ausnahmemeldung eingesetzte Bestell- oder Benutzerkennung zerlegt einen Fehler in tausend Zeilen.

Das Panel antwortet 200, aber es gibt kein Ereignis

Eine Antwort 200 {"success": false} bedeutet, dass das Konto sein monatliches Fehlerkontingent aufgebraucht hat. Die Integration behandelt das nicht als Störung - zu Recht. Das Kontingent siehst du im Konto-Dashboard; bis zum Monatsende wird es aus der erfassten Nutzung berechnet, Fehler zu löschen setzt es also nicht zurück.

Es funktioniert weiterhin nicht

Arbeite die Checkliste zur Fehlerbehebung durch, und wenn das nicht hilft, schreib uns. Nenne den Projektnamen, die Version der Integration und ungefähr die Uhrzeit des Tests: das verkürzt den Weg zur Antwort.