Ingeniería
Cómo diseñar comprobaciones de estado para API creadas con IA
La IA puede generar una API rápidamente, pero la plataforma sigue necesitando un endpoint de estado veraz antes de enviar tráfico de producción.
La comprobación de estado más sencilla siempre devuelve 200. La útil reconoce cuándo hay que dejar de dirigir tráfico a una API creada con IA.
Distingue entre estar activo y estar disponible
La comprobación de actividad determina si el proceso sigue funcionando lo suficiente para recuperarse sin reiniciarse. La de disponibilidad determina si puede atender tráfico con seguridad ahora. Combinar ambas en un endpoint costoso puede convertir una dependencia lenta en un bucle de reinicios.
Mantén la comprobación de actividad local y de bajo coste. Deja que la de disponibilidad cubra el pequeño conjunto de dependencias cuyo fallo impide atender solicitudes. Un servicio de analítica en segundo plano rara vez pertenece a ese conjunto; una conexión necesaria a la base de datos suele pertenecer.
- —Actividad: el proceso o el bucle de eventos responde; no requiere llamadas externas.
- —Disponibilidad: las dependencias necesarias para atender solicitudes responden dentro de un plazo fijo.
- —Inicio: la inicialización y las migraciones terminan antes de que la comprobación de disponibilidad pase.
Acota los fallos
Una sonda que espera indefinidamente no sirve como sonda. Establece un tiempo de espera breve, evita reintentos sin límite dentro del gestor y devuelve un fallo claro cuando la aplicación no pueda confirmar su disponibilidad a tiempo. Así la plataforma puede dejar de dirigir tráfico nuevo mientras el proceso se recupera o se inicia un sustituto.
El endpoint también debe evitar modificar datos. Las comprobaciones de estado se ejecutan con frecuencia, desde más de una ubicación y en condiciones ya degradadas. Una consulta de solo lectura o un ping ligero a una dependencia es más seguro que escribir datos solo para demostrar que hay acceso.
export async function GET() {
const ready = await dependenciesReady({ timeoutMs: 500 });
return Response.json(
{ status: ready ? "ready" : "not_ready" },
{ status: ready ? 200 : 503 },
);
}Prueba los casos de fallo
Una ruta de estado probada solo cuando todas las dependencias funcionan está incompleta. Detén la base de datos, agota un grupo de conexiones, haz que un servicio upstream necesario exceda su tiempo de espera y confirma que la comprobación de disponibilidad falla antes de que se acumulen solicitudes normales.
Después restablece la dependencia y verifica que el proceso vuelve a recibir tráfico sin intervención manual. La recuperación también forma parte del contrato.
- —Bloquea las conexiones a la base de datos y verifica que la disponibilidad devuelve 503.
- —Retrasa un servicio upstream necesario más allá del plazo de la sonda.
- —Envía SIGTERM y confirma que la disponibilidad falla antes de comenzar el apagado.
- —Restablece las dependencias y confirma que la réplica vuelve a la rotación cuando se estabiliza.
Evita incidentes provocados por las sondas
La frecuencia de las sondas se multiplica rápidamente entre réplicas y ubicaciones de monitorización. Comprobar diez réplicas cada segundo puede añadir cientos de consultas a dependencias por minuto. Mantén la consulta de bajo coste, usa caché solo cuando no pueda ocultar una interrupción real y añade variación aleatoria si todas las réplicas realizarían la comprobación al mismo instante.
Genera alertas por una pérdida sostenida de disponibilidad y por el número de réplicas operativas, en lugar de por cada comprobación fallida. Un tiempo de espera agotado transitorio aporta una prueba; una disminución del conjunto que atiende tráfico constituye un incidente.