Healthchecks in ASP NET Core

Healthchecks in ASP NET Core

Healthchecks are used to assess the health of an application. There are multiple level of checks which can be implemented, the first level being whether the application is itself running. The second level being whether the application dependencies, services, databases, files, are accessible by the application. Last level being whether the process itself is healthy, consume a reasonable amount of CPU/RAM.
Today we will see how we can implement a simple healthcheck middleware for ASP NET Core in three parts:

  1. Define the usage
  2. Build the framework
  3. Sqlite Healthcheck extension

1. Define the usage

ASP NET Core is cooking a healthcheck framework but the nuget package hasn’t been created yet therefore only the codebase is available. The framework in this post is a simpler version inspired by the official healthcheck framework.

We will be creating a framework allowing us to register comprehensive healthchecks.

public void ConfigureServices(IServiceCollection services)
{
    // ... rest of function

    services.AddHealthChecks(c =>
    {
        c.AddSelfCheck("Web is running.");
        c.AddSqliteCheck(
            Configuration["connectionStrings:database"],
            "TableA",
            "TableB");
    });
}


public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ... rest of function

    app.UseHealthChecks();

    // ... rest of function
}

Here we register a self healthcheck and a Sqlite healthcheck verifying the existence of tables.

When we hit the /health endpoint we will get the following message:

{
  "results": [
    {
      "name": "SelfCheck",
      "status": "Healthy",
      "message": "Web is running."
    },
    {
      "name": "SqliteCheck",
      "status": "Healthy",
      "message": "Successfully found all table(s) on Sqlite database '..\\Data\\database.db'. Tables: TableA, TableB"
    }
  ],
  "compositeStatus": "Healthy"
}

In order to do this, we will start by implementing the framework.

2. Build the framework

2.1 Abstractions

To achieve the usage describe in 1) we will be implementing three interfaces.

IHealthCheck, this is the main healthcheck interface for the implementation of each concrete healthcheck.

public interface IHealthCheck
{
    Task<HealthCheckResult> Check();
}

IHealthCheckService, this is the main entrypoint to trigger all healthchecks and return a composite result.

public interface IHealthCheckService
{
    Task<CompositeHealthCheckResult> CheckAll();
}

Next we create an abstraction of a builder which is used to register all healthchecks via a simple API.

public interface IHealthCheckBuilder
{
    IHealthCheckBuilder Add(Func<IServiceProvider, IHealthCheck> factory);

    IEnumerable<Func<IServiceProvider, IHealthCheck>> GetAll();
}

The Add takes a factory allowing to build the healthcheck as we want to be able to healthcheck the injection of the healthcheck dependencies so instantiating the healthcheck object can be part of the check.

2.2 Implementations

Now we can implement the interfaces starting from the healthcheck.

public enum CheckStatus
{
    Healthy,
    Unhealthy
}

public class HealthCheckResult
{
    public string Name { get; set; }

    public CheckStatus Status { get; set; }

    public string Message { get; set; }
}

public class SelfCheck : IHealthCheck
{
    private string _name;
    private string _message;

    public SelfCheck(string message)
    {
        _name = typeof(SelfCheck).Name;
        _message = message;
    }

    public Task<HealthCheckResult> Check()
    {
        return Task.FromResult(new HealthCheckResult
        {
            Name = _name,
            Message = _message,
            Status = CheckStatus.Healthy
        });
    }
}

Next we implement the service which runs all healthchecks and construct the composite result.

public class CompositeHealthCheckResult
{
    public IEnumerable<HealthCheckResult> Results { get; set; }

    public CheckStatus CompositeStatus => Results.Any(r => r.Status == CheckStatus.Unhealthy) ? CheckStatus.Unhealthy : CheckStatus.Healthy;
}

public class HealthCheckService : IHealthCheckService
{
    private IEnumerable<IHealthCheck> _checks;

    public HealthCheckService(IEnumerable<IHealthCheck> checks)
    {
        _checks = checks;
    }

    public async Task<CompositeHealthCheckResult> CheckAll()
    {
        return new CompositeHealthCheckResult
        {
            Results = await Task.WhenAll(_checks.Select(async c => await c.Check()))
        };
    }
}

As we can see, the service expects the healthchecks to be registered in the DI. To configure that we provide the Healthcheck builder.

public class HealthCheckBuilder : IHealthCheckBuilder
{
    private List<Func<IServiceProvider, IHealthCheck>> _factories = new List<Func<IServiceProvider, IHealthCheck>>();

    public IHealthCheckBuilder Add(Func<IServiceProvider, IHealthCheck> factory)
    {
        _factories.Add(factory);
        return this;
    }

    public IEnumerable<Func<IServiceProvider, IHealthCheck>> GetAll()
    {
        return _factories;
    }
}

The builder allows us to register the healthchecks with a simple API .AddHealthcheck.
To make things even more explicit, we can create an extension on the IHealthcheckBuilder.

public static class HealthCheckBuilderExtensions
{
    public static IHealthCheckBuilder AddSelfCheck(this IHealthCheckBuilder builder, string message) =>
        builder.Add(sp => new SelfCheck(message));
}

We also define an extension on the service collection:

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddHealthChecks(this IServiceCollection services, Action<IHealthCheckBuilder> configureHealthCheckBuilder)
    {
        if (configureHealthCheckBuilder == null)
        {
            throw new ArgumentNullException(nameof(configureHealthCheckBuilder));
        }

        services.AddTransient<IHealthCheckService, HealthCheckService>();

        var builder = new HealthCheckBuilder();
        configureHealthCheckBuilder(builder);

        foreach (var factory in builder.GetAll())
        {
            services.AddTransient(sp => factory(sp));
        }

        return services;
    }
}

It becomes now more explicit at registration.

services.AddHealthChecks(c =>
{
    c.AddSelfCheck("Web is running.");
});

2.3 Middleware

We could use the service as it is and inject it in a MVC controller but since it isn’t really part of the business logic, it is good to provide it as a Middleware.

To do that we create a Middleware which handle /health.

public class HealthCheckMiddleware
{
    private RequestDelegate _next;

    public HealthCheckMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context, IHealthCheckService healthCheckService)
    {
        if (context.Request.Path.Equals("/health") && context.Request.Method == HttpMethods.Get)
        {
            var result = await healthCheckService.CheckAll();

            if (result.CompositeStatus != CheckStatus.Healthy)
                context.Response.StatusCode = 503;

            context.Response.Headers.Add("content-type", "application/json");
            await context.Response.WriteAsync(
                JsonConvert.SerializeObject(
                    result,
                    new JsonSerializerSettings {
                        Converters = { new StringEnumConverter() },
                        ContractResolver = new CamelCasePropertyNamesContractResolver()
                    }
                )
            );
            return;
        }

        await _next(context);
    }
}

We then create an extension on the application builder to handle the healthcheck endpoint at the beginning of the pipeline.

public static class ApplicationBuilderExtensions
{
    public static IApplicationBuilder UseHealthChecks(this IApplicationBuilder app) =>
        app.UseMiddleware<HealthCheckMiddleware>();
}

And we can then use it in Startup.cs.

app.UseHealthChecks();

We now have a fully functional healthcheck library.

3. Sqlite Healthcheck extension

We saw how we could extend the healthcheck library by adding an extension method on the healthcheck builder.
This should be the default way of extending the framework.

If we were to add a Sqlite healthcheck, we would start by defining the healthcheck:

public class SqliteCheck : IHealthCheck
{
    private string _name;
    private string _connectionString;
    private string[] _tables;

    public SqliteCheck(string connectionString, string[] tables)
    {
        _name = typeof(SqliteCheck).Name;
        _connectionString = connectionString;
        _tables = tables;
    }

    public Task<HealthCheckResult> Check()
    {
        try
        {
            var path = _connectionString.Remove(0, "Date Source=".Length);

            if (File.Exists(path))
            {
                using (var conn = new SQLiteConnection(path))
                {
                    var count = _tables.Aggregate(0, (res, t) => res + conn.CreateCommand($"SELECT COUNT(name) FROM sqlite_master WHERE type='table' AND name='{t}'").ExecuteScalar<int>());
                    if (count == _tables.Length)
                    {
                        return Task.FromResult(new HealthCheckResult
                        {
                            Name = _name,
                            Status = CheckStatus.Healthy,
                            Message = $"Successfully found all table(s) on Sqlite database '{path}'. Tables: {string.Join(", ", _tables)}"
                        });
                    }
                    else
                    {
                        return Task.FromResult(new HealthCheckResult
                        {
                            Name = _name,
                            Status = CheckStatus.Unhealthy,
                            Message = $"Failed to find all tables on Sqlite database '{path}'. Tables: {string.Join(", ", _tables)}"
                        });
                    }
                }
            }
            else
            {
                return Task.FromResult(new HealthCheckResult
                {
                    Name = _name,
                    Status = CheckStatus.Unhealthy,
                    Message = $"Failed to find Sqlite database at '{path}'."
                });
            }

        }
        catch (Exception ex)
        {
            return Task.FromResult(new HealthCheckResult
            {
                Name = _name,
                Status = CheckStatus.Unhealthy,
                Message = "Failed to execute command 'PRAGMA table_info(tabe-name)' on database. Message: " + ex.Message
            });
        }
    }
}

And create an extension registering the healthcheck:

public static IHealthCheckBuilder AddSqliteCheck(this IHealthCheckBuilder builder, string connectionString, params string[] tables) =>
    builder.Add(sp => new SqliteCheck(connectionString, tables));

We can then add it in our DI:

services.AddHealthChecks(c =>
{
    c.AddSelfCheck("Web is running.");
    c.AddSqliteCheck(
        Configuration["connectionStrings:database"],
        "TableA",
        "TableB");
});

And that concludes our healthcheck library.

Conclusion

Today we saw how to implement a healthcheck framework which can be used in any ASP NET Core application. We started from deciding how we want to have our healthcheck configured then moved to the implementation and ended by creating an extension for Sqlite. This methodology can be used to create any framework starting from deciding how we wish to use the framework and moving backward to the implementation. Hope you liked this post, see you next time!

Comments

  1. Vlad ' ' / /6 December 2018 at 13:20

    Where do you implement the service
    services.AddHealthChecks(c =>....)

    It gives the error that is not defined in .net core 2

    Also, why did you deleted a comment?

    ReplyDelete
    Replies
    1. Kimserey6 December 2018 at 15:44

      Hey Vlad, thanks for the interested.

      > "Also, why did you deleted a comment?"
      I deleted the comment above because it was an advert spam.

      > "Where do you implement the service"
      Indeed I didn't mentioned how .AddHealthCheck was implemented. It is an extensions on service collection.
      You can find the whole implementation discussed on this blog on my github.

      I will update this blog post but meanwhile here is the link to the extension:
      https://github.com/Kimserey/Groomgy.HealthChecks.AspNetCore/blob/master/Groomgy.HealthChecks.AspNetCore/Extensions/ServiceCollectionExtensions.cs#L11

      Delete

Post a Comment

Popular posts from this blog

A complete SignalR with ASP Net Core example with WSS, Authentication, Nginx

SignalR with ASP Net Core SignalR is a framework from ASP NET Core allowing us to establish a two way communication between client and server. This two way communication allows the client to send messages to the server but more importantly allows the server to push messages to the client. SignalR makes use of Websocket when available else it falls back to SSE or pulling. Today we will focus on how to setup SignalR to work with WSS, Websocket secure and how we can authenticate the user requesting to connect to our SignalR hub via Webscoket. Getting started with SignalR SSL encryption for Websocket Secure WSS Websocket Authentication with Identity Server 4 SignalR behind Nginx 1. Getting started with SignalR The Hubs are the main components of SignalR. It is an abstraction of a two way communication available for both client and server. Public functions from the hub can be called from the server code and can be called from the client. The frontend NPM package @aspnet/signalr
Keep reading

Microsoft Orleans logs warnings and errors

Microsoft Orleans logs warnings and errors Microsoft Orleans is a framework which helps building distributed system by implementing the actor model together with the concept of virtual actors, taking care of availability and concurrency. If you are unfamiliar with Microsoft Orleans, you can look at my previous blog post explaining the benefits of Microsoft Orleans . Even though Orleans promises to abstract the distributed system problems, there are instances where errors arise without us being able to understand what is going on. Lucky us, the logs are well documented… but only for those who can decrypt them. Today I will go through some of the errors and warnings which can be seen from silo and client so that you too can undestand what is going on. Enjoy! The code used to produce those errors can be found on my GitHub https://github.com/Kimserey/orleans-cluster-consul . 1. Client logs Logs on client appears with address {ip}:0 . 1.1. Can’t find implementation of interface An un
Keep reading

One way to structure Web App built in F# and WebSharper

Image
Architecture for Web App built in F# and WebSharper F# + WebSharper is an awesome combination to build web application . The only problem is that if you want to build a web app larger than a to-do list, it’s hard to find examples to use as references. It is even harder to find tutorials that touches on overall design and answer questions like: How should I start? Where should I put the code? How should I separate the code, put it in different files, with different namespaces or modules? How many layers? Asking these questions at the beginning of the development is important. All these questions if answered correctly will lead to a good structure for the application. Answered incorrectly, or not even asked, will most likely lead to unmaintainable/fragile/rigid (or whatever bad adjectives for coding) code. Over the last few months, I have been working on a web app built in F# with WebSharper and came out with an architecture that caters to extensions and decoupling. Today, I wil
Keep reading