Verificación y problemas habituales - PHP
Un evento controlado
use function Dock\Ray\captureMessage;
captureMessage('Mensaje de control DockRay');En CLI el evento sale en línea (send_after_response está desactivado ahí por defecto), así que es la forma más rápida de comprobar la conexión. En web el evento sale solo después de enviar la respuesta: es normal y no significa que algo esté roto.
Problemas habituales
No llega nada al panel
Comprueba en orden: si init() se llama realmente (la causa más frecuente en una aplicación sin framework), si el token y la clave están definidos y pertenecen al mismo proyecto, si la clave ha sido revocada y si el servidor permite HTTPS saliente.
Los eventos de CLI llegan y los de web no
En web el envío ocurre al cerrar, tras enviar la respuesta. Si el proceso termina de golpe - un exit dentro de un manejador de errores, una caída de PHP-FPM, un proceso matado - la cola nunca se vacía. Para diagnosticarlo, pon temporalmente 'send_after_response' => false: si entonces llegan los eventos, el problema es cómo termina el proceso, no la conexión.
Toda la pila parece código de vendor/
Falta in_app_exclude. Sin esa opción el SDK no sabe dónde acaba tu aplicación y empieza una biblioteca, y el lugar del fallo apunta al frame más profundo en lugar del que significa algo.
Con mucha carga se pierden algunos eventos
La cola guarda como máximo 50 eventos por petición; por encima se descartan los nuevos. Si una petición genera más, casi siempre es un error dentro de un bucle, y el panel lo mostrará igualmente como una fila con contador. Revisa también sample_rate si se ha bajado.
Faltan errores de PHP, solo llegan excepciones
error_types sigue por defecto a error_reporting(). Si la aplicación lo estrecha en php.ini o en el bootstrap, DockRay recibe exactamente ese rango recortado. Define error_types de forma explícita cuando quieras otra cosa.
Faltan transacciones
En este SDK las transacciones tienes que abrirlas tú mediante HttpTransaction: aquí no hay middleware automático. Además, solo se envían con traces_sample_rate mayor que cero.
Un evento se descartó por el camino
Revisa before_send: devolver null descarta el evento. Es la causa más habitual de «algunos errores llegan y otros no» en una aplicación donde alguien puso ahí un filtro.
El panel responde 200 pero no aparece el evento
Una respuesta 200 {"success": false} significa que la cuenta ha agotado su cupo mensual de errores. La integración no lo trata como una avería, y hace bien. El cupo se ve en el panel de la cuenta; hasta fin de mes se calcula a partir del consumo registrado, así que borrar errores no lo reinicia.
Sigue sin funcionar
Repasa la lista de comprobación de falta de datos y, si no ayuda, escríbenos. Indica el nombre del proyecto, la versión de la integración y la hora aproximada de la prueba: acorta el camino a la respuesta.