Monitoreo de API GraphQL Que Detecta las Fallas que Oculta el HTTP 200

La mayoría de las implementaciones de GraphQL devuelven HTTP 200 incluso cuando la consulta falla. Los fallos residen dentro del cuerpo de la respuesta — en el arreglo errors, o como nulos dentro del objeto data — no en el código de estado. El monitoreo solo de tiempo activo marca las APIs GraphQL con fallos como saludables. El monitoreo real de GraphQL debe inspeccionar la carga útil de la respuesta. Ver monitoreo de API REST →

Envía una carga útil de consulta específica y luego realiza aserciones contra el cuerpo de la respuesta. Verifica si el arreglo errors de nivel superior está presente o poblado, valida invariantes de datos específicos de la consulta en la respuesta y marca nulos en campos que no pueden ser nulos. Algunos servidores GraphQL codifican fallos de dominio dentro del objeto data en lugar de poblar errores — se revisan ambas señales.

Sí. Cada monitor ejecuta una carga útil de consulta o mutación definida. Monitorea tus mutaciones más críticas (placeOrder, processPayment) individualmente para rastrear la latencia por operación, tasa de errores y tasa de fallos parciales.

Todos los esquemas comunes de autenticación: Bearer Token (el más común para GraphQL), OAuth 2.0 con renovación automática, JWT, Clave API, Autenticación Básica, Firma AWS v4, mTLS y encabezados personalizados. Los secretos se ocultan mediante Secure Vault. Ver matriz de autenticación →

Sí. Monitorea el endpoint supergraph para verificar que el gateway de federación esté saludable y monitorea endpoints individuales de subgraph para aislar qué servicio falla cuando una consulta federada falla. Funciona con Apollo Federation y arquitecturas similares.

Se rastrea la latencia total de la consulta, con percentiles P95/P99 por consulta. Para identificar resolutores lentos individuales, combina el monitoreo con tu trazado APM — el monitoreo sintético confirma la lentitud visible para el cliente; APM confirma qué resolutor es el cuello de botella.

Sí. Despliega Agentes Privados dentro de tu VPC o centro de datos — común para servicios GraphQL backend-for-frontend (BFF) que no están expuestos públicamente.

El monitoreo puede incluir consultas en varios niveles de profundidad y complejidad para verificar que tus límites de limitación y complejidad se apliquen. Combínalo con tu WAF o middleware de complejidad de consulta para protección total.

Las suscripciones de GraphQL suelen usar WebSocket — vea nuestro monitoreo WebSocket para el establecimiento de la conexión, entrega de mensajes y chequeos de keepalive.

Monitoree el endpoint supergraph para verificar que la puerta de enlace de federación esté saludable Y monitoree los endpoints individuales de subgraph por separado para aislar qué servicio aguas abajo falla cuando una consulta federada se rompe. Ambos monitores comparten rutas de alerta para una respuesta consolidada a incidentes.

Las suscripciones de GraphQL usan transporte WebSocket. Use nuestro producto de monitoreo WebSocket para validar que la conexión de suscripción se establezca correctamente, reciba los eventos esperados y se mantenga activa durante sesiones de larga duración.

Sí. Configure identificadores de consultas persistentes (Apollo Persisted Queries o hashes estilo Relay) en la solicitud y Dotcom-Monitor los enviará como referencia de operación en lugar de la cadena completa de consulta.

Construya monitores con profundidad y complejidad de consulta crecientes para verificar que su middleware de límite de complejidad aplique correctamente el umbral. Combine la configuración del monitor con sus reglas de complejidad del servidor GraphQL.