如何判断当前请求的是健康检查API

前言

为了性能监控的目的，我们使用了Middleware记录所有请求的Log。实现代码如下：

public class RequestLoggingMiddleware
{
    ...
    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        finally
        {
            //Log
        }
    }
}

同时，我们在服务中加入了健康检查API，用于定时访问检查服务状态。

这就导致Log中记录了大量健康检查API的日志，需要有方法判断出这类请求，并忽略日志写入。

判断路由地址

健康检查API的实现代码如下：

public void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddHealthChecks();
}


public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{       
    ...
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/health");
        endpoints.MapControllers();
    });
}

因此，可以根据路由地址是否以/health开头来判断。

判断DisplayName

上面的方法虽然可以实现要求，但是感觉太low了！

而且，如果把Middleware做成公共组件，那就不能限制健康检查API的路由地址的格式。

需要重新找到一个不变的数据值用于判断。

查看Maphealthchecks的实现代码，发现这样一句代码：

private static IEndpointConventionBuilder MapHealthChecksCore(IEndpointRouteBuilder endpoints, string pattern, HealthCheckOptions? options) 
{ 
    ...
   return endpoints.Map(pattern, pipeline).WithDisplayName(DefaultDisplayName); 
}

而DisplayName是个常量：

private const string DefaultDisplayName = "Health checks";

因此，我们只需判断Endpoint的DisplayName即可：

public class RequestLoggingMiddleware
{
    ...
    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        finally
        {
            if (context.GetEndpoint()?.DisplayName == "Health checks")
            { 
            }
            else
            {
                //Log
            }
        }
    }
}

结论

现在，我们已经可以轻松识别出健康检查API请求。

推荐使用DisplayName方式，容错性更高。