Проверки работоспособности в ASP.NET Core

Гленн Кондрон и Джуерген Гутш

ASP.NET Core предоставляет ПО промежуточного слоя и библиотеки для создания отчетов о работоспособности компонентов инфраструктуры приложения.

Проверки работоспособности предоставляются приложением как конечные точки HTTP. Конечные точки проверки работоспособности можно настроить для различных сценариев мониторинга в реальном времени:

• Проверки работоспособности можно использовать с оркестраторами контейнеров и подсистемами балансировки нагрузки, чтобы проверять состояние приложения. Например, оркестратор контейнеров может реагировать на неуспешную проверку работоспособности, остановив последовательное развертывание или перезапустив контейнер. Балансировщик нагрузки может реагировать на неработоспособное приложение путем перенаправления трафика от неисправного экземпляра к работающему экземпляру.
• Использование памяти, диска и других ресурсов физического сервера можно отслеживать с точки зрения работоспособности.
• Проверки работоспособности позволяют проверять зависимости приложения, такие как базы данных и конечные точки внешних служб, чтобы убедиться в доступности и нормальной работе.

Проверки работоспособности обычно используются в оркестраторе контейнеров или внешней службе мониторинга для проверки состояния приложения. Перед добавлением проверки работоспособности приложения выберите используемую систему мониторинга. Система мониторинга определяет, какие виды проверки работоспособности создавать и как настроить их конечные точки.

Базовая проверка работоспособности

Для многих приложений достаточно конфигурации базовой проверки работоспособности, которая сообщает о доступности приложения для обработки запросов (жизнеспособности).

Базовая конфигурация регистрирует службы проверки работоспособности и вызывает ПО промежуточного слоя для получения ответа о работоспособности в конечной точке по URL-адресу. По умолчанию отдельные проверки работоспособности не регистрируются для тестирования какой-либо конкретной зависимости или подсистемы. Приложение считается работоспособным, если оно способно отвечать на запросы по URL-адресу конечной точки работоспособности. Модуль записи ответа по умолчанию записывает HealthStatus в качестве ответа клиенту в виде простого текста. Значение HealthStatus равно HealthStatus.Healthy, HealthStatus.Degraded или HealthStatus.Unhealthy.

Зарегистрируйте службы проверки работоспособности при помощи AddHealthChecks в Program.cs. Создайте конечную точку проверки работоспособности, вызвав MapHealthChecks.

В примере ниже создается конечная точка проверки работоспособности в /healthz:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

var app = builder.Build();

app.MapHealthChecks("/healthz");

app.Run();

Docker HEALTHCHECK

Docker предлагает встроенную директиву HEALTHCHECK, которую можно вызвать для проверки состояния приложения, использующего базовую конфигурацию проверки работоспособности:

HEALTHCHECK CMD curl --fail http://localhost:5000/healthz || exit

В предыдущем примере используется curl, чтобы выполнить HTTP-запрос к конечной точке проверки работоспособности по адресу /healthz. curl не входит в образы контейнеров .NET Linux, но его можно добавить, установив необходимый пакет в Dockerfile. Контейнеры, использующие образы на основе Alpine Linux, могут использовать включенный wget вместо curl.

Создание проверки работоспособности

Проверки работоспособности создаются путем реализации интерфейса IHealthCheck. Метод CheckHealthAsync возвращает HealthCheckResult, что означает состояние работоспособности Healthy, Degraded или Unhealthy. Результат записывается как ответ в виде простого текста с настраиваемым кодом состояния. Конфигурация описана в разделе Параметры проверки работоспособности. HealthCheckResult также может возвращать необязательные пары "ключ-значение".

Следующий пример демонстрирует структуру процесса проверки работоспособности:

public class SampleHealthCheck : IHealthCheck
{
    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        var isHealthy = true;

        // ...

        if (isHealthy)
        {
            return Task.FromResult(
                HealthCheckResult.Healthy("A healthy result."));
        }

        return Task.FromResult(
            new HealthCheckResult(
                context.Registration.FailureStatus, "An unhealthy result."));
    }
}

Логика проверки работоспособности помещается в метод CheckHealthAsync. В предыдущем примере для фиктивной переменной isHealthy задается значение true. Если isHealthy задано значение false, возвращается состояние HealthCheckRegistration.FailureStatus.

Если CheckHealthAsync вызывает исключение во время проверки, возвращается новый объект HealthReportEntry, у которого HealthReportEntry.Status равняется FailureStatus. Это состояние определяется AddCheck (см. раздел Зарегистрируйте службы проверки работоспособности) и включает внутреннее исключение, вызвавшее сбой проверки. Для сообщения исключения задается свойство Description.

Зарегистрируйте службы проверки работоспособности

Чтобы зарегистрировать службу проверки работоспособности, вызовите AddCheck в Program.cs:

builder.Services.AddHealthChecks()
    .AddCheck<SampleHealthCheck>("Sample");

Перегрузка AddCheck, показанная в следующем примере, устанавливает состояние сбоя (HealthStatus) для отчета в ситуации, когда проверка работоспособности сообщает о сбое. Если присвоено состояние сбоя null (по умолчанию), сообщается HealthStatus.Unhealthy. Эта перегрузка — полезный сценарий для авторов библиотек, где состояние сбоя от библиотеки особо учитывается приложением при сбое проверки работоспособности, если реализация проверки работоспособности учитывает этот параметр.

Теги можно использовать для фильтрации проверок работоспособности. Теги описаны в разделе Фильтрация проверок работоспособности.

builder.Services.AddHealthChecks()
    .AddCheck<SampleHealthCheck>(
        "Sample",
        failureStatus: HealthStatus.Degraded,
        tags: new[] { "sample" });

AddCheck также может выполнять лямбда-функции. В следующем примере проверка работоспособности всегда возвращает работоспособное состояние:

builder.Services.AddHealthChecks()
    .AddCheck("Sample", () => HealthCheckResult.Healthy("A healthy result."));

Вызовите AddTypeActivatedCheck, чтобы передать аргументы реализации проверки работоспособности. В следующем примере проверка работоспособности, активируемая с помощью типа, принимает целое число и строку в своем конструкторе:

public class SampleHealthCheckWithArgs : IHealthCheck
{
    private readonly int _arg1;
    private readonly string _arg2;

    public SampleHealthCheckWithArgs(int arg1, string arg2)
        => (_arg1, _arg2) = (arg1, arg2);

    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        // ...

        return Task.FromResult(HealthCheckResult.Healthy("A healthy result."));
    }
}

Чтобы зарегистрировать предыдущую проверку работоспособности, вызовите метод AddTypeActivatedCheck, передав целое число и строку в качестве аргументов:

builder.Services.AddHealthChecks()
    .AddTypeActivatedCheck<SampleHealthCheckWithArgs>(
        "Sample",
        failureStatus: HealthStatus.Degraded,
        tags: new[] { "sample" },
        args: new object[] { 1, "Arg" });

Использование маршрутизации при проверках работоспособности

В Program.cs вызовите MapHealthChecks для построителя конечной точки с URL-адресом конечной точки или относительным путем:

app.MapHealthChecks("/healthz");

RequireHost

Вызовите RequireHost, чтобы указать один или несколько разрешенных узлов для конечной точки проверки работоспособности. Узлы должны быть указаны в Юникоде, а не Punycode, и могут включать порт. Если коллекция не указана, допускается любой узел:

app.MapHealthChecks("/healthz")
    .RequireHost("www.contoso.com:5001");

Чтобы ограничить конечную точку проверки работоспособности, чтобы она отвечала только на конкретный порт, укажите порт в вызове RequireHost. Обычно этот подход используется в контейнерной среде с целью предоставления порта для мониторинга служб:

app.MapHealthChecks("/healthz")
    .RequireHost("*:5001");

Предупреждение

API, основанный на заголовке узла, например HttpRequest.Host и RequireHost, подвержены потенциальному спуфинду клиентов.

Чтобы предотвратить спуфинирование узлов и портов, используйте один из следующих подходов:

• Используйте HttpContext.Connection (ConnectionInfo.LocalPort) место проверка портов.
• Использование фильтрации узлов.

Чтобы запретить несанкционированным клиентам спуфинировать порт, вызовите следующую команду RequireAuthorization:

app.MapHealthChecks("/healthz")
    .RequireHost("*:5001")
    .RequireAuthorization();

Дополнительные сведения см. в статье Сопоставление узлов в маршрутах с помощью RequireHost.

RequireAuthorization

Вызовите RequireAuthorization для запуска ПО промежуточного слоя для авторизации в конечной точке запроса проверки работоспособности. Перегрузка RequireAuthorization принимает одну или несколько политик авторизации. Если политика не указана, используется политика авторизации по умолчанию:

app.MapHealthChecks("/healthz")
    .RequireAuthorization();

Включение запросов о происхождении (CORS)

Хотя выполнение проверок работоспособности вручную из браузера — не распространенный сценарий, можно включить ПО промежуточного слоя CORS, вызывая RequireCors в конечных точках проверки работоспособности. Перегрузка RequireCors принимает делегат построителя политики CORS (CorsPolicyBuilder) или имя политики. Дополнительные сведения см. в статье Включение запросов CORS в ASP.NET Core.

Варианты проверки работоспособности

HealthCheckOptions предоставляет возможность настройки поведения для проверки работоспособности:

• Фильтрация проверок работоспособности
• Настройка кода состояния HTTP
• Подавление заголовков кэша
• Настройка выходных данных

Фильтрация проверок работоспособности

По умолчанию ПО промежуточного слоя для проверки работоспособности выполняет все зарегистрированные проверки работоспособности. Чтобы выполнить подмножество проверок работоспособности, укажите функцию, которая возвращает логическое значение через параметр Predicate.

В следующем примере выполняется фильтрация проверок работоспособности, чтобы запускались только те, у которых есть тег sample:

app.MapHealthChecks("/healthz", new HealthCheckOptions
{
    Predicate = healthCheck => healthCheck.Tags.Contains("sample")
});

Настройка кода состояния HTTP

Используйте ResultStatusCodes для настройки сопоставления состояний работоспособности и кодов состояния HTTP. Следующие назначения StatusCodes являются значениями по умолчанию, используемыми ПО промежуточного слоя. Измените значения кодов состояния в соответствии с требованиями:

app.MapHealthChecks("/healthz", new HealthCheckOptions
{
    ResultStatusCodes =
    {
        [HealthStatus.Healthy] = StatusCodes.Status200OK,
        [HealthStatus.Degraded] = StatusCodes.Status200OK,
        [HealthStatus.Unhealthy] = StatusCodes.Status503ServiceUnavailable
    }
});

Подавление заголовков кэша

AllowCachingResponses определяет, добавляет ли ПО промежуточного слоя HTTP-заголовки в ответ проверки, чтобы предотвратить кэширование ответов. Если значение равно false (по умолчанию), ПО промежуточного слоя задает или переопределяет заголовки Cache-Control, Expires и Pragma, чтобы предотвратить кэширование ответов. Если значение равно true, ПО промежуточного слоя не изменяет заголовки кэша в ответе:

app.MapHealthChecks("/healthz", new HealthCheckOptions
{
    AllowCachingResponses = true
});

Настройка выходных данных

Чтобы настроить вывод отчета о проверках работоспособности, присвойте свойству HealthCheckOptions.ResponseWriter делегат, записывающий ответ:

app.MapHealthChecks("/healthz", new HealthCheckOptions
{
    ResponseWriter = WriteResponse
});

Делегат по умолчанию записывает минимальный ответ в виде открытого текста со строковым значением HealthReport.Status. Следующий пользовательский делегат выводит настраиваемый ответ JSON с помощью System.Text.Json:

private static Task WriteResponse(HttpContext context, HealthReport healthReport)
{
    context.Response.ContentType = "application/json; charset=utf-8";

    var options = new JsonWriterOptions { Indented = true };

    using var memoryStream = new MemoryStream();
    using (var jsonWriter = new Utf8JsonWriter(memoryStream, options))
    {
        jsonWriter.WriteStartObject();
        jsonWriter.WriteString("status", healthReport.Status.ToString());
        jsonWriter.WriteStartObject("results");

        foreach (var healthReportEntry in healthReport.Entries)
        {
            jsonWriter.WriteStartObject(healthReportEntry.Key);
            jsonWriter.WriteString("status",
                healthReportEntry.Value.Status.ToString());
            jsonWriter.WriteString("description",
                healthReportEntry.Value.Description);
            jsonWriter.WriteStartObject("data");

            foreach (var item in healthReportEntry.Value.Data)
            {
                jsonWriter.WritePropertyName(item.Key);

                JsonSerializer.Serialize(jsonWriter, item.Value,
                    item.Value?.GetType() ?? typeof(object));
            }

            jsonWriter.WriteEndObject();
            jsonWriter.WriteEndObject();
        }

        jsonWriter.WriteEndObject();
        jsonWriter.WriteEndObject();
    }

    return context.Response.WriteAsync(
        Encoding.UTF8.GetString(memoryStream.ToArray()));
}

API проверки работоспособности не предоставляет встроенной поддержки для возвращаемых данных в сложных форматах JSON, так как конкретный формат зависит от выбранной системы мониторинга. При необходимости настройте ответ в предыдущих примерах. Дополнительные сведения о сериализации JSON с помощью System.Text.Json см. в статье о сериализации и десериализации JSON в .NET.

Проверка базы данных

Проверка работоспособности может задать запрос для выполнения в качестве логического теста для указания того, отвечает ли база данных как обычно.

AspNetCore.Diagnostics.HealthChecks, библиотека проверки работоспособности для приложений ASP.NET Core включает проверку работоспособности, которая выполняется для базы данных SQL Server. AspNetCore.Diagnostics.HealthChecks выполняет запрос SELECT 1 к базе данных, чтобы подтвердить, что подключение к базе данных находится в работоспособном состоянии.

Предупреждение

При проверке подключения к базе данных с помощью запроса выберите запрос, возвращающий результат быстро. Метод запроса связан с риском перегрузки базы данных и снижения ее производительности. В большинстве случаев тестовый запрос не является обязательным. Достаточно успешного подключения к базе данных. Если вам понадобится выполнить запрос, выберите простой запрос SELECT, например SELECT 1.

Чтобы использовать эту проверку работоспособности SQL Server, включите ссылку на пакет NuGet AspNetCore.HealthChecks.SqlServer. В следующем примере регистрируется проверка работоспособности SQL Server:

var conStr = builder.Configuration.GetConnectionString("DefaultConnection");
if (string.IsNullOrEmpty(conStr))
{
    throw new InvalidOperationException(
                       "Could not find a connection string named 'DefaultConnection'.");
}
builder.Services.AddHealthChecks()
    .AddSqlServer(conStr);

Примечание.

AspNetCore.Diagnostics.HealthChecks не поддерживается и не обслуживается корпорацией Майкрософт.

Проверка DbContext в Entity Framework Core

Проверка DbContext подтверждает, что приложение может взаимодействовать с базой данных, настроенной для нееEF CoreDbContext. Проверка DbContext поддерживается в приложениях, которые:

• используют Entity Framework (EF) Core;
• Добавьте ссылку на пакет NuGet Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore.

AddDbContextCheck регистрирует проверку работоспособности для DbContext. DbContext передается методу в качестве TContext. Доступна перегрузка, позволяющая настроить состояние ошибки, теги и запрос тестирования.

По умолчанию:

• Метод DbContextHealthCheck вызоваEF CoreCanConnectAsync. Вы можете указать, какая операция выполняется в том случае, когда проверка работоспособности производится с помощью перегрузок метода AddDbContextCheck.
• Имя проверки работоспособности — это имя типа TContext.

В следующем примере показано, как зарегистрировать DbContext и связанный объект DbContextHealthCheck:

builder.Services.AddDbContext<SampleDbContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

builder.Services.AddHealthChecks()
    .AddDbContextCheck<SampleDbContext>();

Разделение проверок готовности и активности

В некоторых сценариях размещения используется пара проверок работоспособности, отличающая два состояния приложения:

• Готовность указывает, что приложение работает нормально, но не готово к приему запросов.
• Активность указывает на сбой приложения, и его необходимо перезапустить.

Рассмотрим следующий пример: приложение должно скачать большой файл конфигурации, прежде чем он готов к обработке запросов. Нам не требуется перезапуск приложения в случае сбоя начальной загрузки, так как приложение может повторить попытку скачивания файла несколько раз. Для описания активности процесса используется проба активности, дополнительные проверки не выполняются. Кроме того, мы хотим предотвратить отправку запросов в приложение до успешной загрузки файла конфигурации. Мы используем пробу активности, чтобы указать состояние "не готово" до тех пор, пока загрузка не будет завершена и приложение не сможет принимать запросы.

Следующая фоновая задача имитирует процесс запуска, который занимает примерно 15 секунд. После завершения задача устанавливает для свойства StartupHealthCheck.StartupCompleted значение true:

public class StartupBackgroundService : BackgroundService
{
    private readonly StartupHealthCheck _healthCheck;

    public StartupBackgroundService(StartupHealthCheck healthCheck)
        => _healthCheck = healthCheck;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        // Simulate the effect of a long-running task.
        await Task.Delay(TimeSpan.FromSeconds(15), stoppingToken);

        _healthCheck.StartupCompleted = true;
    }
}

StartupHealthCheck сообщает о завершении длительной задачи запуска и предоставляет свойство StartupCompleted, которое задается фоновой службой:

public class StartupHealthCheck : IHealthCheck
{
    private volatile bool _isReady;

    public bool StartupCompleted
    {
        get => _isReady;
        set => _isReady = value;
    }

    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        if (StartupCompleted)
        {
            return Task.FromResult(HealthCheckResult.Healthy("The startup task has completed."));
        }

        return Task.FromResult(HealthCheckResult.Unhealthy("That startup task is still running."));
    }
}

Проверка работоспособности регистрируется через AddCheck в Program.cs вместе с размещенной службой. Поскольку размещенной службе необходимо задать свойство проверки работоспособности, проверка работоспособности также регистрируется в контейнере службы как singleton:

builder.Services.AddHostedService<StartupBackgroundService>();
builder.Services.AddSingleton<StartupHealthCheck>();

builder.Services.AddHealthChecks()
    .AddCheck<StartupHealthCheck>(
        "Startup",
        tags: new[] { "ready" });

Чтобы создать две разные конечные точки проверки работоспособности, вызовите MapHealthChecks два раза:

app.MapHealthChecks("/healthz/ready", new HealthCheckOptions
{
    Predicate = healthCheck => healthCheck.Tags.Contains("ready")
});

app.MapHealthChecks("/healthz/live", new HealthCheckOptions
{
    Predicate = _ => false
});

В предыдущем примере создаются приведенные ниже конечные точки проверки работоспособности:

• В /healthz/ready для проверки готовности. Проверка готовности фильтрует проверки работоспособности, оставляя те, которые помечены ready.
• В /healthz/live для проверки жизнеспособности. Проверка активности отфильтровывает все проверки работоспособности, возвращая false в делегат HealthCheckOptions.Predicate. Дополнительные сведения о фильтрации проверок работоспособности см. в разделе Фильтрация проверок работоспособности в этой статье.

Перед завершением задачи запуска конечная точка /healthz/ready сообщает о состоянии Unhealthy. После завершения задачи запуска эта конечная точка сообщает о состоянии Healthy. Конечная точка /healthz/live исключает все проверки и сообщает о состоянии Healthy всех вызовов.

Пример для Kubernetes

Использование отдельных проверок готовности и жизнеспособности полезно в таких средах, как Kubernetes. В Kubernetes приложениям может потребоваться долго выполнять задачи во время запуска, прежде чем начать принимать запросы; например, проверить доступность основной базы данных. Использование отдельных проверок позволяет оркестратору различать, когда приложение работает, но еще не готово, а когда приложение не удалось запустить. Дополнительные сведения о проверках готовности и жизнеспособности в Kubernetes см. в разделе Настройка проверок готовности и жизнеспособности в документации по Kubernetes.

В следующем примере показана конфигурация проверки готовности для Kubernetes:

spec:
  template:
  spec:
    readinessProbe:
      # an http probe
      httpGet:
        path: /healthz/ready
        port: 80
      # length of time to wait for a pod to initialize
      # after pod startup, before applying health checking
      initialDelaySeconds: 30
      timeoutSeconds: 1
    ports:
      - containerPort: 80

Распространение библиотеки проверки работоспособности

Чтобы распространять проверки работоспособности в качестве библиотеки, выполните следующие действия.

1. Напишите проверку работоспособности, которая реализует интерфейс IHealthCheck как автономный класс. Класс может полагаться на внедрение зависимостей (DI), активацию типов и именованные параметры для доступа к данным конфигурации.

2. Напишите метод расширения с параметрами, который приложение вызывает в своем методе Program.cs. Рассмотрим следующий пример проверки работоспособности, который принимает arg1 и arg2 в качестве параметров конструктора:

   public SampleHealthCheckWithArgs(int arg1, string arg2)
       => (_arg1, _arg2) = (arg1, arg2);
   

   Эта сигнатура указывает, что проверке работоспособности требуются пользовательские данные для обработки логики проверки работоспособности. Данные передаются делегату, используемому для создания экземпляра проверки работоспособности, когда проверка работоспособности регистрируется с помощью метода расширения. В следующем примере вызывающая сторона задает:

   • arg1 — целочисленная точка данных для проверки работоспособности.
   • arg2 — строковый аргумент для проверки работоспособности.
   • name — необязательное имя проверки работоспособности. При null используется значение по умолчанию.
   • failureStatus — необязательные HealthStatus, который передается в случае состояния неполадки. Если null, используется HealthStatus.Unhealthy.
   • tags — необязательная коллекция тегов IEnumerable<string>.

   public static class SampleHealthCheckBuilderExtensions
   {
       private const string DefaultName = "Sample";
   
       public static IHealthChecksBuilder AddSampleHealthCheck(
           this IHealthChecksBuilder healthChecksBuilder,
           int arg1,
           string arg2,
           string? name = null,
           HealthStatus? failureStatus = null,
           IEnumerable<string>? tags = default)
       {
           return healthChecksBuilder.Add(
               new HealthCheckRegistration(
                   name ?? DefaultName,
                   _ => new SampleHealthCheckWithArgs(arg1, arg2),
                   failureStatus,
                   tags));
       }
   }
   

Издатель проверки работоспособности

Когда IHealthCheckPublisher добавляется в контейнер службы, система проверки работоспособности периодически выполняет ваши проверки работоспособности и вызывает PublishAsync с полученным результатом. Этот процесс полезен в ситуации принудительной передачи данных мониторинга работоспособности, когда ожидается, что каждый процесс периодически вызывает систему мониторинга для определения работоспособности.

HealthCheckPublisherOptions позволяет задать следующие параметры:

• Delay: начальная задержка, примененная после запуска приложения перед выполнением IHealthCheckPublisher экземпляров. Задержка применяется при запуске один раз и не распространяется на все последующие итерации. Значение по умолчанию — пять секунд.
• Period: период IHealthCheckPublisher выполнения. Значение по умолчанию — 30 секунд.
• Predicate: если Predicate задано null (по умолчанию), служба издателя проверка работоспособности запускает все зарегистрированные проверка работоспособности. Чтобы выполнить ряд проверок работоспособности, укажите функцию, которая отфильтровывает нужный набор. Предикат вычисляется в каждом периоде.
• Timeout: время ожидания для выполнения проверка работоспособности для всех IHealthCheckPublisher экземпляров. Используйте InfiniteTimeSpan, чтобы выполнить проверки без задержки. Значение по умолчанию — 30 секунд.

Следующий пример демонстрирует структуру издателя проверки работоспособности:

public class SampleHealthCheckPublisher : IHealthCheckPublisher
{
    public Task PublishAsync(HealthReport report, CancellationToken cancellationToken)
    {
        if (report.Status == HealthStatus.Healthy)
        {
            // ...
        }
        else
        {
            // ...
        }

        return Task.CompletedTask;
    }
}

Класс HealthCheckPublisherOptions предоставляет свойства для настройки поведения издателя проверки работоспособности.

В следующем примере регистрируется издатель проверки работоспособности как singleton и настраиваются HealthCheckPublisherOptions:

builder.Services.Configure<HealthCheckPublisherOptions>(options =>
{
    options.Delay = TimeSpan.FromSeconds(2);
    options.Predicate = healthCheck => healthCheck.Tags.Contains("sample");
});

builder.Services.AddSingleton<IHealthCheckPublisher, SampleHealthCheckPublisher>();

AspNetCore.Diagnostics.HealthChecks:

• Включает издателей для нескольких систем, включая Аналитика приложений.
• Не поддерживается или поддерживается корпорацией Майкрософт.

Отдельные работоспособности проверка

Delay и Period можно задать для каждого из них HealthCheckRegistration по отдельности. Это полезно, если требуется запустить некоторые проверка работоспособности по сравнению с заданным периодомHealthCheckPublisherOptions.

Следующий код задает и Period для SampleHealthCheck1следующих элементовDelay:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks()
   .Add(new HealthCheckRegistration(
       name: "SampleHealthCheck1",
       instance: new SampleHealthCheck(),
       failureStatus: null,
       tags: null,
       timeout: default)
   {
       Delay = TimeSpan.FromSeconds(40),
       Period = TimeSpan.FromSeconds(30)
   });

var app = builder.Build();

app.MapHealthChecks("/healthz");

app.Run();

Внедрение зависимостей и проверка работоспособности

Можно использовать внедрение зависимостей для использования экземпляра определенного Type внутри класса проверки работоспособности. Внедрение зависимостей может быть полезно для внедрения параметров или глобальной конфигурации в проверку работоспособности. Использование внедрения зависимостей не является обычным сценарием для настройки проверок работоспособности. Обычно каждая проверка работоспособности вполне зависит от фактического теста и настраивается с помощью IHealthChecksBuilder методов расширения.

В следующем примере показан пример проверки работоспособности, который извлекает объект конфигурации с помощью внедрения зависимостей:

public class SampleHealthCheckWithDI : IHealthCheck
{
    private readonly SampleHealthCheckWithDiConfig _config;

    public SampleHealthCheckWithDI(SampleHealthCheckWithDiConfig config)
        => _config = config;

    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        var isHealthy = true;

        // use _config ...

        if (isHealthy)
        {
            return Task.FromResult(
                HealthCheckResult.Healthy("A healthy result."));
        }

        return Task.FromResult(
            new HealthCheckResult(
                context.Registration.FailureStatus, "An unhealthy result."));
    }
}

Необходимо SampleHealthCheckWithDiConfig добавить проверка работоспособности в контейнер службы:

builder.Services.AddSingleton<SampleHealthCheckWithDiConfig>(new SampleHealthCheckWithDiConfig
{
    BaseUriToCheck = new Uri("https://sample.contoso.com/api/")
});
builder.Services.AddHealthChecks()
    .AddCheck<SampleHealthCheckWithDI>(
        "With Dependency Injection",
        tags: new[] { "inject" });

UseHealthChecks vs. MapHealthChecks

Существует два способа сделать работоспособности проверка доступными для абонентов:

• UseHealthChecksрегистрирует ПО промежуточного слоя для обработки запросов работоспособности проверка в конвейере ПО промежуточного слоя.
• MapHealthChecksрегистрирует конечную точку работоспособности проверка. Конечная точка сопоставляется и выполняется вместе с другими конечными точками в приложении.

Преимуществом использования MapHealthChecks является UseHealthChecks возможность использовать по промежуточному слоям, поддерживающим конечные точки, например авторизацию, и более точное управление политикой сопоставления. Основным преимуществом использования UseHealthChecks является MapHealthChecks управление именно тем, где выполняются проверка работоспособности в конвейере ПО промежуточного слоя.

UseHealthChecks:

• Завершает конвейер, когда запрос соответствует конечной точке работоспособности проверка. Короткое замыкание часто желательно, так как это позволяет избежать ненужных работ, таких как ведение журнала и другое ПО промежуточного слоя.
• В основном используется для настройки по промежуточному слоям работоспособности проверка конвейера.
• Может совпадать с любым путем на порту или пустым nullPathString. Позволяет выполнять проверка работоспособности при любом запросе, сделанном на указанный порт.
• исходный код.

MapHealthChecks Позволяет:

• Завершение конвейера при выполнении запроса соответствует конечной точке работоспособности проверка путем вызоваShortCircuit. Например, app.MapHealthChecks("/healthz").ShortCircuit();. Дополнительные сведения см. в разделе ПО промежуточного слоя короткого канала после маршрутизации.
• Сопоставление определенных маршрутов или конечных точек для проверка работоспособности.
• Настройка URL-адреса или пути, в котором доступна конечная точка работоспособности проверка.
• Сопоставление нескольких конечных точек работоспособности проверка с различными маршрутами или конфигурациями. Поддержка нескольких конечных точек:
  • Включает отдельные конечные точки для различных типов проверка работоспособности или компонентов.
  • Используется для разных аспектов работоспособности приложения или применения определенных конфигураций к подмножествам проверка работоспособности.
• исходный код.

Дополнительные ресурсы

• Просмотреть или скачать образец кода (описание загрузки)

Примечание.

Эта статья была частично создана с помощью искусственного интеллекта. Перед публикацией автор проверил и отредактировал содержимое по мере необходимости. См. раздел Наши принципы использования созданного ИИ содержимого в Microsoft Learn.