W ekosystemie Kubernetes / Docker obowiązuje konwencja używania /healthz
jako punktu końcowego kontroli kondycji dla aplikacji.
Skąd pochodzi nazwa „healthz” i czy jest z nią związana jakaś szczególna semantyka?
źródło
W ekosystemie Kubernetes / Docker obowiązuje konwencja używania /healthz
jako punktu końcowego kontroli kondycji dla aplikacji.
Skąd pochodzi nazwa „healthz” i czy jest z nią związana jakaś szczególna semantyka?
Historycznie pochodzi z wewnętrznych praktyk Google. Nazywają się „stronami Z”.
Powodem, dla którego się kończy, z
jest zmniejszenie kolizji z rzeczywistymi punktami końcowymi aplikacji o tej samej nazwie (np /status
.). Zobacz tę rozmowę, aby uzyskać więcej informacji: https://vimeo.com/173610242
Podobne punkty końcowe (przynajmniej wewnątrz Google) są /varz
, /statusz
, /rpcz
. Usługi opracowane w Google automatycznie pobierają te punkty końcowe w celu eksportowania ich kondycji i wskaźników, a istnieją narzędzia, które zbierają ujawnione wskaźniki / stany ze wszystkich wdrożonych usług.
Narzędzia open source, takie jak Prometheus, wdrażają ten wzorzec (ponieważ oryginalni autorzy Prometheusa są również byłymi pracownikami Google), przechodząc do dobrze znanego punktu końcowego w celu zebrania metryk z aplikacji. Podobnie OpenCensus umożliwia udostępnianie stron Z z Twojej aplikacji (najlepiej na innym porcie) w celu diagnozowania problemów.