Learn gRPC - Health Checking, Reflection, and Service Discovery

#Introduction

Your gRPC server is running, but how do other systems know the server is healthy? How can developers call methods without writing a client? And how does a load balancer find available instances? Those three questions are answered by three mechanisms: health checking, reflection, and service discovery.

Episode 9 covers all three. You'll enable the standard health service, turn on reflection for debugging with grpcurl, and understand how DNS, Consul, Kubernetes, and xDS let clients find the right server.

#gRPC Health Checking Standard

#The Standard Health Service

gRPC defines the official health service in grpc/health/v1/health.proto. By using this standard, any tool — Kubernetes probes, load balancers, or clients — can query the server's health the same way:

syntax = "proto3";
 
package grpc.health.v1;
 
service Health {
  rpc Check(HealthCheckRequest) returns (HealthCheckResponse);
}
 
message HealthCheckRequest {
  string service = 1;
}
 
message HealthCheckResponse {
  enum ServingStatus {
    UNKNOWN = 0;
    SERVING = 1;
    NOT_SERVING = 2;
  }
  ServingStatus status = 1;
}

Don't rewrite this: use the implementation from the library. In Go, google.golang.org/grpc/health and healthgrpc provide everything.

#Enabling the Health Service on the Server

import (
    "google.golang.org/grpc/health"
    healthpb "google.golang.org/grpc/health/grpc_health_v1"
)
 
healthSrv := health.NewServer()
healthSrv.SetServingStatus(
    "catalog.v1.CatalogService", healthpb.HealthCheckResponse_SERVING,
)
healthpb.RegisterHealthServer(s, healthSrv)

healthSrv.SetServingStatus(...) tells the monitor that the catalog.v1.CatalogService service is serving. When a dependency goes down — for example the database dies — the status can be changed to NOT_SERVING so traffic isn't routed to a broken instance.

#Probing from the Command Line

A container health check can use grpc-health-probe, a small tool optimized for Kubernetes:

grpc-health-probe -addr=localhost:50051

Output status: SERVING means the server is healthy. The grpc-health-probe -addr=localhost:50051 command can be used as a liveness or readiness probe in Kubernetes.

#gRPC Server Reflection

#Enabling Reflection

Reflection lets clients query the list of services and message definitions without a .proto file. In Go it's just one line:

import "google.golang.org/grpc/reflection"
 
reflection.Register(s)

reflection.Register(s) generates the grpc.reflection.v1.ServerReflection service that grpcurl can use to explore the API dynamically.

#Exploring Services with grpcurl

With reflection enabled, all contract information is available from the server itself:

grpcurl -plaintext localhost:50051 list
grpcurl -plaintext localhost:50051 list catalog.v1.CatalogService
grpcurl -plaintext localhost:50051 describe catalog.v1.Product

The grpcurl -plaintext localhost:50051 list command shows all registered services. This changes your debugging workflow: no need to carry a .proto file around, just ask the server.

#Calling Methods from the Terminal

You can even run a full RPC from the CLI:

grpcurl -plaintext -d '{"id":"p-001"}' \
  localhost:50051 catalog.v1.CatalogService/GetProduct

The JSON output it produces makes manual testing very fast. grpcurl -plaintext -d '{"id":"p-001"}' translates the JSON request to binary protobuf automatically thanks to reflection.

#Modern Service Discovery

#DNS as the Foundation

The simplest approach: the client uses a DNS name. grpc.NewClient("catalog-svc:50051") asks the resolution system to find the IP address. For a single IP, gRPC uses pick_first; for multiple IPs, round_robin — episode 10 covers both.

#Consul

Consul provides a service registry: servers register themselves, clients query via API or DNS. Registration is often combined with health checks:

consul services register -name=catalog -port=50051
consul catalog services

The consul services register -name=catalog -port=50051 command registers the instance; clients find healthy instances via the catalog.service.consul query.

#Kubernetes and xDS

In Kubernetes, the Service object selects healthy pods via readiness probes — where grpc-health-probe plays its role. For smarter load balancing, xDS is the control protocol used by Envoy and Istio: gRPC clients can subscribe to endpoints dynamically without restarting. That's the topic of episodes 10 and 18.

#Closing

Key takeaways:

• The standard grpc.health.v1 health service is understood by all tools without special configuration.
• grpc-health-probe bridges to Kubernetes liveness and readiness probes.
• Reflection lets grpcurl explore and call the API without a .proto file.
• DNS is the most basic discovery; Consul adds a registry and health filtering.
• Kubernetes uses readiness probes to select healthy pods.
• xDS lets gRPC clients discover endpoints dynamically, like Envoy.

In episode 10 next, we cover HTTP/2, load balancing, and connection management — the HTTP/2 networking characteristics gRPC uses, modern client-side load balancing with round robin, pick-first, and xDS, plus connection pooling, keepalive, and stream management. The discovery you built will be connected to the right traffic distribution strategy.