👁 Image
NetEvolve.HealthChecks.Abstractions 4.20.61

HealthChecks

👁 GitHub
👁 GitHub top language
👁 GitHub repo size
👁 GitHub Pipeline CI

👁 CodeFactor
👁 codecov

What is this repository about?

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.

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.

NuGet packages

The following table lists all currently available NuGet packages. For more details about the packages, please visit the corresponding NuGet page.

Package naming explanation

The package names are based on the following naming schema - NetEvolve.HealthChecks.<ServiceGroup?>.<ServiceName>.<ServiceVersion?>

Explanation of the naming schema:

• NetEvolve is the name of the organization that maintains this repository.
• HealthChecks indicates 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.

ServiceGroup and ServiceName

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

ServiceVersion

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:

1. Multiple Client Libraries: When there are multiple client libraries available for the same service, each with different implementations or approaches.
2. Legacy vs Modern Implementations: To distinguish between older Legacy and 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.

Examples in the Repository:

1. SQL Server Client Libraries:

   • NetEvolve.HealthChecks.SqlServer - Uses the modern Microsoft.Data.SqlClient
   • NetEvolve.HealthChecks.SqlServer.Legacy - Uses the legacy System.Data.SqlClient

2. MySQL Client Libraries:

   • NetEvolve.HealthChecks.MySql - Uses the implementation of MySql.Data
   • NetEvolve.HealthChecks.MySql.Connector - Uses the alternative implementation of MySqlConnector

3. RabbitMQ Client Libraries:

   • NetEvolve.HealthChecks.RabbitMQ - Uses the latest version of RabbitMQ.Client
   • NetEvolve.HealthChecks.RabbitMQ.V6 - Uses the older version of RabbitMQ.Client (version 6.x)

Supported .NET version

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.

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.

Where can I find more information about the end-of-life (EOL) date for the relevant components?

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.

Why not .NET Standard?

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.