Health Check#

Using gRPC#

You can check every individual Executor, by using a standard gRPC health check endpoint. In most cases this is not necessary, since such checks are performed by Jina, a Kubernetes service mesh or a load balancer under the hood. Nevertheless, you can perform these checks yourself.

When performing these checks, you can expect one of the following ServingStatus responses:

  • UNKNOWN (0): The health of the Executor could not be determined

  • SERVING (1): The Executor is healthy and ready to receive requests

  • NOT_SERVING (2): The Executor is not healthy and not ready to receive requests

  • SERVICE_UNKNOWN (3): The health of the Executor could not be determined while performing streaming

See Also

To learn more about these status codes, and how health checks are performed with gRPC, see here.

Let’s check the health of an Executor. First start a dummy executor from the terminal:

jina executor --port 12346

In another terminal, you can use grpcurl to send gRPC requests to your services.

docker pull fullstorydev/grpcurl:latest
docker run --network='host' fullstorydev/grpcurl -plaintext 127.0.0.1:12346 grpc.health.v1.Health/Check

{
  "status": "SERVING"
}

Using HTTP#

Caution

For Executors running with HTTP, the gRPC health check response codes outlined above do not apply.

Instead, an error-free response signifies healthiness.

When using HTTP as the protocol for the Executor, you can query the endpoint '/' to check the status.

First, create a Deployment with the HTTP protocol:

from jina import Deployment

d = Deployment(protocol='http', port=12345)
with d:
    d.block()

Then query the “empty” endpoint:

curl http://localhost:12345

You get a valid empty response indicating the Executor’s ability to serve:

{}