Liveness/Readiness nümunələri

2) Dizayn prinsipləri

1. Semantikaları bölüşün.

Readiness: Xarici istəklərə xidmət etmək bacarığı (kritik asılılıqları nəzərə alır).
Liveness: prosesin «sağalmaz» vəziyyətinin detalı.
2. Fail-fast, lakin «false-fast» deyil. Taymaut/eşik 'failureThreshold' ki, qısa sıçrayışlar lazımsız restartlara səbəb olmasın.
3. Nümunələrdə ağır əməliyyatlar yoxdur. Yoxlama sürətli olmalıdır (≤ 100-200 ms) və heç bir yan təsiri yoxdur.
4. Zərif deqradasiya. Asılılığın qismən əlçatmazlığı - Readiness = OK, təhlükəsiz follbek varsa (cache/hack).
5. Deterministic I/O. Statuslar yalnız «təsadüfi» xarici testlərdən deyil, mövcud vəziyyətdən asılıdır.

3) HEALTH end-point semantikası

3. 1 HTTP yanaşması (tövsiyə olunur)

'GET/healthz/liveness' → 200 proses «canlı» olarsa (hadisə-loop fırlanır, GC ilişib deyil, watchdog «ürək» döyünür).
'GET/healthz/readiness' → 200 nümunə kritik sinif trafikə hazırdırsa. Yoxlamalar: qoşulma hovuzu, yerli caches, biznes məntiq nüvəsinin mövcudluğu.
'GET/healthz/startup' → 200 başlanğıc sonra (miqrasiya/cache qızdırma/model yükləmə).

• Xarici DB/API-də yaşamaq mümkün deyil - bu asılılıq hadisələri zamanı «intihara» səbəb olacaq.
• Readiness-də kritik asılılıqları yoxlaya bilərsiniz, lakin taymaut və deqradasiya ilə: əgər valid follbek varsa - düşməyin.

3. 2 gRPC Health Checking

Standart 'grpc istifadə edin. health. v1. Health/Check 's service-scoped states ('SERVING', 'NOT _ SERVING'). Kubernetes üçün - grpc testləri (və ya http-proxy).

3. 3 Daxili tetikləyicilər

«Yumşaq» dayanacaq Watchdog: SIGTERM-də Readiness = FAIL → gözləmək 'terminationGracePeriodSeconds' → növbələri işləyib bitirmək.

4) Tayminq və eşiklər (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' (~ 5 dəqiqəyə qədər)
• readiness/liveness startup müvəffəqiyyətindən sonra aktivləşdirilir

• readiness emala hazır olduğunu əks etdirir (DLQ deqradasiyası var mı, brokerə qoşulmaq),
• liveness - daxili heartbeat loop.

Backoff: Tətbiqdə asılılıqlara yenidən qoşulmaq üçün eksponensial backoff istifadə edin, əks halda readiness «kəsəcək».

5) Konfiqurasiya (fraqmentlər)

5. 1 Kubernetes, HTTP nümunələri

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 testi

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"]

Xidmət daxilində '/healthz/drain 'Readiness = FAIL (stop-accepting) tərcümə edir, aktiv sorğuları tamamlamaq üçün vaxt verir.

6) Asılılıq və deqradasiya

Kritik (onlarsız xidmət göstərilə bilməz): «/login »üçün avtorizasiya DB, «/pay» üçün ödəniş şluzu. Siz 'timeoutSeconds' testinin 80% -dən ≤ vaxtında readiness yoxlaya bilərsiniz.
Kritik olmayan: analitika, e-poçt, əlavə yükləmə olduqda cache təbəqəsi. Onları readiness-ə daxil etməyin; follbek istifadə edin.
Feature-flags: Qismən deqradasiya zamanı Readiness = OK saxlayaraq asılı fiqurları söndürün.

7) Növbələr və fon emalçıları

• Readiness = broker abunə/bağlayıcı quraşdırılmış və emal üçün bir resurs varsa, OK.
• DLQ/lag → həddindən artıq daşdıqda, Readiness OK olaraq qala bilər (qəbul etsək və qatlasaq), lakin SLI «təzəlik/lag» yanır - məlumatlara görə alert.
• Liveness: poll-cycle/heartbeat nəzarət, dedlock detektor.

İdempotentlik: liveness restart sonra bərpa sürətləndirir.

8) Sidecar/mesh/ingress

• sidecar statusunu nəzərə almaq üçün 'readinessGate' (K8s) daxil edin,
• Nümunələrin mTLS maneələrinə daxil olmadığından əmin olun (və ya istisnalar əlavə edin).
• Ingress/Envoy/Nginx: yerli olaraq '/healthz/' prokslayın, daxili hissələri «çıxartmayın».

9) Təhlükəsizlik və məxfilik

Health-end-pointlər konfiqaları, kitabxanaların versiyalarını, səhv xətalarını - yalnız «OK/FAIL» + minimum səbəb kodunu açıqlamamalıdır.
Xaricdən giriş məhdudlaşdırın (NetworkPolicy/ACL). İctimai üçün - yalnız detalları olmadan liveness ping verin.
Sağlamlıq yoxlamaları - DEBUG səviyyəsində, Trottling ilə.

10) Müşahidə və SLO

Metrləri ixrac edin: 'health _ readiness {status}', 'health _ liveness {status}', sınaq müddəti.
Readiness-flapları SLO əlçatanlığı ilə əlaqələndirin (end-pointlərdən düşmə → 5xx/connection reset).

• «Liveness> N/saat» dedlock/sızma simptomudur.
• «Flap Readiness> X/15 min» - asılılıq/şəbəkə problemlərinin simptomudur.
• Deployla korrelyasiya ('service. version`).

11) Test

Unit/Contract: end-pointlər '/healthz/' hər asılılığı söndürdükdə düzgün statusları qaytarır.
Chaos: DB/cache/broker devre: Readiness düşmək və ya ciddi model follbek daxil olmalıdır. Liveness - proses «canlı» olduqda tetiklənmir.
Load/Soak: health end-point yükü altında sürətli qalmalıdır (kontenshn atmayın).
Canary: trafik artmadan əvvəl Readiness sabitliyini yoxlayın.

12) Tez-tez səhvlər və onlardan necə qaçmaq olar

Liveness DB/xarici API yoxlayır. Nəticə - hadisələrdə sonsuz restartlar. Həll: liveness «proses həyatı» məhdudlaşdırmaq.
Ağır testlər. Yanlış uğursuzluqlara səbəb olur. Həll: yüngül yoxlamalar + ayrı-ayrı background-health monitorları.
Startup Probe yoxdur. Yavaş başlanğıc «öldürür» liveness. Həll: geniş pəncərə ilə startup əlavə edin.
graceful shutdown yoxdur. Deployda nadir 5xx. Həll: preStop + balansdan çıxarılması.
Flap fırtınaları. Çox aqressiv eşiklər. Həll: 'failureThreshold' artırmaq, 'timeoutSeconds' artırmaq, backoff əlavə.
Hər şey üçün eyni end nöqtələri. Semantiklərin qarışması. Həll: ayrı-ayrı 'liveness/readiness/startup'.

13) Mini satış nümunələri

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) Çek vərəqləri

Məhsuldan əvvəl

• liveness/readiness/startup endpoints bölünmüş, onların semantika təsvir.
• Liveness xarici asılılıqlara toxunmur; Readiness yalnız kritik zaman və follback ilə yoxlayır.
• Xidmət profili altında 'initialDelay/period/timeout/failureThreshold' konfiqurasiya.
• graceful shutdown aktiv: 'preStop' + balansdan çıxarılması.
• Sağlamlıq metrikası/logları bağlıdır; restart/flap üçün alertlər.
• Asılılıq imtinaları və yavaş başlanğıc testləri keçdi.

Əməliyyat

• readiness restarts və flaps haqqında həftəlik hesabat.
• Hadisələrdən sonra astanaların sazlanması; relizləri ilə əlaqə.
• Mütəmadi chaos testləri asılılığı söndürür.
• Asılılığın kritikliyini dəyişdirərkən semantiklərin aktuallığı.

15) FAQ

S: Hər şeyi bir sınaqla bağlamaq olarmı?
A: Arzuolunmaz. 'Startup', 'readiness', 'liveness' parçalayın - bu, saxta təsirləri azaldır və RCA-nı sürətləndirir.

S: readiness cache yoxlamaq?
A: Əgər cache olmadan düzgün (yavaş olsa da) rejim varsa - readiness-i tərk etməyin, sadəcə deqradasiyanı açın.

S: Liveness-də tez-tez restartlarda nə etmək lazımdır?
A: Əvvəlcə ded/sızmanı istisna edin; sonra eşikləri yüngülləşdirin və app watchdog əlavə edin.

S: Çoxicarə necə nəzərə alınır?
A: Readiness hər hansı bir icarə trafikinə xidmət etmək qabiliyyətini əks etdirməlidir. Xüsusi kirayəçinin şəxsi problemləri üçün - readiness-i dəyişdirməyin, ancaq ayrı SLI/alertlərlə siqnal verin.

• «Müşahidə: loqlar, metriklər, izlər»
• «Paylanmış izlər»
• «SLO/SLA və Metrika»
• «Webhook çatdırılma zəmanətləri»
• «In Transit Şifrələmə»
• «Sirlərin menecmenti»