Enlaces importantes
*El Panel de Estado del servicio actualmente solo está disponible para clientes Enterprise API.
Empieza con los valores predeterminados correctos
Al abrir el panel de Estado del servicio, se establece de forma predeterminada en:
Todos los proyectos
Últimos 30 días
Resolución por hora
Esta vista solo es útil para orientarte. La solución de problemas significativa siempre requiere filtrado.
Filtra antes de investigar
El filtrado correcto es el paso más importante. La mayoría de las interpretaciones erróneas provienen de mezclar modelos, niveles o proyectos.
Filtra por modelo (uno a la vez)
Siempre filtra por un solo modelo.
Por qué:
Los problemas en modelos con poco tráfico pueden quedar ocultos por tráfico de mayor volumen
Los modelos con mucho tráfico pueden hacer que problemas localizados parezcan globales
Los distintos modelos tienen diferentes objetivos de rendimiento
Nota: seleccionar varios modelos los agrega; no alterna entre ellos.
Filtra por nivel de servicio
Si usas más de un nivel (standard, priority, scale), siempre filtra por el nivel que estás investigando.
Por qué:
Los niveles tienen diferentes características de rendimiento
Los niveles priority y scale tienen SLA definidos
Mezclar niveles oculta el rendimiento del nivel de pago
Esto es especialmente importante para el análisis de latencia.
Filtra por proyecto
De forma predeterminada, Estado del servicio muestra todos los proyectos.
Para la solución de problemas, filtra por el/los proyecto(s) donde se observó el problema.
Por qué:
Un solo proyecto de alto volumen puede dominar las métricas
Los proyectos afectados más pequeños pueden quedar ocultos por tráfico no relacionado
Solo deja seleccionado "Todos los proyectos" si crees que el problema realmente afecta a toda la organización.
Solución de problemas de errores
Usa la vista de solicitudes HTTP
Para investigar errores:
Filtra por modelo y nivel
Para cambiar de Uptime a HTTP Requests, haz clic en la pestaña HTTP Requests
Esta vista muestra el total de solicitudes y el conteo de errores por código de estado HTTP. Haz zoom hasta una resolución por minuto para identificar picos o cambios granulares.
Interpreta tasas de error, no conteos
Algunos errores son esperables en cualquier sistema de producción. Enfócate en el porcentaje de errores, no en los totales brutos.
Cuanto mayor sea tu volumen total, mayor será la cantidad potencial de errores incluso con una tasa de error extremadamente baja.
Cuando faltan errores en Estado del servicio
Si ves errores del lado del cliente pero no datos correspondientes en Estado del servicio:
Es probable que las solicitudes no hayan llegado a OpenAI
El problema normalmente está aguas arriba (timeouts, proxies, red)
Esto es común con timeouts agresivos del lado del cliente.
Solución de problemas de latencia
El análisis de latencia es más significativo en los niveles priority y scale, que tienen SLA definidos. El nivel standard puede mostrar una variación de latencia más amplia y no tiene latencia garantizada.
Métricas clave
Para ver cada una de estas métricas, haz clic en la pestaña correspondiente:
Velocidad de tokens
Tokens generados por segundo.
Independiente del tamaño del prompt.
Tiempo de solicitud
Duración total de la solicitud.
Muy afectado por el tamaño de la salida y el razonamiento.
Tiempo hasta el primer token (TTFT)
Tiempo hasta que se genera el primer token.
Muy afectado por el tamaño del prompt de entrada no almacenado en caché y el razonamiento.
Revisa siempre los percentiles P50 / P75 / P95. Los promedios pueden ocultar el impacto en usuarios reales.
6. Correlación de la latencia con el uso de tokens
Estado del servicio muestra cuándo cambió el comportamiento. Los datos de uso ayudan a explicar por qué.
En el panel de Uso, haz lo siguiente para asegurarte de que estás viendo los datos relevantes para tu vista en el Panel de Estado del servicio:
Filtra por el mismo proyecto, modelo
Agrupa por nivel de servicio si corresponde
Enfócate en los tokens de salida, que son los que más afectan la latencia
Para un análisis más profundo, exporta los datos de actividad y examina los tokens por solicitud a lo largo del tiempo.
7. Qué compartir con Soporte (si es necesario)
Si te pones en contacto con soporte, incluye:
ID de organización afectados (esto es importante)
Puntos de acceso afectados (Chat Completions, Responses, etc.) (esto es importante)
Modelos afectados (esto es importante)
¿Esto ocurre en el nivel scale o priority? (esto es importante)
Rangos de tiempo con zona horaria para latencia o error (esto es importante)
x-request-id o X-Client-Request-Id relevantes (a menudo es importante; inclúyelos si es posible)
Marcas de tiempo con zona horaria (o al menos la fecha) de las solicitudes proporcionadas
Latencia: si compartes ejemplos de solicitudes lentas, comparte cuánto tardó de tu lado. Idealmente, incluye también las marcas de tiempo de cuándo se envió la solicitud y cuándo se recibió.
Errores: comparte el porcentaje aproximado de solicitudes fallidas/con error, los códigos de respuesta, los mensajes de error y cuánto tardó en llegar la respuesta de error
ID del proyecto relacionado con las solicitudes
¿Esto afecta solicitudes de residencia de datos? Si es así, ¿cuáles?
Descripciones de las tendencias que observas
Errores: % aproximado de solicitudes fallidas/con error
Latencia: qué percentiles están afectados (p50 / p90 / p95 / p99) y qué tan altos son en comparación con la línea base del cliente
Ambos: capturas de pantalla o tabla de datos de error o latencia (¿cómo determinaste que las tasas de error o la latencia son más altas de lo esperado?)
Escenarios comunes de solución de problemas
Se producen timeouts pero Estado del servicio parece normal
Causa posible: las solicitudes están agotando el tiempo de espera antes de llegar a OpenAI.
Revisa:
Configuración de timeout del cliente o proxy
Cambios en la red local o en el balanceador de carga
Presencia de errores 499 en el panel de Estado del servicio (estos pueden aparecer como errores 5xx en tus propios sistemas).
La latencia aumentó sin un despliegue
Causa posible: aumentó el tamaño de los tokens de salida o el uso de razonamiento y\or el tráfico cambió entre niveles de servicio
Revisa:
Promedio de tokens de salida por solicitud en el panel de Uso (requiere descargar datos y dividir los tokens de salida por el total de solicitudes).
Percentiles de Tiempo de solicitud y TTFT en el panel de Estado del servicio.
El nivel Priority o Scale parece lento
Causa posible: las métricas están mezcladas entre niveles (lo que significa que el tráfico del nivel standard está ocultando el rendimiento del nivel de pago)
Revisa:
Los filtros están restringidos a un solo nivel y modelo
Comparación de velocidad de tokens entre niveles
Pico de errores 5XX
Causa probable: fallas transitorias que afectan a un pequeño porcentaje del tráfico.
Revisa:
Porcentaje de tasa de error
Si el volumen de tráfico cambió al mismo tiempo
El problema afecta solo a un proyecto
Causa probable: configuración o patrón de uso específico del proyecto.
Revisa:
Filtrado a nivel de proyecto
Comparación con proyectos no afectados
Conclusiones finales
Filtra por modelo, nivel y, cuando sea relevante, proyecto antes de interpretar las métricas
Usa percentiles, no promedios, para el análisis de latencia
Se esperan tasas de error pequeñas
La falta de datos generalmente indica problemas aguas arriba
Los datos de uso pueden ayudar a explicar por qué cambió la latencia; Estado del servicio ayuda a mostrar cuándo