Liveness/Readiness樣本

2）設計原則

1.共享語義。

準備就緒：外部滿足查詢的能力（考慮關鍵依賴性）。
活著：「無法治愈」的過程狀態的細節。
2.失敗快速，但不是「false-fast」。自定義「failureThreshold」計時器/閾值,使短暫的爆發不會導致額外的重啟。
3.樣品中沒有重型手術。檢查必須快速（≤100-200毫秒），並且沒有副作用。
4.優美的降解。如果依賴項部分不可訪問,則Readiness=OK（如果存在安全後備程序（緩存/收縮））。
5.Deterministic I/O.狀態僅取決於當前狀態，而不取決於「隨機」外部測試。

3）健康末端的語義

3.1個HTTP方法（推薦）

「GET/healthz/liveness」 → 200如果過程「活著」（事件循環旋轉，GC沒有卡住，看門狗「心臟」跳動）。
「GET/healthz/readiness」 → 200如果實例已準備好用於關鍵類的流量。檢查：連接池、本地緩存、業務邏輯核心可用性。
初始化後「GET/healthz/startup」 → 200（緩存遷移/加熱/模型加載）。

• 你不能活著去外部DB/API-這將導致成癮事件期間的「自殺」。
• 在準備就緒中，可以測試關鍵依賴性，但是隨著時間的流逝和退化：如果有一個有效的後衛-不要倒下。

3.2 gRPC Health Checking

使用'grpc標準。health.v1.具有Service scoped狀態的健康/檢查（「SERVING」，「NOT_SERVING」）。對於Kubernetes，是grpc樣本（或http代理）。

3.3內部觸發器

看門狗「軟」停止：在SIGTERM中，顯示Readiness=FAIL →等待「terminationGracePeriodSeconds」 →通過排隊完成。

4）計時和急流（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分鐘）
• 在啟動成功後激活就緒/生活
• Batch/consumer:

準備就緒反映了處理準備（連接到經紀人，是否存在DLQ降解），

liveness-內部心跳循環。

故障後坐力：在應用程序中,使用指數後坐力重新連接到依賴項,否則就緒將「剝離」。

5）配置（片段）

5.1 Kubernetes, 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樣本

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（停止接受）,給時間完成活動請求。

6）成癮和退化

關鍵（沒有它們就無法維護）：「/登錄」的授權數據庫，「/pay」的支付網關。可以使用「timeoutSeconds」樣本的≤80％定時進行準備性檢查。
非臨界：分析、電子郵件、緩存層（如果有掛載）。不要將它們包括在準備工作中；使用後衛。
Feature-flags：當部分降解時,通過保留Readiness=OK來禁用從屬字體。

7）隊列和背景處理程序

Consumers/Workers:

如果已為經紀人建立訂閱/連接,並且有處理資源,則Readiness=確定。
當DLQ/Lag溢出時，Readiness →可以保持OK（如果我們接受和折疊），但是SLI 「新鮮/LA」亮起-根據數據。
Liveness： 控制poll 循環/heartbeat, dedlock檢測器。

等效性：加快從重啟生活中的恢復。

8) Sidecar/mesh/ingress

• 啟用「readinessGate」 （K8s）以考慮附帶狀態,
• 確保樣品不會進入mTLS屏障（或添加例外情況）。
• Ingress/Envoy/Nginx：在本地滾動'/healthz/'，不向外「輸出」內部細節。

9）安全和隱私

Health Endpoints不應披露Configs，庫版本，錯誤行-僅「OK/FAIL」+最小原因代碼。
限制外部訪問（NetworkPolicy/ACL）。對於公眾來說-讓我們只是在沒有細節的情況下直播。
健康檢查的日誌位於DEBUG級別，帶有trottling。

10）可觀察性和SLO

導出指標：'health_readiness {status}、'health_liveness {status}、樣品處理時間'。
將Readiness-flaps與可用性SLO（從Endpoint → 5xx/connection reset）關聯。

• 「頻繁的liveness重新開始>N/hour」是衰落/泄漏的癥狀。
• 「Flap Readiness> X/15 min」是依賴/網絡問題的癥狀。
• 與dploy（'service。version`).

11）測試

單位/合同：當關閉每個依賴項時,endpoints '/healthz/'返回正確的狀態。
混亂：DB/緩存/經紀人斷開：準備就緒應嚴格按照模型下降或打開後衛。Liveness-如果過程「活著」不會觸發。
Load/Soak：在負載下，健康端點必須保持快速（不要打孔）。
金絲雀：在流量增加之前檢查準備就緒的穩定性。

12）頻繁的錯誤以及如何避免錯誤

Liveness檢查DB/外部 API。結果是事件無休止的重啟。解決方案：將生活限制在「過程生活」。
樣品中的重檢查。導致虛假拒絕。解決方案：輕松檢查+單獨的背景健康監視器。
沒有Startup Probe。緩慢的開始被liveness「殺死」。解決方案：添加帶有寬窗口的啟動。
缺少graceful shutdown。稀有的5xx變質。解決方案：preStop+退出平衡。
Flap風暴。太激進的閾值。解決方案：舉起「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後端，描述其語義。
• Liveness不觸及外部依賴性；Readiness僅檢查關鍵的taymouth和fallback。
• 將'initialDelay/period/timeout/failureThreshold'配置為服務配置文件。
• 啟用了graceful shutdown： 'preStop'+從平衡中移除。
• 健康指標/邏輯連接；Alertes on restarts/flap。
• 已通過依賴性故障和慢啟動測試。

運營

• 每周重新開始和準備工作報告。
• 事件發生後的閾值調節；與發行版的關系。
• 定期chaos關閉依賴性測試。
• 當依賴關系的關鍵性發生變化時語義的相關性。

15) FAQ

問：是否可以通過一個樣本來關閉所有內容？
答：不希望。分享「啟動」、「準備就緒」、「生活」-減少誤報並加速RCA。

問： 是否在準備就緒中檢查緩存?

答：如果沒有緩存，則有正確的（盡管速度最慢）模式-不要放棄準備，只需啟用降級即可。

問：經常重啟生活怎麼辦？
答：首先排除減速/泄漏；然後放寬閾值並在應用程序中添加看門狗。

問：如何考慮多重性？
答：準備就緒應反映為任何租賃流量提供服務的能力。對於特定租戶的私人問題-不要改變準備工作，而是用單獨的SLI/Alert發出信號。

• 「可觀察性：邏輯，度量，跟蹤」
• 「分布式跟蹤」
• 「SLO/SLA和指標」
• 「網絡手冊交付保證」
• 「In Transit加密」
• 「秘密管理」