* Redesign HealthStatus (again)
This change brings back the ability to return Healthy/Degraded/Unhealthy
in a HealthCheckResult. We tried making this pass/fail in 2.2.0-preview3
and folks writing health checks for their own use pointed out (rightly
so) that it was too limited.
It's still possible for the app developer to configure the failure
status of a health check, but it requires the health check author to
cooperate.
I also got rid of HealthStatus.Failed since it raises more questions
than it answers. It's really not clear that it's valuable for a health
check for behave different when throwing an unhandled exception.
We would still recommend that a health check library handle exceptions
that they know about and return `context.Registration.FailureStatus`.
* Use options for registering health checks
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).
* HARDER BETTER STRONGER FASTER
This allows each middleware to be configured with a specific set of
checks (by name). See the comments in the sample for how this is
frequently used.
This is also addresses aspnet/Home#2575 - or at least the part that we
plan to do. We think that any sort of built-in system of metadata or
tags is vast overkill, and doesn't really align with the primary usage
of health checks.
We're providing building blocks, and these can be put together to
build more complicated things like what's described in aspnet/Home#2575.
Ryan Nowak
Zhiliang
Ryan Nowak