使用/healthz进行应用程序运行状况检查的惯例从何而来? [英] Where does the convention of using /healthz for application health checks come from?

问题描述

在Kubernetes/Docker生态系统中，约定使用/healthz 作为应用程序的运行状况检查终结点.

In the Kubernetes/Docker ecosystem there is a convention of using /healthz as a health-check endpoint for applications.

"healthz"这个名字是从哪里来的，与该名字相关的语义是否特殊?

Where does the name 'healthz' come from, and are there any particular semantics associated with that name?

推荐答案

从历史上讲，它来自Google的内部实践.它们称为"z页".

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

以 z 结尾的原因是为了减少与具有相同名称(例如/status )的实际应用程序端点的冲突.有关更多信息，请参见此演讲: https://vimeo.com/173610242

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

相似的端点(至少在Google内部)是/varz ，/statusz ，/rpcz .Google开发的服务会自动使这些端点导出其运行状况和指标，并且有一些工具可以从所有已部署的服务中收集公开的指标/状态.

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.

像Prometheus这样的开源工具通过到达著名的端点从您的应用程序收集指标来实现这种模式(因为Prometheus的原始作者也是Google的前任).同样， OpenCensus 允许您从应用程序(最好在其他端口)上显示应用程序的Z页面，以诊断问题.

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.

这篇关于使用/healthz进行应用程序运行状况检查的惯例从何而来?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！