Diagnosticar por síntoma: z-request-id localiza 401 / 502 / flujos rotos
Rastree 401 / 403 / 404 / 502 / 503 / tiempos de espera / flujos rotos / OOM con z-request-id de extremo a extremo: deje de adivinar.
De qué se queja realmente la comunidad
Preguntas frecuentes en StackOverflow: "la respuesta en streaming se convirtió en un solo bloque después del proxy", "el JSON de llamada a herramientas no se ensambla", "¿este 429 es límite de velocidad o cuota excedida?", "¿este 502 es del gateway o del proveedor?".
Diagnosticar llamadas de IA es difícil: rutas con varios saltos, streaming y códigos de error inconsistentes; cuando algo se rompe, no sabe en qué salto.
Cómo lo hace GateLLM
GateLLM asigna a cada solicitud un z-request-id que atraviesa todo el log, así que localiza por síntoma: 401 / 403 → autenticación y Header ACL; 404 → enrutamiento; 502 / 503 → salud del upstream; tiempo de espera → límite de velocidad y ruta transoceánica; flujo roto → almacenamiento en búfer y SSE; OOM → configuración.
Los códigos de error se normalizan (semántica de errores entre proveedores unificada), el streaming pasa de forma nativa sin almacenamiento en búfer y los logs de Token Ops son consultables y exportables.
5 palancas que realmente funcionan
- z-request-id atraviesa todo el log: localice por id en un solo paso
- Triaje por síntoma: 401 / 403 / 404 / 502 / 503 / tiempo de espera / flujo roto / OOM
- Normalización de códigos de error: semántica de errores entre proveedores unificada en un solo vocabulario
- Paso nativo de flujos, sin almacenamiento en búfer y sin romper SSE ni las llamadas a herramientas
- Logs de Token Ops consultables y exportables, conectados al diagnóstico y a la conciliación