Проверка работоспособности Service Fabric
Есть ли встроенная проверка работоспособности служебной ткани? У меня есть гостевой исполняемый файл, написанный на NET Core 2.2 и использующий в нем функцию проверки работоспособности. Например, у меня есть простая проверка работоспособности, которая возвращает нездоровое состояние:
services
.AddHealthChecks()
.AddCheck<DocumentDbHealthCheck>("cosmos-database");
internal class DocumentDbHealthCheck : IHealthCheck
{
public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default(CancellationToken))
{
return Task.FromResult(HealthCheckResult.Unhealthy());
}
}
Я подключил это, используя:
app.UseHealthChecks(@"/foo/bar/v1/healthcheck");
Однако, когда я локально запускаю свой экземпляр служебной фабрики в рабочем состоянии, я ожидал, что он будет в ошибочном / неработоспособном состоянии.
Возможно ли, чтобы Service Fabric попала в маршрут проверки работоспособности API?
Ответы 1
Проверка здоровья, представленный в AspNetCore, представляет собой механизм для возврата данных о состоянии некоторой службы, он не влияет на фактическое состояние службы.
В Service Fabric, если вы хотите сообщить о работоспособности из службы в систему работоспособности Service Fabric, вы можете использовать API ReportReplicaHealth(). что-то вроде это:
HealthInformation healthInformation = new HealthInformation("ServiceCode", "StateDictionary", HealthState.Error);
this.Partition.ReportReplicaHealth(healthInformation);
Это будет отображаться в SF Explorer как ошибка.
Вы также можете сообщать о проблемах с помощью FabricClient, как описано здесь, в этом случае вы должны создать службу для мониторинга других служб, а затем сообщить об их статусе, также известную как Watchdog.
AFAIK, Service Fabric не имеет механизма HTTP Probe для проверки работоспособности службы, он использует внутренние метрики, сообщаемые службой, непосредственно в подсистему работоспособности.
Если вы планируете использовать его для проверки работоспособности службы перед отправкой ей запроса, вы можете использовать HTTP-зонды балансировщика нагрузки или просто поместить его за прокси, который обрабатывает сбои и перенаправляет запрос на действительный узел, например встроенный в обратном прокси, как описано здесь.
Я уверен, что не существует механизма, позволяющего преобразовать сбой в отчет о состоянии работоспособности. Но вы должны уметь написать сторожевого пса.