Liveness/Readiness muestreo

2) Principios de diseño

1. Divide las semánticas.

Lectura: capacidad externa para atender consultas (tiene en cuenta las dependencias críticas).
Liveness: el detonante de un estado de proceso «incurable».
2. Fail-fast, pero no «false-fast». Configure los timeouts/umbral 'failureThreshold' para que las ráfagas cortas no den lugar a más restarts.
3. No hay cirugías pesadas en las muestras. El chequeo debe ser rápido (≤100 -200 ms) y sin efectos secundarios.
4. Degradación graciosa. Si las dependencias son parcialmente inaccesibles, Readiness = OK si hay un follback seguro (caché/doblez).
5. Deterministic I/O. Los estados dependen únicamente del estado actual y no de las pruebas externas «aleatorias».

3) Semántica de Endpoints HEALTH

3. 1 enfoque HTTP (recomendado)

'GET/healthz/liveness' → 200 si el proceso está «vivo» (el evento-loop gira, GC no se atasca, watchdog «corazón» late).
'GET/healthz/readiness' → 200 si la instancia está lista para el tráfico de la clase crítica. Validaciones: agrupación de conexiones, cachés locales, disponibilidad del motor de lógica empresarial.
'GET/healthz/startup' → 200 después de la inicialización (migración/calentamiento de caché/carga de modelos).

• No es posible en la vida ir a la OBD/API externa - esto dará lugar a «suicidios» durante incidentes de adicciones.
• En la readiness se pueden comprobar las dependencias críticas, pero con los timeouts y la degradación: si hay un folback válido no se puede tumbar.

3. 2 gRPC Health Checking

Utilice el estándar 'grpc. health. v1. Health/Check 'con estados service-scoped (' SERVING ',' NOT _ SERVING '). Para Kubernetes, muestras grpc (o proxy http).

3. 3 Disparadores internos

Parada «suave» de Watchdog: con SIGTERM, exponer Readiness = FAIL → esperar 'terminationGracePeriodSeconds' → terminar practicando colas.

4) Tiempos y umbrales (tuning)

• `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `successThreshold`, `failureThreshold`.

• readiness: `period=5s, timeout=0. 2–0. 5s, failure=2`
• liveness: `period=10s, timeout=0. 2–0. 5s, failure=3`

• startup: 'period = 5s, failure = 60' (hasta ~ 5 min)
• readiness/liveness se activan después del éxito de startup

• readiness refleja la preparación para el procesamiento (conexión con el bróker, si hay degradación DLQ),
• liveness es el loop interno de heartbeat.

Backoff en las fallas: en la aplicación, use backoff exponencial para reconectar a las dependencias, de lo contrario readiness será «aserrar».

5) Configuraciones (fragmentos)

5. 1 Kubernetes, muestras HTTP

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5. 2 Kubernetes, muestra gRPC

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5. 3 Graceful shutdown

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

'/healthz/drain 'dentro del servicio traduce Readiness = FAIL (stop-accepting), da tiempo para completar las consultas activas.

6) Adicciones y degradación

Crítico (sin ellos no se puede servir): BD de autorización para '/login ', pasarela de pago para '/pay'. Se puede comprobar en readiness con un tiempo de espera del ≤80% de la muestra 'timeoutSeconds'.
No crítico: analítica, correo electrónico, capa de caché si hay dosificación. No los incluya en la lista; use un follback.
Características-flags: si se degradan parcialmente, desactive los ficheros dependientes guardando Readiness = OK.

7) Colas y manejadores de fondo

• Readiness = OK si la suscripción/connect al corredor está instalado y hay un recurso para procesar.
• Cuando el DLQ/Lage se desborda, el → Readiness puede permanecer OK (si lo tomamos y lo doblamos), pero SLI «frescura/lag» se enciende - alert según los datos.
• Liveness: Controle el ciclo poll/heartbeat, detector de movimiento rápido.

Idempotencia: acelera la recuperación después de los restarts de liveness.

8) Sidecar/mesh/ingress

• Active 'readinessGate' (K8s) para tener en cuenta el estado sidecar,
• Asegúrese de que las muestras no caigan en las barreras mTLS (o agregue excepciones).
• Ingress/Envoy/Nginx: proxy '/healthz/' localmente, no «salga» de los detalles internos.

9) Seguridad y privacidad

Los endpoints de salud no deben revelar confecciones, versiones de bibliotecas, líneas de error - sólo «OK/FAIL» + código de causa mínimo.
Restringir el acceso externo (NetworkPolicy/ACL). Para los públicos - vamos a sólo liveness-ping sin detalles.
Los registros de comprobación de salud están en el nivel DEBUG, con trottling.

10) Observabilidad y SLO

Exportar métricas: 'health _ readiness {status}', 'health _ liveness {status}', tiempo de procesamiento de muestras.
Asocie las banderas Readiness a SLO de disponibilidad (desactivación de endpoints → reset 5xx/connection).

• «Restarts frecuentes por liveness> N/hora» es un síntoma de deadlock/fugas.
• «Flap Readiness> X/15 min» es un síntoma de problemas de adicción/red.
• Correlación con el deploy ('service. version`).

11) Pruebas

Unidad/Contrato: los endpoints '/healthz/' devuelven los estados correctos cuando se apaga cada dependencia.
Chaos: desactivar el BD/caché/broker: Readiness debe caer o encender el follback estrictamente según el modelo. Liveness - No se desencadenará si el proceso está «vivo».
Load/Soak: bajo carga, los endpoints de salud deben permanecer rápidos (no perforar el contensado).
Canarias: compruebe la estabilidad de Readiness antes de aumentar el tráfico.

12) Errores frecuentes y cómo evitarlos

Liveness comprueba la DAB/API externa. El resultado son infinitos restarts en incidentes. Solución: limitar la vida a la «vida del proceso».
Pruebas pesadas en las muestras. Conduce a falsos rechazos. Solución: controles fáciles + monitores individuales de background-health.
No Startup Probe. Los inicios lentos son «matados» por la vida. Solución: agregue startup con una ventana amplia.
Sin graceful shutdown. Raro 5xx en el deploe. Solución: preStop + eliminación del equilibrio.
Tormentas de bandera. Umbrales demasiado agresivos. Solución: elevar 'failureThreshold', aumentar 'timeoutSeconds', añadir backoff.
Los mismos endpoints para todo. Mezcla de semánticas. Solución: «liveness/readiness/startup» individual.

13) Mini patrones de implementación

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14) Hojas de cheques

Antes de la venta

• Separados por endpoints liveness/readiness/startup, se describe su semántica.
• Liveness no toca las dependencias externas; Readiness sólo comprueba los críticos con timeout y follback.
• Configurado 'initialDelay/period/timeout/failureThreshold' para el perfil de servicio.
• Activado graceful shutdown: 'preStop' + retirada del equilibrio.
• Métricas/registros de salud conectados; alertas en restart/flap.
• Se han superado las pruebas de fallas de dependencia y arranque lento.

Operación

• Informe semanal sobre reestarts y flaps readiness.
• Afinar los umbrales después de los incidentes; conexión con lanzamientos.
• Pruebas regulares de apagado de dependencias chaos.
• La relevancia de las semánticas cuando se cambia la criticidad de las dependencias.

15) FAQ

P: ¿Se puede cerrar todo con una sola muestra?
R: No es deseable. Compartir 'startup', 'readiness', 'liveness': reduce los falsos positivos y acelera el RCA.

P: ¿Está comprobando la caché en readiness?
R: Si sin caché hay un modo correcto (aunque sea el más lento) - No valide readiness, simplemente active la degradación.

P: ¿Qué hacer con los restarts frecuentes por liveness?
R: Elimine primero el taladro/fugas; luego afloje los umbrales y agregue el reloj en la aplicación.

P: ¿Cómo tener en cuenta el multiarrendamiento?
R: Readiness debe reflejar la capacidad de servir a cualquier tráfico de alquiler. Para los problemas privados de un inquilino específico - no cambie la readiness, sino señale con SLI/alertas separadas.

• «Observabilidad: registros, métricas, trazados»
• «Trazados distribuidos»
• «SLO/SLA y métricas»
• "Garantías de entrega de webhooks'
• «Encriptación In Transit»
• «Gestión de secretos»