Merge HealthChecks API source code from aspnet/Diagnostics #548
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 65025d4.
- aspnet/Testing#248 - xUnit no longer supports .NET 4.5.1 - build tests for desktop .NET only on Windows Address existing issues - work around test failures, including #350 - skip tests mentioned in #350 - reorder xunit and xunit.runner.visualstudio; setup fails for .NET Core otherwise - skip all tests using LocalDB on Linux and OSX - `[FrameworkSkipCondition(RuntimeFrameworks.Mono)]` now redundant - correct AppVeyor image nits: - let VS add the test `<Service>` - use `[ConditionalFact]` when there's no test data
[auto-updated: dependencies]
[auto-updated: dependencies]
[auto-updated: dependencies]
* 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
[auto-updated: dependencies]
- Add logging of description/data - Add logging for aggregate begin/end
* Added execution time duration into HealthReportEntry and TotalDuration on HealthReport * review PR feedback from @rynowak. * added the same duration into HealthReportEntry and log when the health check throw
…nd remove unnecessary signing properties
[auto-updated: dependencies]
IHealthCheckPublisher allows you to configure and run health checks regularly inside an application, and push the notifications elsewhere. All publishers are part of a single queue with a configurable period and timeout.
The link (https://github.com/aspnet/Home/blob/dev/CONTRIBUTING.md) was broken due to merging of repo's.
Fixes aspnet/Diagnostics#511 and aspnet/Diagnostics#514 It's really confusing to people that we use Map. Users expect that the URL they provide for the health check middleware will only process exact matches. The way it behaves when using map is not optimal for some of the common patterns.
- Renamed the property for configuration response caching headers - Renamed the options class to avoid conflicts with other type names Fixes aspnet/Diagnostics#509
* 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`.
Prior to reorganization, this source code was found in https://github.com/aspnet/Diagnostics/tree/c802d5ef5fba1ba8dfbcb8c3741af2ba15e9d1aa
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As a part of dotnet/aspnetcore#3598, this merges the source code and history for two HealthChecks projects into this repo.