Hone logo
Hone
Problems

Implement a Simple Liveness Probe in Go

In microservices architecture, it's crucial to know if your application is healthy and responsive. A liveness probe is a mechanism that checks if a service instance is alive and functioning correctly. This challenge asks you to build a basic liveness probe for a Go application that exposes its health status via an HTTP endpoint.

Problem Description

Your task is to create a simple HTTP server in Go that exposes a /healthz endpoint. This endpoint should return a success status code (e.g., 200 OK) if the application is considered "healthy," and a failure status code (e.g., 503 Service Unavailable) otherwise. For this challenge, we'll define "healthy" as simply being able to start and run the server without critical errors. In a real-world scenario, this probe would check database connections, external service dependencies, or internal state.

Key Requirements:

  1. HTTP Server: The Go program must start an HTTP server.
  2. /healthz Endpoint: The server must expose an endpoint at the path /healthz.
  3. Healthy Response: When /healthz is accessed, if the application is running normally, it should respond with an HTTP status code of 200 OK.
  4. Unhealthy Response (Simulated): For this exercise, we won't implement complex checks that lead to an unhealthy state. However, the structure should allow for future expansion. If, hypothetically, the application were in an unhealthy state, it should respond with an HTTP status code of 503 Service Unavailable.
  5. Graceful Shutdown: The server should be able to shut down gracefully when a signal (like SIGINT) is received.

Expected Behavior:

When the Go program runs, it should:

  • Start an HTTP server listening on a specified port (e.g., 8080).
  • Allow external requests to hit the /healthz endpoint.
  • Respond with 200 OK to /healthz requests.
  • Exit cleanly when a termination signal is received.

Examples

Example 1:

Input: (No direct input, just run the Go program)

Program Execution: The Go program starts, listening on port 8080.

External Request (e.g., using curl):

curl -v http://localhost:8080/healthz

Output:

*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /healthz HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 0
< Date: Mon, 23 Oct 2023 10:30:00 GMT
<
* Connection #0 to host localhost left intact

Explanation: The client sent a GET request to /healthz. The server, being healthy, responded with 200 OK.

Example 2:

Input: (Simulating an unhealthy state, though not required to implement the transition to unhealthy for this challenge)

Program Execution: The Go program starts. For demonstration purposes, imagine a condition arises that marks the application as unhealthy.

External Request:

curl -v http://localhost:8080/healthz

Output (Hypothetical, demonstrating expected unhealthy response):

*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /healthz HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 503 Service Unavailable
< Content-Length: 0
< Date: Mon, 23 Oct 2023 10:31:00 GMT
<
* Connection #0 to host localhost left intact

Explanation: The client requested /healthz. The server, in this hypothetical scenario, is considered unhealthy and returns 503 Service Unavailable.

Constraints

  • The HTTP server must listen on port 8080.
  • The liveness probe endpoint must be at /healthz.
  • The solution must be written in Go.
  • The program should handle graceful shutdown when interrupted (e.g., via Ctrl+C).

Notes

  • You'll need to use Go's built-in net/http package.
  • Consider how to handle signals for graceful shutdown using the os/signal package.
  • For this challenge, the /healthz handler can be very simple; just returning http.StatusOK is sufficient to demonstrate the concept. The focus is on setting up the probe endpoint and server.
  • Think about how you might introduce a "check" into the /healthz handler in the future, which could return a different status code based on some internal application state.
Loading editor...
go