grpc_health_probe:检查gRPC应用程序运行状况的命令行工具

网友投稿 971 2022-10-25

grpc_health_probe:检查gRPC应用程序运行状况的命令行工具

grpc_health_probe:检查gRPC应用程序运行状况的命令行工具

grpc_health_probe(1)

The grpc_health_probe utility allows you to query health of gRPC services that expose service their status through the gRPC Health Checking Protocol.

This command-line utility makes a RPC to /grpc.health.v1.Health/Check. If it responds with a SERVING status, the grpc_health_probe will exit with success, otherwise it will exit with a non-zero exit code (documented below).

grpc_health_probe is meant to be used for health checking gRPC applications in Kubernetes, using the exec probes.

EXAMPLES

$ grpc_health_probe -addr=localhost:5000healthy: SERVING

$ grpc_health_probe -addr=localhost:9999 -connect-timeout 250ms -rpc-timeout 100msfailed to connect service at "localhost:9999": context deadline exceededexit status 2

Installation

It is recommended to use a version-stamped binary distribution:

Refer to the Releases section for binary distributions.

Installing from source (not recommended)

Make sure you have git and go installed.Run: go get github.com/grpc-ecosystem/grpc-health-probeThis will compile the binary into your $GOPATH/bin (or $HOME/go/bin).

Using the gRPC Health Checking Protocol

To make use of the grpc_health_probe, your application must implement the gRPC Health Checking Protocol v1. This means you must to register the Health service and implement the rpc Check that returns a SERVING status.

Since the Health Checking protocol is part of the gRPC core, it has packages/libraries available for the languages supported by gRPC:

[health.proto] [Go] [Java] [Python] [C#/NuGet] [Ruby] ...

Most of the languages listed above provide helper functions that hides implementation details. This eliminates the need for you to implement the Check rpc yourself.

Example: gRPC health checking on Kubernetes

You are recommended to use Kubernetes exec probes and define liveness and readiness checks for your gRPC server pods.

You can bundle the statically compiled grpc_health_probe in your container image. Choose a binary release and download it in your Dockerfile:

RUN GRPC_HEALTH_PROBE_VERSION=v0.3.1 && \ wget -qO/bin/grpc_health_probe https://github.com/grpc-ecosystem/grpc-health-probe/releases/download/${GRPC_HEALTH_PROBE_VERSION}/grpc_health_probe-linux-amd64 && \ chmod +x /bin/grpc_health_probe

In your Kubernetes Pod specification manifest, specify a livenessProbe and/or readinessProbe for the container:

spec: containers: - name: server image: "[YOUR-DOCKER-IMAGE]" ports: - containerPort: 5000 readinessProbe: exec: command: ["/bin/grpc_health_probe", "-addr=:5000"] initialDelaySeconds: 5 livenessProbe: exec: command: ["/bin/grpc_health_probe", "-addr=:5000"] initialDelaySeconds: 10

This approach provide proper readiness/liveness checking to your applications that implement the gRPC Health Checking Protocol.

Health Checking TLS Servers

If a gRPC server is serving traffic over TLS, or uses TLS client authentication to authorize clients, you can still use grpc_health_probe to check health with command-line options:

OptionDescription
-tlsuse TLS (default: false)
-tls-ca-certpath to file containing CA certificates (to override system root CAs)
-tls-client-certclient certificate for authenticating to the server
-tls-client-keyprivate key for for authenticating to the server
-tls-no-verifyuse TLS, but do not verify the certificate presented by the server (INSECURE) (default: false)
-tls-server-nameoverride the hostname used to verify the server certificate

Other Available Flags

OptionDescription
-vverbose logs (default: false)
-connect-timeouttimeout for establishing connection
-rpc-timeouttimeout for health check rpc
-user-agentuser-agent header value of health check requests (default: grpc_health_probe)
-serviceservice name to check (default: "") - empty string is convention for server health

Example:

Start the route_guide example server with TLS by running: go run server/server.go -tls Run grpc_client_probe with the CA certificate (in the testdata/ directory) and hostname override the cert is signed for:$ grpc_health_probe -addr 127.0.0.1:10000 \ -tls \ -tls-ca-cert /path/to/testdata/ca.pem \ -tls-server-name=x.test.youtube.comstatus: SERVING

Exit codes

It is not recommended to rely on specific exit statuses. Any failure will be a non-zero exit code.

Exit CodeDescription
0success: rpc response is SERVING.
1failure: invalid command-line arguments
2failure: connection failed or timed out
3failure: rpc failed or timed out
4failure: rpc successful, but the response is not SERVING

This is not an official Google project.

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:node.js: ws服务端和WebSocket客户端交互示例
下一篇:mitt.js:小型事件发布订阅库
相关文章

 发表评论

暂时没有评论,来抢沙发吧~