背景

在 Kubernetes 的生態(tài)中，習(xí)慣使用 /healthz 作為健康檢查的接口。例如，下面為 kubernetes 官方文檔中配置存活探針和啟動探針的配置文件，將探活的接口命名為 /healthz。與在平時實踐的探活接口命名有些不同，一般我們將探活接口命名為 /health、/whoami 等。

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

解答

/healthz 的命名來自谷歌內(nèi)部的實踐，這樣命名的原因是為了避免與應(yīng)用程序已有的狀態(tài)接口產(chǎn)生沖突。

It historically comes from Google’s internal practices. They're called "z-pages".

The reason it ends with z is to reduce collisions with actual application endpoints with the same name (like /status). See this talk for more: https://vimeo.com/173610242

Similar endpoints (at least inside Google) are /varz, /statusz, /rpcz. Services developed at Google automatically get these endpoints to export their health and metrics and there are tools that collect the exposed metrics/statuses from all the deployed services.

Open source tools like Prometheus implement this pattern (since original authors of Prometheus are also ex-Googlers) by coming to a well-known endpoint to collect metrics from your application. Similarly OpenCensus allows you to expose z-pages from your app (ideally on a different port) to diagnose problems.

相關(guān)資料

• https://stackoverflow.com/questions/43380939/where-does-the-convention-of-using-healthz-for-application-health-checks-come-f
• https://vimeo.com/173610242