This is a mono repository for several NuGet packages based on the Microsoft.Extensions.Diagnostics.HealthChecks package. The main goal of this repository is to provide a set of health checks for different services and frameworks, which are fully configurable either via code or configuration.
What is the difference between this repository and the AspNetCore.Diagnostics.HealthChecks repository?
The main difference is that we try to focus on providing packages that are fully configurable via code or configuration. This means that you can configure the health checks in your Program.cs file, or in your appsettings.json file, or in any other configuration provider. While we continue to focus on configurability, we always consider the possibility of performance optimization. In some cases, we provide the same healthcheck for a service with an alternative implementation. For example, we provide a healthcheck for MySql that is based on MySql.Data and one that is based on MySqlConnector. This allows you to choose the implementation that best suits your needs or fits your existing dependencies.
While we continue to focus on configurability, we always consider the possibility of performance optimization.
| Method | Mean | Error | StdDev | Ratio | RatioSD | Allocated | Alloc Ratio |
|---|---|---|---|---|---|---|---|
| AspNetCore.HealthChecks.SqlServer | 651.3 μs | 31.19 μs | 87.45 μs | baseline | 10.42 KB | ||
| NetEvolve.HealthChecks.SqlServer | 596.6 μs | 23.81 μs | 70.22 μs | 1.11x faster | 0.20x | 5.25 KB | 1.98x less |
In addition, we try to support the latest LTS and STS versions of .NET (.NET Support Policy) as well as the latest preview version of .NET for at least 3 years, but we can't guarantee this. This depends on the support of related NuGet packages and the .NET platform itself. See the Supported .NET Version section for more details.
The following table lists all currently available NuGet packages. For more details about the packages, please visit the corresponding NuGet page.
| Package Name | NuGet Link |
|---|---|
| NetEvolve.HealthChecks Contains general application HealthChecks. |
 |
| NetEvolve.HealthChecks.Abstractions Contains abstract implementations for the NetEvolve.HealthChecks. |
 |
| NetEvolve.HealthChecks.Apache.ActiveMq Contains HealthChecks for Apache ActiveMq, based on the NuGet package Apache.NMS.ActiveMQ. |
 |
| NetEvolve.HealthChecks.Apache.Kafka Contains HealthChecks for Apache Kafka, based on the NuGet package Confluent.Kafka. |
 |
| NetEvolve.HealthChecks.ArangoDb Contains HealthChecks for ArangoDb, based on the nuget package ArangoDBNetStandard. |
 |
| NetEvolve.HealthChecks.AWS Contains HealthChecks for various AWS services. |
 |
| NetEvolve.HealthChecks.AWS.SNS Contains HealthChecks for AWS Simple Notification Service (SNS). |
 |
| NetEvolve.HealthChecks.Azure Contains HealthChecks for various Azure services. |
 |
| NetEvolve.HealthChecks.Azure.Blobs Contains HealthChecks for Azure Blob Storage. |
 |
| NetEvolve.HealthChecks.Azure.Queues Contains HealthChecks for Azure Queue Storage. |
 |
| NetEvolve.HealthChecks.Azure.ServiceBus Contains HealthChecks for Azure Service Bus. |
 |
| NetEvolve.HealthChecks.Azure.Tables Contains HealthChecks for Azure Table Storage. |
 |
| NetEvolve.HealthChecks.ClickHouse Contains HealthChecks for ClickHouse, based on the nuget package ClickHouse.Client. |
 |
| NetEvolve.HealthChecks.Dapr Contains HealthChecks for Dapr, based on the nuget package Dapr.Client. |
 |
| NetEvolve.HealthChecks.DB2 Contains HealthChecks for Db2, based on the nuget packages Net.IBM.Data.Db2 (Windows), Net.IBM.Data.Db2-lnx (Linux) and Net.IBM.Data.Db2-osx (OSX). |
 |
| NetEvolve.HealthChecks.DuckDB Contains HealthChecks for DuckDB, based on the nuget package DuckDB.NET.Data. |
 |
| NetEvolve.HealthChecks.Firebird Contains HealthChecks for Firebird, based on the nuget package FirebirdSql.Data.FirebirdClient. |
 |
| NetEvolve.HealthChecks.Keycloak Contains HealthChecks for the Keycloak service, based on the nuget package Keycloak.Net.Core. |
 |
| NetEvolve.HealthChecks.MongoDb Contains HealthChecks for MongoDb, based on the nuget package MongoDB.Driver. |
 |
| NetEvolve.HealthChecks.MySql Contains HealthChecks for MySql, based on the nuget package MySql.Data. |
 |
| NetEvolve.HealthChecks.MySql.Connector Contains HealthChecks for MySql, based on the nuget package MySqlConnector. |
 |
| NetEvolve.HealthChecks.Npgsql Contains HealthChecks for PostgreSQL, based on the nuget package Npgsql. |
 |
| NetEvolve.HealthChecks.Odbc Contains HealthChecks for ODBC data sources, based on the nuget package System.Data.Odbc. |
 |
| NetEvolve.HealthChecks.Oracle Contains HealthChecks for Oracle Databases, based on the nuget package Oracle.ManagedDataAccess.Core. |
 |
| NetEvolve.HealthChecks.Qdrant Contains HealthChecks for Qdrant Vector database, based on the nuget package Qdrant.Client. |
 |
| NetEvolve.HealthChecks.RabbitMQ Contains HealthChecks for RabbitMQ, based on the nuget package RabbitMQ.Client. |
 |
| NetEvolve.HealthChecks.RavenDb Contains HealthChecks for RavenDb, based on the nuget package RavenDB.Client. |
 |
| NetEvolve.HealthChecks.Redis Contains HealthChecks for Redis, based on the NuGet package StackExchange.Redis. |
 |
| NetEvolve.HealthChecks.Redpanda Contains HealthChecks for Redpanda, based on the NuGet package Confluent.Kafka. This is a temporary measure; if a dedicated Redpanda client is provided in the future, we will use it immediately. |
 |
| NetEvolve.HealthChecks.SqlEdge ❌ DEPRECATED Contains HealthChecks for SqlEdge, based on the nuget package Microsoft.Data.SqlClient. |
 |
| NetEvolve.HealthChecks.SQLite Contains HealthChecks for SQLite, based on the nuget package Microsoft.Data.Sqlite. |
 |
| NetEvolve.HealthChecks.SQLite.Legacy Contains HealthChecks for SQLite, based on the nuget package System.Data.Sqlite. |
 |
| NetEvolve.HealthChecks.SqlServer Contains HealthChecks for Microsoft SqlServer, based on the nuget package Microsoft.Data.SqlClient. |
 |
| NetEvolve.HealthChecks.SqlServer.Legacy Contains HealthChecks for Microsoft SqlServer, based on the nuget package System.Data.SqlClient. |
 |
The package names are based on the following naming schema - NetEvolve.HealthChecks.<ServiceGroup?>.<ServiceName>.<ServiceVersion?>
NetEvolveis the name of the organization that maintains this repository.HealthChecksindicates that this package contains health checks for various services.<ServiceGroup?>is an optional part that groups related services together. It helps to categorize the health checks based on the service provider or technology.<ServiceName>is the name of the service for which the health check is provided. It specifies the actual service that the health check is targeting.<ServiceVersion?>is an optional suffix that identifies a specific implementation or version of the client library used to connect to the service. This is useful when there are multiple client libraries available for the same service, each with different implementations or approaches.
The ServiceGroup is optional and is used to group related services. For example, all azure platform services are grouped under Azure. The ServiceName is the name of the service for which the health check is provided. For example, SqlServer or MySql.
The following table lists all planned and used groups. We will add more groups maybe in the future, if the demand is there.
- Apache
- AWS
- Azure
- GCP
The ServiceVersion in the package naming schema NetEvolve.HealthChecks.<ServiceGroup?>.<ServiceName>.<ServiceVersion?> refers to an optional suffix that identifies a specific implementation or version of the client library used to connect to the service.
This component is used when:
- Multiple Client Libraries: When there are multiple client libraries available for the same service, each with different implementations or approaches.
- Legacy vs Modern Implementations: To distinguish between older
Legacyand newer implementations of a client library for the same service.
This naming convention allows developers to choose the specific client implementation that best matches their existing dependencies without having to change their application architecture. For example, if your application already uses MySqlConnector, you would choose the corresponding health check package that uses the same client library.
The ServiceVersion is particularly valuable in scenarios where:
- Different client libraries have varying features, performance characteristics, or compatibility.
- You need to maintain compatibility with specific versions of a service.
-
SQL Server Client Libraries:
NetEvolve.HealthChecks.SqlServer- Uses the modernMicrosoft.Data.SqlClientNetEvolve.HealthChecks.SqlServer.Legacy- Uses the legacySystem.Data.SqlClient
-
MySQL Client Libraries:
NetEvolve.HealthChecks.MySql- Uses the implementation ofMySql.DataNetEvolve.HealthChecks.MySql.Connector- Uses the alternative implementation ofMySqlConnector
-
RabbitMQ Client Libraries:
NetEvolve.HealthChecks.RabbitMQ- Uses the latest version ofRabbitMQ.ClientNetEvolve.HealthChecks.RabbitMQ.V6- Uses the older version ofRabbitMQ.Client(version 6.x)
We try to support the LTS and STS versions of .NET (.NET Support Policy), as well as the latest preview version of .NET. We will try to support each framework version for at least 3 years, but we can't guarantee it. This depends on the support of related NuGet packages and the .NET platform itself.
| .NET Version | Supported |
|---|---|
| .NET Standard | ❌ No |
| .NET 7.0 or earlier versions | ❌ No |
| .NET 8.0 | ✅ Yes |
| .NET 9.0 | ✅ Yes |
| .NET 10.0 | 🔳 Early stage of planning, not yet supported |
Why did we choose this approach? Because we want to be able to take advantage of the latest language features of the .NET platform and the performance gains that come with them. We know that not all of our NuGet packages will gain performance from this, but this is our general strategy and nobody knows what the future will bring.
To get more information about the end-of-life (EOL) date for the relevant components, please visit the website of the creators of the components or try the website endoflife.date.
With the .NET Standard Microsoft created a specification for APIs that are intended to be available on all .NET implementations. This was a great idea, but it also has some drawbacks. The main drawback is that the .NET Standard is a specification and not an implementation. This means that the real work is done by .NET implementations, such as .NET 5.0 and later versions. Which is why we decided us against the .NET Standard and for the concrete .NET implementations.
See The future of .NET Standard for more details.