Überprüfung und typische Probleme - PHP

Ein kontrolliertes Ereignis

use function Dock\Ray\captureMessage;

captureMessage('DockRay-Kontrollmeldung');

In der CLI geht das Ereignis sofort hinaus (send_after_response ist dort standardmäßig aus), das ist also der schnellste Weg, die Verbindung zu prüfen. Im Web verlässt das Ereignis die Anwendung erst nach dem Ausliefern der Antwort - das ist normal und bedeutet nicht, dass etwas kaputt ist.

Typische Probleme

Es kommt nichts im Panel an

Prüfe der Reihe nach: wird init() überhaupt aufgerufen (die häufigste Ursache in einer Anwendung ohne Framework), sind Token und Schlüssel gesetzt und gehören zum gleichen Projekt, wurde der Schlüssel widerrufen, und erlaubt der Server ausgehendes HTTPS.

CLI-Ereignisse kommen an, Web-Ereignisse nicht

Im Web geschieht das Senden beim Shutdown, nach dem Ausliefern der Antwort. Endet der Prozess abrupt - ein exit im Fehlerhandler, ein PHP-FPM-Absturz, ein beendeter Prozess - wird die Warteschlange nie geleert. Setze zur Diagnose vorübergehend 'send_after_response' => false: kommen die Ereignisse dann an, liegt es am Prozessende und nicht an der Verbindung.

Der ganze Stack sieht wie Fremdcode aus

in_app_exclude fehlt. Ohne diese Option weiß das SDK nicht, wo deine Anwendung endet und eine Bibliothek beginnt - die Fehlerstelle zeigt dann auf den tiefsten Frame statt auf den, der etwas bedeutet.

Unter Last verschwinden einzelne Ereignisse

Die Warteschlange hält höchstens 50 Ereignisse pro Anfrage, darüber werden neue verworfen. Erzeugt eine Anfrage mehr, ist es fast immer ein Fehler in einer Schleife - und das Panel zeigt ihn ohnehin als eine Zeile mit Zähler. Prüfe auch sample_rate, falls sie gesenkt wurde.

PHP-Fehler fehlen, nur Ausnahmen kommen an

error_types folgt standardmäßig error_reporting(). Engt die Anwendung das in der php.ini oder im Bootstrap ein, bekommt DockRay genau diesen eingeengten Bereich. Setze error_types ausdrücklich, wenn du etwas anderes willst.

Transaktionen fehlen

In diesem SDK musst du Transaktionen selbst öffnen, über HttpTransaction - es gibt hier keine automatische Middleware. Zusätzlich werden sie nur bei einer traces_sample_rate über null gesendet.

Ein Ereignis wurde unterwegs verworfen

Prüfe before_send: gibt es null zurück, wird das Ereignis verworfen. Das ist die häufigste Ursache für „manche Fehler kommen an, andere nicht“ in einer Anwendung, in der jemand dort einen Filter eingebaut hat.

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.