Überprüfung und typische Probleme - Symfony

Prüfen, dass das Bundle aktiv ist

php bin/console debug:container ray.hub
php bin/console debug:config ray

Der erste Befehl bestätigt, dass das Bundle registriert ist, der zweite zeigt, welche Werte nach dem Auflösen der Umgebungsvariablen tatsächlich gelten. Damit ist die Mehrheit der Fälle „ich habe es konfiguriert und nichts passiert“ geklärt.

Ein kontrolliertes Ereignis

Rufe captureMessage() aus einem Befehl oder Controller auf und prüfe, ob das Ereignis im Panel unter Fehler erscheint. Die Umgebung sollte %kernel.environment% entsprechen.

Typische Probleme

Es kommt nichts im Panel an

Prüfe der Reihe nach: zeigt debug:config ray gefüllte token und private_key (und kein unaufgelöstes %env(...)%), gehören beide zum gleichen Projekt, ist der Container-Cache frisch (php bin/console cache:clear), und erlaubt der Server ausgehendes HTTPS.

Das Panel hat sich mit 404-Fehlern gefüllt

In Symfony ist eine 404 eine Ausnahme. Ergänze NotFoundHttpException in ignore_exceptions. Dasselbe gilt für Zugriffsverweigerungen, wenn sie in deiner Anwendung ein normales Ergebnis sind.

Eine Ausnahme wird gemeldet, aber nicht die richtige

ExceptionListener liegt auf Priorität -128 und meldet damit die Ausnahme, die die Listener der Anwendung überlebt hat. Wandelt ein eigener Listener eine Ausnahme in eine andere und wirft sie weiter, zeigt das Panel die zweite - und genau daran ist die Anfrage gescheitert.

Benutzerdaten fehlen

UserListener registriert sich nur, wenn symfony/security-core installiert ist, und läuft auf kernel.controller. Eine vor dem Controller geworfene Ausnahme - in der Firewall oder in einem anderen kernel.request-Listener - hat noch keinen Benutzer.

Fehler aus Konsolenbefehlen fehlen

ConsoleErrorListener braucht symfony/console im Projekt und hört auf console.error. Ein Befehl, der seine Ausnahme selbst fängt und einen Exit-Code zurückgibt, ohne sie weiterzuwerfen, löst dieses Ereignis nie aus - melde dort manuell über ray.hub.

Transaktionen fehlen

Transaktionen entstehen nur bei einer traces_sample_rate über null, betreffen ausschließlich Hauptanfragen (keine Sub-Requests) und schließen auf kernel.terminate. Prüfe auch ignore_transactions - ein zu deiner Route passendes Pfad-Präfix schaltet die Messung für den gesamten Adresszweig ab.

Ein Messenger-Worker übernimmt eine Konfigurationsänderung nicht

Der Hub ist ein Container-Singleton, und ein Worker liest die Konfiguration beim Start. Starte die Worker nach einer Änderung der ray.yaml oder der .env.local neu (php bin/console messenger:stop-workers).

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.