Health check aggregator UI in microservice architecture

Microservice architectures consist of many services. Generally, special services manage access to these services at a single point, like API gateways. These services are used for external accesses instead of accessing all microservices. Similarly, we can create a single point for health check services. A health check service can be defined as a specialized REST endpoint that allows a service to check its health and publishes its current status. It could be for any access that a service requires, such as a database connection, system resources, or network availability. This article demonstrates how a single service or user interface can show the health check result of multiple services.

Health Checks in ASP.NET Core

A health check service reports the app’s availability to process requests. In .NET Core, health check services can be registered simply as a middleware. This middleware handles requests that come to a particular endpoint. A health check service can be written by merely implementing the IHealthCheck interface and registered in the startup. The outputs of these services can be not only plaintext but also custom JSON outputs with the response writers. Please check the Microsoft document to get details:

Health checks in ASP.NET Core

AspNetCore.Diagnostics.HealthChecks Library

It would be much more practical to see the output of the health check service via a UI instead of JSON. AspNetCore.HealthChecks.UI library allows us to see the health check output as a web interface, as shown below.

The AspNetCore.Diagnostics.HealthChecks project provides many features. This repository includes a lot of ASP.NET Core Health Check packages for standard services and platforms such as SQL Server, RabbitMQ, Redis, and so on. In addition, it can save the outputs on storage by periodically calling the health check services with many storage options, including PostgreSQL, MySql, InMemory, and so on.

Health Check Aggregator UI Project

Two simple microservices and one health check UI service have been developed to explain the approach.

Downstream Microservices

Basket and Product services represent microservices.

A simple health check service has been added to both services for proof of concept. ProcessAllocatedMemoryHealthCheck checks the process memory exceeds the threshold or not using AspNetCore.HealthChecks.System library. In this example, 100 MB has been set as a limit. If this limit is exceeded, the service will respond as unhealthy.

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks()
            .AddProcessAllocatedMemoryHealthCheck(100, "Memory");
}

Let’s configure the /health endpoint to return health check results as JSON.

public void Configure(IApplicationBuilder app)
{
       app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/health", new HealthCheckOptions()
        {
            ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
        });
    });
}

Sample JSON output:

{
  "status": "Healthy",
  "totalDuration": "00:00:00.0312045",
  "entries": {
    "AllocatedMemory": {
      "data": {},
      "description": "Allocated megabytes in memory: 4 mb",
      "duration": "00:00:00.0048113",
      "status": "Healthy",
      "tags": []
    }
  }
}

Aggregator UI

All possible parameters in the aggregator UI application are placed in the appsettings.json file. Thus, multiple deploys can be made with a single code base by creating a configurable application. You can read the details in the article: Multiple deployments using a single code base. Two sections are written for configuration parameters: HealthCheck and Services. In the HealthCheck section, there are parameters for the UI.

"HealthCheck": {
  "HeaderText": "HealthCheck Aggregator UI",
  "PollingInterval": 60,
  "UIPath": "/health-ui",
  "ApiPath": "/health-api"
}

• Header Text — header in the page
• PollingInterval — polling interval in seconds
• UIPath — relative path for UI
• ApiPath — relative path for JSON response

The second section is Services that contains the information of the services to be aggregated.

"Services": [
  {
    "Name": "Basket Service",
    "Url": "http://basketservice/health"
  },
  {
    "Name": "Product Service",
    "Url": "http://productservice/health"
  }
]

To register health check UI services in Startup.cs.

To map health check UI and API as an endpoint:

Demo

A docker-compose file can be used to run demo with docker-compose upcommand.

The health check UI will be accessible at http://localhost:5001/health-ui

Source code is available at:

GitHub - bordatech/healthcheck-aggregator-ui

Thanks for reading.