Weryfikacja i typowe problemy - PHP

Kontrolowane zdarzenie

use function Dock\Ray\captureMessage;

captureMessage('Kontrolny komunikat DockRay');

W CLI zdarzenie idzie w miejscu wywołania (send_after_response jest tam domyślnie wyłączone), więc jest to najszybszy sposób sprawdzenia połączenia. Na WWW zdarzenie wyjdzie dopiero po odesłaniu odpowiedzi - to normalne i nie znaczy, że coś nie działa.

Typowe problemy

Nic nie dociera do panelu

Sprawdź kolejno: czy init() jest w ogóle wywoływane (najczęstsza przyczyna w aplikacji bez frameworka), czy token i klucz są ustawione i należą do tego samego projektu, czy klucz nie został odwołany i czy serwer ma otwarte połączenia wychodzące HTTPS.

Zdarzenia z CLI docierają, z WWW nie

Na WWW wysyłka dzieje się przy zamknięciu, po odesłaniu odpowiedzi. Jeżeli proces kończy się nagle - exit w handlerze błędu, awaria PHP-FPM, ubicie procesu - kolejka nie zostanie opróżniona. Do diagnozy przełącz tymczasowo 'send_after_response' => false: jeśli wtedy zdarzenia docierają, problem jest w zakończeniu procesu, a nie w połączeniu.

Cały stos wygląda jak kod z vendor/

Brakuje in_app_exclude. Bez tej opcji SDK nie wie, gdzie kończy się Twoja aplikacja, a zaczyna biblioteka - i miejsce awarii wskazuje najgłębszą ramkę zamiast tej, która coś znaczy.

Część zdarzeń ginie przy dużym ruchu

Kolejka trzyma najwyżej 50 zdarzeń na żądanie; nadwyżka jest odrzucana. Jeżeli jedno żądanie generuje ich więcej, prawie zawsze znaczy to błąd w pętli - i tak w panelu zobaczysz go jako jeden wiersz z licznikiem. Sprawdź też sample_rate, jeśli został obniżony.

Brakuje błędów PHP, są tylko wyjątki

error_types domyślnie idzie za error_reporting(). Jeśli aplikacja zawęża je w php.ini albo w bootstrapie, DockRay dostaje dokładnie ten zawężony zakres. Ustaw error_types jawnie, gdy chcesz coś innego.

Brakuje transakcji

Transakcje trzeba w tym SDK otworzyć samemu przez HttpTransaction - nie ma tu automatycznego middleware'u. Dodatkowo wychodzą tylko przy traces_sample_rate większym od zera.

Zdarzenie zostało odrzucone po drodze

Sprawdź before_send: zwrócenie null odrzuca zdarzenie. To najczęstsza przyczyna „jedne błędy docierają, inne nie" w aplikacji, w której ktoś wstawił tam filtr.

Panel odpowiada 200, ale zdarzenia nie ma

Odpowiedź 200 {"success": false} znaczy, że konto wyczerpało miesięczny limit błędów. Integracja nie traktuje tego jak awarii - i słusznie. Limit widzisz na pulpicie konta; do końca miesiąca liczy się z zapisanego zużycia, więc nie zresetuje go usunięcie błędów.

Nadal nie działa

Przejdź przez listę kontrolną braku danych w panelu, a jeśli to nie pomoże - napisz do nas. Podaj nazwę projektu, wersję integracji i przybliżoną godzinę testu: to skraca drogę do odpowiedzi.