Liveness/Readiness amostras

2) Princípios de design

1. Divida as semânticas.

Readiness: capacidade externa para atender a solicitação (considerando dependências críticas).
Liveness: Detecção do estado terminal do processo.
2. Fast-fast, mas não «falso-fast». Configure os temporizadores/limiar 'failureThreshold' para que os picos curtos não causem restabelecimentos.
3. Nada de cirurgias difíceis nas provas. A verificação deve ser rápida (≤100 -200 ms) e sem efeitos colaterais.
4. Degradação graciosa. Se as dependências não estiverem disponíveis parcialmente - Readiness = OK, se houver um folbeck seguro (dinheiro/entulho).
5. Deterministic I/O. Os estados dependem apenas do estado atual, não de testes externos «aleatórios».

3) Semântica HEALTH-endpoint

3. 1 abordagem HTTP (recomendado)

'GET/healthz/liveness' → 200 se o processo estiver «vivo» (event-loop rodando, GC não está preso, watchdog «coração» bate).
'GET/healthz/readiness' → 200 se a instância estiver pronta para o tráfego de classe crítica. Verificações: pool de conexões, cachês locais, disponibilidade do núcleo de lógica empresarial.
'GET/healthz/startup' → 200 após a inicialização (migração/aquecimento do cachê/download de modelos).

• Não se pode ir em liveness a um BB/API externo, o que levaria a «suicídios» em incidentes de dependência.
• No readiness, é possível verificar dependências críticas, mas com temporizações e degradação, se houver um folbeque valido, não pode sair.

3. 2 gRPC Health Checking

Use o padrão 'grpc. health. v1. Health/Check 'com estados service-scoped (' SERVING ',' NOT _ SERVING '). Para Kubernetes - amostras grpc (ou http-proxy).

3. 3 Desencadeadores internos

Watchdog «suave» paragem: com SIGTERM expor Readiness = FAIL → esperar 'terminationGracePeriodSeconds' → terminar, trabalhando filas.

4) Timing e liminares (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: 'perod = 5s, failure = 60' (até £5 min)
• readiness/liveness são ativados após o sucesso da startup

• readiness reflete a preparação para processamento (conexão com corretor, se há degradação DLQ),
• liveness - heartbeat loop interno.

Bacof em falhas: No aplicativo, use backoff exponencial para converter-se às dependências, ou o readiness será «serrado».

5) Configurações (fatias)

5. 1 Kubernetes, amostras 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, gRPC-amostra

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 do serviço traduz Readiness = FAIL (stop-accepting), dando tempo para concluir as solicitações ativas.

6) Dependências e degradação

Criticas (sem elas não podem ser atendidas): BD de autorização para '/login ', entrada de pagamento para '/pay'. Você pode verificar no readiness com um temporizador de % da prova.
Não-ríticos: analista, email, camada de dinheiro quando há um dogro. Não os inclua no readiness; Use o folbeck.
Função-flags: Em caso de degradação parcial, desabilite os fichas dependentes mantendo o Readiness = OK.

7) Filas e processadores de fundo

• Readiness = OK se a assinatura/conector do corretor está instalada e há um recurso para processamento.
• Quando o DLQ/laje é cheio, o Readiness pode ficar OK (se aceitar e dobrar), mas o SLI «frescura/liga» se acende - alert de acordo com os dados.
• Liveness: controle o ciclo poll/heartbeat, detector de dados.

Idempotidade: acelera a recuperação dos restartes liveness.

8) Sidecar/mesh/ingress

• Ative 'readinessGate' (K8s) para o status sidecar,
• Verifique se as provas não entram em barreiras mTLS (ou adicione exceções).
• Enquress/Envoy/Nginx: Procure '/healthz/' localmente, não 'traga para fora' as peças internas.

9) Segurança e privacidade

Os health-endpoints não devem revelar configs, versões de bibliotecas, linhas de erro - apenas «OK/FAIL» + o código mínimo de causa.
Limite o acesso externo (NetworkPolicy/ACL). Para público - vamos só liveness-ping sem detalhes.
Logs de verificação health - nível DEBUG, com trottling.

10) Observabilidade e SLO

Exporte as métricas: 'health _ readiness se você está empenhado na amostra.
Vincule o Readiness Flaps ao SLO de disponibilidade (queda de endpoint → 5xx/connect reset).

• «Restabelecimentos frequentes liveness> N/hora» é um sintoma de deads/fugas.
• «Flap Readiness> X/15 min» é um sintoma de dependência/problemas de rede.
• Correlação com o deploy ('service. version`).

11) Testes

Unit/Contract: Os endpoints '/healthz/' devolvem os estados corretos quando cada vício é desligado.
Chaos: desativar o BD/dinheiro/corretor: Readiness deve cair ou ligar o folback de acordo com o modelo. Liveness - Não será desencadeado se o processo estiver vivo.
Load/Soak: Sob a carga de health-endpoint, deve permanecer rápido (não furar contensões).
Canady: verifique a estabilidade do Readiness antes de aumentar o tráfego.

12) Erros frequentes e como evitá-los

O Liveness verifica o BD/API externo. O resultado são restrições sem fim nos incidentes. A solução é limitar a liveness a «vida do processo».
Testes pesados nas provas. Leva a falhas falsas. Solução: Verificações leves + monitores de background-health individuais.
Não há Startup Probe. Os lentos lançamentos estão a «perder» liveness. A solução é adicionar um startup com uma janela ampla.
Falta de graceful shutdown. Raras 5xx para deplóide. Solução: preStop + retirada do balanço.
Tempestades de flap. Liminares muito agressivos. A solução é levantar 'failureThreshold', aumentar 'timeoutSeconds', adicionar backoff.
Endpoint iguais para tudo. Mistura de semânticos. Solução: individuais 'liveness/readiness/startup'.

13) Mini-pattern de implementação

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) Folhas de cheque

Antes de vender

• Divididos por endpoints liveness/readiness/startup, descrito por sua semântica.
• Liveness não toca em dependências externas; Readiness só verifica os críticos com timeouts e folbeck.
• Configurado 'initialDelay/period/timeout/failureThreshold' para o perfil do serviço.
• Graceful shutdown incluído: 'preStop' + retirada do balanço.
• As métricas/logs de saúde estão conectados; Alertas de restinga/flap.
• Testes de falhas de dependência e iniciações lentas foram concluídos.

Operação

• Relatório semanal sobre restartes e flaps readiness.
• Sintonizar as liminares após os incidentes; A ligação com os lançamentos.
• Testes chaos regulares de desligamento de dependências.
• Relevância das semânticas quando a criticidade das dependências é alterada.

15) FAQ

Podemos fechar tudo com uma única prova?
Não é desejável. Divida «startup», «readiness», «liveness» - o que reduz o desempenho falso e acelera o RCA.

Em: Verificar se o dinheiro está em readiness?
Se há um modo correto (embora mais lento) sem o cachê, não deixe cair o readiness, basta acionar a degradação.

Em: O que fazer com restartes frequentes liveness?
Exclua primeiro o deadlock/fuga; em seguida, enfraqueça os liminares e adicione watchdog no aplicativo.

Como se leva em conta a multiplicidade?
O Readiness deve refletir a capacidade de atender qualquer tráfego de aluguel. Para problemas privados de um locatário específico - não mude de readiness, mas sinalize com alertas SLI individuais.

• Observabilidade: logs, métricas, traçados
• Traçados distribuídos
• «SLO/SLA e métricas»
• «Garantia de entrega de webhooks»
• Criptografia In Transit
• «Gestão de segredos»