search

aspnet / Diagnostics

[Archived] Diagnostics middleware for reporting info and handling exceptions and errors in ASP.NET Core, and diagnosing Entity Framework Core migrations errors. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
213 stars 111 forks source link

Use options for registering health checks #479

Closed rynowak closed 6 years ago

rynowak commented 6 years ago

This change pivots to use options for registering health checks. We get a few pretty nice things out of this, and it unblocks some of our requirements.

Now all registration methods support the application developer configuring the name, failure-status, and tags for each health check. This is a requirment, that we weren't really satisfying - which is what led to this redesign. In support of this health checks now return pass/fail, and the service is responsible for assigning the status.

Health check authors that need configuration data (connection string as an example) now have three ways to do this depending on their requirements.

  1. Create an instance and register that (easiest)
  2. Use Type Activation and pass parameters (middle)
  3. Use named options (richest)

We expect most health checks to need/want some kind of configuration - which 1) works pretty well to solve. However many other health checks will need DI + configuration. It was also a gap that we didn't have a good way to use named options, when it's such a good fit for our scenarios.

Added new registration methods for type activation that allow you to pass parameters for 2).

Added a context type that allows the running health check access to its registration for 3).

Redesigned and renamed how status gets reported. Health checks return pass/fail result, but the overall HealthReport includes entries of a different type. This seems fine because there isn't really a way to consume a HealthCheckResult directly - the service is the only consumer.

Added support for tags. This was easy to add now that we have a separate registration type, and it's quite handy for building filters (see sample).

rynowak commented 6 years ago

@davidfowl updates

steveoh commented 5 years ago

Are health checks all pass/fail in reality?

I think there is an in-between place since we can use healthy, degraded, and unhealthy. If you limit the check to pass/fail and then use the failStatus to mark the check as degraded or unhealthy, it seems that you lose the ability to choose degraded or unhealthy. Am I missing something?

rynowak commented 5 years ago

Am I missing something?

My thinking about this is that more often health check code is coming from a library - but it's the application developer's concern to decide how a failure should be interpreted. We wanted to provide a consistent experience for this works.

steveoh commented 5 years ago

here is the example i have that will give me issues in preview 3.

https://github.com/agrc/api.mapserv.utah.gov/blob/development/src/api/Features/Health/LocatorHealthCheck.cs

rynowak commented 5 years ago

Thanks for this feedback, I'm opening an issue to track this so we can take a look into changing it.