Saltar al contenido principal
La mayoría de los servicios desplegables de Lerian exponen los mismos tres endpoints HTTP operativos —/health, /readyz y /version— en su puerto de aplicación principal. Los orquestadores como Kubernetes los usan para decidir cuándo un servicio está activo, cuándo puede recibir tráfico y qué build se está ejecutando. Este es el contrato de sondas estándar, no una garantía para cada servicio: algunos componentes —workers y sidecars— exponen solo un subconjunto. La tabla de cobertura por servicio de abajo es la autoridad para las excepciones.

​
Los endpoints de sonda

La grafía es exactamente /health y /readyz, no /healthz ni /livez. Las tres sondas se registran en el puerto de aplicación principal, antes del middleware de autenticación (son sondas públicas), y se excluyen de los logs de acceso y del rastreo de peticiones.

​
El cuerpo de respuesta de /readyz

/readyz devuelve un documento JSON que describe la readiness general y cada comprobación de dependencia.
El vocabulario de estado es un conjunto cerrado:
  • status general: healthy o unhealthy.
  • status por comprobación: up, down, degraded, skipped, n/a.
/readyz devuelve HTTP 200 solo cuando el estado general es healthy. Si cualquier comprobación es down o degraded, devuelve HTTP 503.

​
Comportamiento de arranque y apagado

Las sondas están cableadas para que un orquestador nunca enrute tráfico a un servicio que no puede atenderlo.
  • Autoprueba de arranque. /readyz devuelve 503 (“server not ready”) hasta que el listener está activo y las dependencias son alcanzables, de modo que un pod que está arrancando no se añade prematuramente a un balanceador de carga, aunque /health ya responda 200.
  • Drenaje ordenado. Ante un SIGTERM, el servicio cambia /readyz a 503 durante una ventana de drenaje (unos 12 segundos) mientras /health sigue en 200. Los orquestadores dejan de enrutar tráfico nuevo durante la ventana y, después, el proceso termina una vez que se drena el trabajo en curso. La ventana es ajustable mediante READYZ_DRAIN_DELAY_SEC (algunos servicios usan READYZ_DRAIN_GRACE_SECONDS).
  • Modo de despliegue. El DEPLOYMENT_MODE activo se refleja en el cuerpo de /readyz. En modo saas, una dependencia alcanzada sin TLS hace fallar la comprobación de readiness (y de arranque); en byoc se recomienda pero no se impone.

​
Readiness multi-tenant

Cuando el multi-tenancy está habilitado, el servicio añade una sonda de readiness por tenant protegida por auth:
Ejecuta las comprobaciones de readiness contra las conexiones resueltas de un único tenant. El /readyz global reporta las comprobaciones con alcance de tenant como n/a y apunta a la ruta por tenant.

​
Cobertura por servicio

Cada servicio de la lista siguiente expone /health (liveness) y /readyz (readiness) en su puerto principal. La tabla lista los puertos por defecto, la sonda multi-tenant donde aplica y las dos desviaciones de ruta.
Readyz multi-tenant se marca como Sí donde el servicio registra GET /readyz/tenant/{id}; aparece cuando el multi-tenancy está habilitado. Un — significa que no se registra ninguna sonda dedicada por tenant para ese servicio.Los puertos son valores por defecto de compose/.env.example y pueden sobrescribirse por despliegue; consulta Puertos de red por defecto. Varía marca un servicio cuyo puerto por defecto depende de la configuración del despliegue.