Mostre de viață/pregătire

2) Principii de proiectare

1. Semantică separată.

Disponibilitate: capacitatea externă de a solicita servicii (ia în considerare dependențele critice).
Liveness: Detectabilitatea stării „incurabile” a procesului.
2. Fail-rapid, dar nu fals-rapid. Ajustați termenele/pragul „Pragul de eșec”, astfel încât exploziile scurte să nu conducă la reporniri inutile.
3. Fără operaţii grele în probe. Verificarea trebuie să fie rapidă (≤100 -200 ms) și fără efecte secundare.
4. Degradare graţioasă. În caz de indisponibilitate parțială a dependențelor - Readiness = OK, dacă există un folback sigur (cache/coarsening).
5. Deterministic I/O. Statusurile depind numai de starea curentă, nu de testele externe „aleatorii”.

3) Semantica criteriilor finale HEALTH

3. 1 abordare HTTP (recomandat)

„GET/healthz/livness” → 200 în cazul în care procesul este „viu” (eveniment-loop se învârte, GC nu este blocat, watchdog „inima” este bate).
„GET/healthz/readiness” → 200 dacă instanța este pregătită pentru traficul de clasă critică. Verificări: piscină de conexiune, cache-uri locale, disponibilitate kernel logica de afaceri.
„GET/healthz/startup” → 200 după inițializare (modele de încălzire/încărcare a memoriei cache).

• Nu puteți merge la baze de date externe/API-uri în viață - acest lucru va duce la „sinucideri” în timpul incidentelor de dependență.
• În pregătire, puteți verifica dependențele critice, dar cu timeout și degradare: dacă există un folback valid, nu-l aduceți în jos.

3. 2 gRPC Health Checking

Foloseşte standardul 'grpc'. sănătate. v1. Health/Check 'cu state de serviciu („SERVIRE”, „NU _ SERVIRE”). Pentru sondele Kubernetes - grpc (sau http proxy).

3. 3 Declanșatoare interne

Watchdog „soft' stop: cu setul SIGTERM Readiness = FAIL → așteptați” terminationGracePeriodSeconds' → sfârșit, lucrând cozi.

4) Temporizări și praguri (tuning)

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

• pregătire: 'perioada = 5s, timeout = 0. 2–0. 5s, eșec = 2 '
• liveness: 'perioada = 10s, timeout = 0. 2–0. 5s, eșec = 3 '

• pornire: 'perioada = 5s, esec = 60' (pana la ~ 5 min)
• pregătire/viață activată după succesul startup-ului

• disponibilitatea reflectă disponibilitatea pentru procesare (conectarea la un broker, indiferent dacă există degradare DLQ),
• liveness - buclă de bătăi ale inimii interioare.

Backoff pe eșecuri: în aplicație, utilizați backoff exponențial pentru a reconecta la dependențe, în caz contrar pregătirea va „văzut”.

5) Configurații (fragmente)

5. 1 Kubernete, sonde 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 Kubernete, eșantion gRPC

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

5. 3 Închidere grațioasă

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

„/healthz/drain ”în interiorul serviciului traduce Readiness = FAIL (stop-accepting), oferă timp pentru a completa cererile active.

6) Dependențe și degradare

Critic (nu poate fi deservit fără ele): baza de date de autorizare pentru '/login ', poarta de plată pentru '/pay'. Poate fi verificat în pregătire cu timeout ≤80% din "timeoutSeconds' probe.
Non-critic: analiză, e-mail, strat cache dacă există o sarcină. Nu-i includeți în pregătire; utilizați un folbeck.
Feature-flags: Dacă caracteristicile dependente sunt parțial degradate, dezactivați în timp ce mențineți disponibilitatea = OK.

7) Cozi și manipulatori de fundal

• Readiness = OK dacă este instalat un abonament/conexiune la broker și există o resursă de procesat.
• Când DLQ/lag overflow → Readiness poate rămâne OK (dacă acceptăm și adăugăm), dar SLI „prospețime/lag” se aprinde - alertă în funcție de date.
• Liveness: controlați ciclul de sondaj/bătăile inimii, deathdetector.

Idempotența: Accelerează recuperarea de la repornirea vieții.

8) Sidecar/plasă/intrare

• Activați „readinessGate” (K8s) pentru a ține cont de starea atașamentului,
• Asigurați-vă că eșantioanele nu se încadrează în barierele mTLS (sau adăugați excepții).
• Ingress/Envoy/Nginx: Prox '/healthz/' local, nu „scoate” piese interne.

9) Securitate și confidențialitate

Punctele finale de sănătate nu ar trebui să dezvăluie configurații, versiuni de bibliotecă, șiruri de erori - numai „OK/FAIL” + codul minim de cauză.
Restricționați accesul în exterior (NetworkPolicy/ACL). Pentru public - să doar liveness-ping fără detalii.
Jurnalele de controale de sănătate - la nivelul DEBUG, cu throttling.

10) Observabilitate și SLO

Indicatori de export: 'health _ readiness {status}', 'health _ livness {status}', timp de procesare a probelor.
Steaguri Associate Readiness cu SLO-uri de disponibilitate (drop from endpoints → 5xx/connection reset).

• „Reporniri frecvente prin livness> N/oră” - un simptom al blocajului/scurgerilor.
• „Flap Readiness> X/15 min” - un simptom al problemelor de dependență/rețea.
• Corelarea cu implementarea ("service. versiunea ").

11) Testarea

Unitate/Contract: Endpoints '/healthz/' returnează statusurile corecte atunci când fiecare dependență este dezactivată.
Haos: dezactivarea bazei de date/cache/broker: Pregătirea ar trebui să cadă sau să permită folback strict în funcție de model. Liveness - nu se declanșează dacă procesul este „viu”.
Încărcați/înmuiați: Sub sarcină, punctele finale de sănătate trebuie să rămână rapide (nu împingeți conținutul).
Canare: Verificați stabilitatea pregătirii înainte de creșterea traficului.

12) Greșeli frecvente și cum să le evitați

Livness verifică bazele de date/API-urile externe. Rezultatul este repornirea fără sfârșit pentru incidente. Soluția: limitarea viețuirii la „procesarea vieții”.
Controale grele în probe. Duce la false eşecuri. Soluție: controale ușoare + monitoare individuale de fond-sănătate.
Nu există sondă de pornire. Pornirile lente sunt „ucise” de viaţă. Soluție: adăugați pornire cu o fereastră largă.
Fără închidere graţioasă. Rare 5xx în depla. Soluţie: dezechilibru preStop +.
Flap furtuni. Praguri prea agresive. Soluție: ridicați 'Pragul de eșec', creșteți 'timpul de ieșireSecunde', adăugați backoff.
Aceleaşi puncte finale pentru orice. Amestecarea semanticii. Solutie: individual 'liveness/readiness/startup'.

13) Mini Modele de implementare

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) Liste de verificare

Înainte de vânzare

• Punctele finale de viață/pregătire/pornire sunt separate, semantica lor este descrisă.
• Liveness nu atinge dependențele externe; Pregătirea testează numai critice cu timeout și folbeck.
• Configurat 'initialDelay/period/timeout/failingThreshold' pentru profilul de serviciu.
• oprire grațioasă activată: 'preStop' + dezechilibru.
• Măsurătorile/jurnalele de sănătate sunt conectate; alerte la reporniri/clapete.
• Eșecul dependenței și testele de pornire lentă au trecut.

Funcționare

• Raportul săptămânal privind repornirile și steagurile de pregătire.
• Tuning praguri după incidente; conexiune cu versiuni.
• Teste regulate de haos ale dependențelor de dezactivare.
• Relevanța semanticii atunci când critica dependenței se schimbă.

15) ÎNTREBĂRI FRECVENTE

Î: Este posibil să închideți totul cu o singură defecțiune?
R: Nedorite. Separați „pornire”, „pregătire”, „viață” - acest lucru reduce pozitivele false și accelerează RCA.

Î: Verific memoria cache în pregătire?
R: Dacă există un mod corect (deși mai lent) fără o memorie cache, nu coborâți pregătirea, doar porniți degradarea.

Î: Ce trebuie să faceți cu repornirile frecvente pentru viață?
R: Excludeți mai întâi un dektor/scurgere; apoi slăbiți pragurile și adăugați un câine de pază în aplicație.

Î: Cum contabilizăm multi-chirie?
R: Disponibilitatea ar trebui să reflecte capacitatea de a deservi orice trafic de închiriere. Pentru problemele private ale unui anumit chiriaș - nu schimbați disponibilitatea, ci semnalizați cu SLI/alerte separate.

• „Observabilitate: busteni, metrici, urme”
• „Urme distribuite”
• „SLO/SLA și metrici”
• „Garanții de livrare prin broșură web”
• „În criptarea tranzitului”
• „Managementul secret”