* 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
* Allow health checks to use any DI lifetime
This change allows registered IHealthCheck implementations to use any DI
lifetime. This is necessary for scenarios like using EF which requires a
scope.
The works by having the health check service create a scope for each
time it queries health checks. This scope does not overlap or share
state with other scopes (the request scope) so there is no crosstalk
between processing going on per-request in ASP.NET Core and the health
check operation.
* PR feedback and some logging cleanup
This adds UseHealthChecks overloads that configure the health checks
middleware to listen on a preconfigured port.
This is sugar for MapWhen, but it's important because a significant set
of users will want to use Health Checks in this way.
This adds UseHealthChecks overloads that configure the health checks
middleware to listen on a preconfigured port.
This is sugar for MapWhen, but it's important because a significant set
of users will want to use Health Checks in this way.
* 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.
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.
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.
Fixaspnet/Home#2820 - UseDatabaseErrorPage throws NullReferenceException when ef exception occur in background task
Fixaspnet/EntityFrameworkCore#9599 - Insert entity in non existing table throws NullException
Added null checks to async local access in event callback.
Related to aspnet/Home#2825
- Removed EF ApiCheck tests; not required for middleware.
- Removed JB annotations and Check usage; align with other Diagnostics Pages projects.
- Fixed code redundancies.
Ryan Nowak
Arthur Vickers
Ryan Nowak
Andrew J Said
Ryan Brandenburg
Ajay Bhargav Baaskaran
Nate McMaster
Henk Mollema
Andrew Peters
Jass Bagga
Andrew Stanton-Nurse
Pranav K
Pavel Krymets
John Luo
BrennanConroy
Smit Patel