Большинство health check'ов проверяют три вещи:
- Запущен ли процесс?
- Есть ли коннект к базе данных?
- Доступен ли Redis?
Это полезно. Но этого недостаточно для больших продуктивных систем.
Приложение может быть технически живым и при этом функционально сломанным. Процесс работает, эндпоинт возвращает 200, Kubernetes считает под здоровым, но первый же реальный запрос падает с ошибкой.
К примеру, кастомный health check для EF Core миграций:
public class DbContextMigrationsHealthCheck(DbContext dbContext) : IHealthCheck
{
public async Task<HealthCheckResult> CheckHealthAsync(
HealthCheckContext context,
CancellationToken cancellationToken = default)
{
try
{
var applied = await dbContext.Database
.GetAppliedMigrationsAsync(cancellationToken: cancellationToken);
var pending = await dbContext.Database
.GetPendingMigrationsAsync(cancellationToken);
if (pending.Any())
{
return HealthCheckResult.Degraded(
"Есть неприменённые миграции.",
data: new Dictionary<string, object>
{
{ "PendingMigrations", pending },
{ "LatestAppliedMigration", applied.LastOrDefault() ?? "" }
});
}
return HealthCheckResult.Healthy(
data: new Dictionary<string, object>
{
{ "LatestAppliedMigration", applied.LastOrDefault() ?? "" }
});
}
catch (Exception ex)
{
return new HealthCheckResult(context.Registration.FailureStatus, exception: ex);
}
}
}
Идея не ограничивается EF Core. Любая зависимость, которая доступна, но ещё не готова к работе:
• CMS — нужно прогреть кэш перед началом работы
• Биллинг — зависит от загрузки актуальных правил ценообразования
• Search API — ждёт готовности текущей версии индекса
Сервис здоров не тогда, когда открывает SQL-коннекшн. Сервис здоров, когда готов выполнять ту работу, для которой задеплоен.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека шарписта
#il_люминатор