Health

Health Endpoint

Overview

This tool exposes two types of health endpoints that you can control from within the application:

1. Service Health Endpoints: These are the standard health endpoints (/health and /healthz) that monitor the overall health of the service and can be used by external monitoring services like Azure App Services or Container Instances to check the application's health.

2. Custom Health Endpoint: This is a custom endpoint (/Health/CustomEndpoint) that simulates various health states (such as delayed responses or errors) and can be useful for testing and debugging how your system handles different health scenarios.

In some Azure services, the /health and /healthz endpoints can be monitored by the application host service (like App Services, Container Instances...).

Note: Depending on how you are hosting this application, additional health configuration might be required to ensure the health checks integrate properly with your environment's monitoring tools.

What is the difference between /health and /healthz?

• /healthz: The /healthz endpoint originated from Google's internal practices and was adopted by Kubernetes. The "z" at the end differentiated internal health checks from those intended for external use. This convention helps avoid conflicts with any user-defined /health endpoints that applications may expose.
• /health: This is a more general and commonly used endpoint for health checks in web applications and services. It follows standard RESTful practices and is intuitive for both developers and system administrators.

Purpose

The Health Endpoint Tool allows you to simulate and control your application's health status. This is particularly useful when testing your system's behavior in different health states and when implementing health checks for monitoring in cloud environments such as Azure.

Health Statuses

There are two main health status types controlled by this tool:

1. Service Health: This controls the overall health status of the application, which is exposed by the /health and /healthz endpoints. You can manually set the health status to one of the following:

   • Healthy: The service is fully operational and returns a status code 200.
   • Degraded: The service is operational but may have limited performance or issues. It still returns a status code 200.
   • Unhealthy: The service is not functioning correctly and returns a status code 503.

2. Custom Health: This controls the health of a custom endpoint /Health/CustomEndpoint, where the health status can be altered to simulate specific scenarios:

   • Healthy: The custom endpoint returns 200 OK with a message indicating health.
   • Delayed 10s: The custom endpoint simulates a delay of 10 seconds before returning a 200 OK status.
   • Delayed 60s: The custom endpoint simulates a delay of 60 seconds before returning a 200 OK status.
   • Error: The custom endpoint simulates a failure by returning a 500 Internal Server Error.

Resources

• Health checks in ASP.NET Core
• AspNetCore.Diagnostics.HealthChecks This repository offers a wide collection of ASP.NET Core Health Check packages for widely used services and platforms.