Liveness/Readonists

2) დიზაინის პრინციპები

1. გაიზიარეთ სემანტიკა.

Readiness: მოთხოვნების მომსახურების გარე უნარი (ითვალისწინებს კრიტიკულ დამოკიდებულებებს).
Liveness: პროცესის „განუკურნებელი“ მდგომარეობის დეტალი.
2. Fail-fast, მაგრამ არა „false-fast“. TailuretThreshold- ის კონფიგურაცია/ბარიერი ისე, რომ მოკლე აურზაურებმა არ გამოიწვიოს ზედმეტი გადატვირთვა.
3. არ არის მძიმე ოპერაციები ნიმუშებში. შემოწმება უნდა იყოს სწრაფი (100-200 ms) და გვერდითი მოვლენების გარეშე.
4. მოხდენილი დეგრადაცია. დამოკიდებულების ნაწილობრივი მიუწვდომელობით - Readiness = OK, თუ არსებობს უსაფრთხო ფოლკლორი (ქეში/დამხობა).
5. Deterministic I/O. სტატუსები დამოკიდებულია მხოლოდ ამჟამინდელ მდგომარეობაზე და არა „შემთხვევითი“ გარე ტესტებზე.

3) HEALTH ენდოინების სემანტიკა

3. 1 HTTP მიდგომა (რეკომენდებულია)

'GET/healthz/liveness' 200 თუ პროცესი „ცოცხალია“ (მოვლენები-სისხლი ტრიალებს, GC არ ჩერდება, watchdog „გული“ სცემს).
'GET/healthz/readiness' 200, თუ ნიმუში მზად არის კრიტიკული კლასის ტრაფიკისთვის. შემოწმებები: კავშირების აუზები, ადგილობრივი ქეში, ბიზნეს ლოგიკის ბირთვის ხელმისაწვდომობა.
'GET/healthz/startup' 200 ინიციალიზაციის შემდეგ (ქეში/დატვირთვა).

• შეუძლებელია liveness- ში წასვლა გარე მონაცემთა ბაზაში/API - ეს გამოიწვევს „თვითმკვლელობას“ დამოკიდებულების ინციდენტების დროს.
• რეალობაში, თქვენ შეგიძლიათ შეამოწმოთ კრიტიკული დამოკიდებულებები, მაგრამ ტაიმაუტებითა და დეგრადაციით: თუ არსებობს ნამდვილი ფოლბეკი, არ დაეცა.

3. 2 gRPC Health Checking

გამოიყენეთ სტანდარტი 'grpc. health. v1. HEAlth/Check 'სერვისის სახელმწიფოებით (' SERVING ',' NOT _ SERVING '). Kubernetes- ისთვის - grpc ტესტები (ან http მარიონეტული).

3. 3 შინაგანი გამომწვევები

Watchdog არის „რბილი“ გაჩერება: SIGTERM- ით გამოავლინეთ Readiness = FAIL, დაელოდეთ 'terminationationGracePeriodSeconds' - ს, ხაზების დამუშავებით.

4) ტაიმინგი და ბარიერები

• `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 წუთამდე)
• startup- ის წარმატების შემდეგ გააქტიურებულია readiness/liveness

• რეალობა ასახავს დამუშავების მზადყოფნას (ბროკერთან დაკავშირება, არის თუ არა DLQ დეგრადაცია),
• liveness არის შიდა heartbeat loop.

ზურგჩანთა უარის თქმის შესახებ: პროგრამა გამოიყენებს ექსპონენციალურ backoff- ს დამოკიდებულებაზე გადასატანად, წინააღმდეგ შემთხვევაში readiness „spike“ იქნება.

5) კონფიგურაცია (ფრაგმენტები)

5. 1 კუბერნეტები, 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 კუბერნეტები, 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 'სერვისის შიგნით თარგმნის Readiness = FAIL (Stop-accepting), აძლევს დროს აქტიური თხოვნების დასრულებას.

6) დამოკიდებულება და დეგრადაცია

კრიტიკული (მათ გარეშე ვერ მოემსახურება): ავტორიზაციის მონაცემთა ბაზა '/login ', გადახდის კარიბჭე '/გადახდა'. თქვენ შეგიძლიათ შეამოწმოთ „TimeoutSeconds“ ნიმუშის 80% ფასდაკლებით.
არაკრიტიკული: ანალიტიკა, email, ქეშის ფენა დისტანციური დატვირთვის თანდასწრებით. ნუ ჩართავთ მათ რეალობაში; გამოიყენეთ ფოლბეკი.
Feature-flags: ნაწილობრივი დეგრადაციით გამორთეთ დამოკიდებული ფიჩები, შეინარჩუნეთ Readiness = OK.

7) რიგები და ფონის დამუშავება

• Readiness = OK, თუ ბროკერისთვის გამოწერა/კონექტი დამონტაჟებულია და დამუშავების რესურსი არსებობს.
• DLQ/Lage გადატვირთვისას, Readness შეიძლება დარჩეს OK (თუ ჩვენ ვიღებთ და დავაკეცავთ), მაგრამ SLI „სიახლე/lag“ ანათებს - ალერტის მიხედვით.
• Liveness: გააკონტროლეთ პოლარული ციკლი/heartbeat, ბაბუის დეტექტორი.

Idempotention: აჩქარებს აღდგენას liveness restarts- ის შემდეგ.

8) Sidecar/mesh/ingress

• ჩართეთ 'readexGate' (K8s) sidecar სტატუსის დასადგენად,
• დარწმუნდით, რომ ნიმუშები არ შედის mTLS ბარიერებში (ან გამონაკლისის დამატება).
• Ingress/Envoy/Nginx: შეამოწმეთ '/healthz/' ადგილობრივად, ნუ „გამოიყვანთ“ შიდა დეტალებს.

9) უსაფრთხოება და კონფიდენციალურობა

Health endpoints- მა არ უნდა გამოავლინოს კონფიგურაციები, ბიბლიოთეკების ვერსიები, შეცდომების ხაზები - მხოლოდ „OK/FAIL“ + მიზეზის მინიმალური კოდი.
გარედან წვდომა შეზღუდულია (ქსელის პოლიტიკა/ACL). საჯარო - მოდით, მხოლოდ liveness პინგი დეტალების გარეშე.
ჯანმრთელობის შემოწმების ლოგოები - DEBUG დონეზე, trottling.

10) დაკვირვება და SLO

ექსპორტზე მრიცხველები: 'health _ readiness {status}', 'health _ liveness {status}', ნიმუშის დამუშავების დრო.
დაუკავშირეთ Readonness floods და SLO წვდომა (ენდოინტებიდან გამოტოვება 5xx/Concestion Reset).

• „ხშირი გადატვირთვა liveness> N/საათში“ არის ბედლოკების/გაჟონვის სიმპტომი.
• „Flap Readiness> X/15 წთ“ არის დამოკიდებულების/ქსელის პრობლემების სიმპტომი.
• კორელაცია ('მომსახურება. version`).

11) ტესტირება

Unit/Contract: endpoints '/healthz/' ბრუნდება სწორი სტატუსები, როდესაც გამორთულია თითოეული დამოკიდებულება.
Chaos: BD/ქეში/ბროკერის გამორთვა: Readoniness უნდა დაეცეს ან შეიცავდეს ფოლკლორს მკაცრად მოდელის მიხედვით. Liveness - არ გამოდგება, თუ პროცესი „ცოცხალია“.
Load/Soak: Health endpoints- ის დატვირთვის ქვეშ, ისინი სწრაფად უნდა დარჩნენ (არ გააფართოვოს ჭურვი).
Canary: შეამოწმეთ Readiness- ის სტაბილურობა ტრაფიკის გაზრდამდე.

12) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

Liveness ამოწმებს BD/გარე API. შედეგი - ინციდენტების გაუთავებელი რესტავრაცია. გამოსავალი: შეზღუდეთ „პროცესის ცხოვრება“.
მძიმე ტესტები ნიმუშებში. იწვევს ცრუ უარს. გამოსავალი: მსუბუქი შემოწმება + ცალკეული ზურგჩანთა ჯანმრთელობის მონიტორები.
არა Startup Probe. ნელი სტარტები „კლავს“ ცხოვრებას. გამოსავალი: დაამატეთ startup ფართო ფანჯრით.
Graceful shutdown- ის არარსებობა. იშვიათი 5xx უკანა მხარეს. გამოსავალი: preStop + დაბალანსება.
ფლოპის ქარიშხალი. ძალიან აგრესიული ბარიერები. გამოსავალი: გაზარდეთ 'failureThreshold', გაზარდეთ 'TimeoutSeconds', დაამატეთ backoff.
იგივე ენდოინები ყველაფრისთვის. სემანტიკური ნაზავი. გამოსავალი: ინდივიდუალური 'liveness/readiness/startup'.

13) მინი შაბლონები

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) ჩეკის ფურცლები

გაყიდვამდე

• ენდოპოინტი liveness/readiness/startup იყოფა, მათი სემანტიკა აღწერილია.
• ცხოვრება არ ეხება გარე დამოკიდებულებებს; Readiness ამოწმებს მხოლოდ კრიტიკულ ტაიმუთს და ფოლბეკს.
• „initialDelay/period/timeout/failureThreshold“ მომსახურების პროფილის ქვეშ.
• შედის graceful shutdown: 'preStop' + დაბალანსება.
• მეტრიკები/ჯანმრთელობის ლოგოები დაკავშირებულია; ალერტები restarts/flop.
• დამოკიდებულებისა და ნელი დაწყების უარყოფის ტესტები დასრულდა.

ოპერაცია

• ყოველკვირეული მოხსენება restarts და reading flaps.
• ინციდენტების შემდეგ ბარიერი; კავშირი გამოშვებებთან.
• დამოკიდებულების გამორთვის რეგულარული ქაოსის ტესტები.
• სემანტიკების აქტუალობა დამოკიდებულების კრიტიკულად შეცვლისას.

15) FAQ

გ: შესაძლებელია თუ არა ყველაფრის დახურვა ერთი ნიმუშით?
ო: არასასურველია. გაყოფა 'startup', 'readiness', 'liveness' - ეს ამცირებს ცრუ მოქმედებებს და აჩქარებს RCA- ს.

გ: შეამოწმეთ ქეში რეალობაში?
ო: თუ ქეშის გარეშე არსებობს სწორი (თუმც ნელი) რეჟიმი - ნუ დააყოვნებთ რეალობას, უბრალოდ ჩართეთ დეგრადაცია.

გ: რა უნდა გავაკეთოთ ხშირი შეზღუდვებით?
ო: პირველი, გამორიცხეთ ბაბუა/გაჟონვა; შემდეგ შეასუსტეთ ბარიერები და დაამატეთ watchdog განაცხადში.

გ: როგორ გავითვალისწინოთ მრავალფეროვნება?
O: Readiness უნდა ასახავდეს ნებისმიერი გაქირავების ტრაფიკის მომსახურების უნარს. კონკრეტული მოიჯარის პირადი პრობლემებისთვის - ნუ შეცვლით რეალობას, მაგრამ მიუთითეთ ცალკეული SLI/ალერტებით.

• „დაკვირვება: ლოგოები, მეტრიკები, ტრეკები“
• „განაწილებული ტრეკები“
• „SLO/SLA და მეტრიკა“
• „ვებ ჰუკების მიწოდების გარანტიები“
• „დაშიფვრა In Transit“
• საიდუმლო მენეჯმენტი