* 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
* Remove JSON output and convert to sample
GlennC and I made the decisison to turn the JSON output into a sample
rather than something we support out of the box. We wouldn't tell
customers to definitely use it and we don't want to introduce more
coupling to JSON.NET.
A bunch of small changes and updates for 2.2 focused at making our main
scenarios more streamlined and focused. Also adds samples for
extensibility we support so far.
A list of changes:
Clearing baselines for these projects. We didn't ship anything in 2.1 so
there should be nothing in the baselines.
--
The middleware now uses Map for path matching. This makes the actual
`HealthCheckMiddleware` more standalone. This will make it easy to use
with Dispatcher/Endpoint Routing in the future.
This also manifests by removing Path from HealthCheckOptions - the path
is an explicit argument to the UseHealthChecks middelware - this
streamlines the design for 3.0.
--
Added extensibility for customizing the status codes (aspnet/Home#2584)
--
Added extensibility for writing the textual output (aspnet/Home#2583)
--
Changed the default output to be `text/plain`. The most common use cases
for health checks don't include a detailed status.
The existing output format is still available as an option.
Ryan Nowak
Ryan Nowak