You can use Helidon-provided health checks to report various common health check statuses:

† Helidon cannot support the indicated health checks in the GraalVM native image environment, so with native image those health checks do not appear in the health output.

The following code adds the default built-in health checks to your application:

HealthSupport health = HealthSupport.builder()
    .add(HealthChecks.healthChecks())   
    .build();

Routing.builder()
       .register(health)   
       .build();

• Add built-in health checks using defaults (requires the helidon-health-checks dependency).
• Register the created HealthSupport with web server routing (adds the /health endpoint).

You can control the thresholds for built-in health checks in either of two ways:

• Create the health checks individually using their builders instead of using the HealthChecks convenience class. Follow the JavaDoc links in the table above.

• Using configuration as explained in .

• Liveness Probe

• Readiness Probe

• Startup Probe

Probes is the term used by Kubernetes to describe health checks for containers (Kubernetes documentation).

There are three types of probes:

• liveness: Indicates whether the container is running

• readiness: Indicates whether the container is ready to service requests

• startup: Indicates whether the application in the container has started

You can implement probes using the following mechanisms:

1. Running a command inside a container
2. Sending an HTTP request to a container
3. Opening a TCP socket to a container

A microservice exposed to HTTP traffic will typically implement both the liveness probe and the readiness probe using HTTP requests. If the microservice takes a significant time to initialize itself, you can also define a startup probe, in which case Kubernetes does not check liveness or readiness probes until the startup probe returns success.

You can configure several parameters for probes. The following are the most relevant parameters:

Liveness Probe

Readiness Probe

Startup Probe

Failed probes are recorded as events associated with their corresponding pods. The event message contains only the status code.

POD_NAME=$(kubectl get pod -l app=acme -o jsonpath='{.items[0].metadata.name}') 
kubectl get event --field-selector involvedObject.name=${POD_NAME} 

• Get the effective pod name by filtering pods with the label app=acme.
• Filter the events for the pod.

Accessing the Helidon-provided /health endpoint reports the health of your application as shown below:

{
    "status": "UP",
    "checks": [
        {
            "name": "deadlock",
            "status": "UP"
        },
        {
            "name": "diskSpace",
            "status": "UP",
            "data": {
                "free": "211.00 GB",
                "freeBytes": 226563444736,
                "percentFree": "45.31%",
                "total": "465.72 GB",
                "totalBytes": 500068036608
            }
        },
        {
            "name": "heapMemory",
            "status": "UP",
            "data": {
                "free": "215.15 MB",
                "freeBytes": 225600496,
                "max": "3.56 GB",
                "maxBytes": 3817865216,
                "percentFree": "99.17%",
                "total": "245.50 MB",
                "totalBytes": 257425408
            }
        }
    ]
}

This example shows the usage of the Helidon health API in an application that implements health endpoints for the liveness and readiness probes. Note that the application code dissociates the health endpoints from the default routes, so that the health endpoints are not exposed by the service. An example YAML specification is also provided for the Kubernetes service and deployment.

Routing healthRouting = Routing.builder()
        .register(JsonSupport.create())
        .register(HealthSupport.builder()
                .webContext("/live") 
                .add(HealthChecks.healthChecks()) 
                .build())
        .register(HealthSupport.builder()
                .webContext("/ready") 
                .addReadiness(() -> HealthCheckResponse.named("database").up().build()) 
                .build())
        .build();

Routing defaultRouting = Routing.builder()
        .any((req, res) -> res.send("It works!")) 
        .build();

WebServer server = WebServer.builder(defaultRouting)
        .config(ServerConfiguration.builder()
                .port(8080) 
                .addSocket("health", SocketConfiguration.builder() 
                        .port(8081)
                        .build())
                .build())
        .addNamedRouting("health", healthRouting) 
        .build();

server.start();

• The health service for the liveness probe is exposed at /live.
• Using the built-in health checks for the liveness probe.
• The health service for the readiness probe is exposed at /ready.
• Using a custom health check for a pseudo database that is always UP.
• The default route: returns It works! for any request.
• The server uses port 8080 for the default routes.
• A socket configuration named health using port 8081.
• Route the health services exclusively on the health socket.

kind: Service
apiVersion: v1
metadata:
  name: acme 
  labels:
    app: acme
spec:
  type: NodePort
  selector:
    app: acme
  ports:
  - port: 8080
    targetPort: 8080
    name: http
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: acme 
spec:
  replicas: 1
  selector:
    matchLabels:
      app: acme
  template:
    metadata:
      name: acme
      labels:
        name: acme
    spec:
      containers:
      - name: acme
        image: acme
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /live 
            port: 8081
          initialDelaySeconds: 3 
          periodSeconds: 10
          timeoutSeconds: 3
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /ready 
            port: 8081
          initialDelaySeconds: 10 
          periodSeconds: 30
          timeoutSeconds: 10
---

• A service of type NodePort that serves the default routes on port 8080.
• A deployment with one replica of a pod.
• The HTTP endpoint for the liveness probe.
• The liveness probe configuration.
• The HTTP endpoint for the readiness probe.
• The readiness probe configuration.