Общие сведения о наблюдении за работоспособностью системы в Service Fabric

Статья
06/01/2023

В платформе Azure Service Fabric используется модель работоспособности c широкими и гибкими возможностями оценки работоспособности и создания отчетов, которая позволяет отслеживать состояние кластера и выполняющихся в нем служб практически в реальном времени. Вы можете легко получать сведения о работоспособности и устранять потенциальные проблемы, прежде чем они приведут к серьезным перебоям в работе. Службы в рамках обычной модели отправляют отчеты на локальном уровне, а затем полученная информация агрегируется на уровне кластера.

Компоненты Service Fabric используют эту многофункциональную модель для отправки отчетов о своем текущем состоянии. Вы тоже можете использовать этот механизм для получения информации о работоспособности своих приложений. Приложив усилия к созданию качественного механизма, генерирующего отчеты о состоянии работоспособности компонентов среды, вы сможете более эффективно обнаруживать и исправлять проблемы в своих приложениях.

На этой странице можно просмотреть обучающие видеоматериалы, описывающие модель работоспособности Service Fabric и ее использование:

Примечание

Мы выпустили подсистему обеспечения работоспособности для удовлетворения потребности в отслеживаемых обновлениях. Service Fabric поддерживает отслеживаемую систему обновления приложений и кластеров, которая обеспечивает полную доступность, исключает простои и почти не требует участия пользователя. Для достижения этих целей процесс обновления проверяет работоспособность на основе настроенных политик обновления. Обновление может быть продолжено только в том случае, если соблюдены требуемые пороги работоспособности. В противном случае автоматически выполняется откат или обновление приостанавливается, пока администраторы не устранят проблему. Дополнительные сведения об обновлении приложений см. в этой статье.

Хранилище данных о работоспособности

В хранилище данных о работоспособности хранится информация, связанная с состоянием сущностей в кластере, которую можно извлечь и изучить. Хранилище реализовано в виде хранимой службы Service Fabric с отслеживанием состояния, что позволяет обеспечить высокую доступность и масштабируемость. Оно является частью приложения fabric:/System и доступно сразу после запуска кластера.

Сущности и иерархия работоспособности

Сущности работоспособности упорядочены в логическую иерархию со связями и зависимостями между сущностями. Хранилище данных о работоспособности создает сущности и иерархию автоматически, на основе отчетов, получаемых от компонентов Service Fabric.

Сущности работоспособности отражают сущности Service Fabric. (Например, сущность приложения работоспособности соответствует экземпляру приложения, развернутому в кластере, тогда как сущность узла работоспособности соответствует узлу кластера Service Fabric.) Иерархия работоспособности фиксирует взаимодействия системных сущностей и является основой для расширенной оценки работоспособности. Дополнительные сведения о ключевых понятиях Service Fabric см. в статье Технический обзор Service Fabric. Дополнительные сведения о приложениях см. в статье Модель приложения Service Fabric.

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

Сущности работоспособности. Сущности работоспособности, упорядоченные в иерархии на основе отношений "родители-потомки".

К сущностям работоспособности относятся:

Cluster(кластер). Отражает работоспособность кластера Service Fabric. Отчеты о работоспособности кластера описывают условия, которые влияют на весь кластер. Эти условия охватывают несколько сущностей в кластере или сам кластер. С учетом условия информатор не может свести проблему к одному или нескольким неработоспособным дочерним элементам. Пример: разделение мощностей кластера из-за проблем со связью или фрагментацией сети.
Node. Отражает работоспособность узла Service Fabric. Отчеты о работоспособности узла описывают условия, которые влияют на работу узла. Обычно они влияют на все развернутые сущности, запущенные на узле. Примеры: узлу не хватает места на диске (памяти, подключений или других свойств уровня компьютера) или узел не работает. Сущность узла идентифицируется по имени узла (строка).
Приложения Отражает работоспособность экземпляра приложения, выполняющегося в кластере. Отчеты о работоспособности приложения описывают условия, которые влияют на общую работоспособность приложения. Они не могут быть отнесены к отдельным дочерним элементам (службам или развернутым приложениям). Пример: сквозное взаимодействие между различными службами в приложении. Сущность приложения определяется именем приложения (URI).
Служба. Отражает работоспособность службы, выполняющейся в кластере. Отчеты о работоспособности службы описывают условия, которые влияют на общую работоспособность службы. Информатор не может свести проблему к неработоспособной секции или реплике. Пример: конфигурация службы (например, порт или внешняя общая папка), которая является причиной проблем во всех разделах. Сущность службы определяется именем службы (URI).
Partition(раздел). Отражает работоспособность раздела службы. Отчеты о работоспособности раздела описывают условия, которые влияют на весь набор реплик. Пример: количество реплик меньше требуемого или в разделе нет кворума. Сущность раздела определяется идентификатором раздела (GUID).
Replica(реплика). Отражает работоспособность реплики службы с отслеживанием состояния или экземпляра службы без отслеживания состояния. Реплика — это минимальная единица, которую модули наблюдения и компоненты системы могут включать в отчеты о приложении. К примерам служб с отслеживанием состояния можно отнести первичную реплику, которая не может реплицировать операции на вторичные реплики, из-за чего снижается скорость репликации. Кроме того, экземпляр службы без сохранения состояния может отправлять отчет, если заканчиваются ресурсы или возникают проблемы с подключением. Сущность реплики определяется идентификатором раздела (GUID) и (длинным) идентификатором реплики или экземпляра.
DeployedApplication(развернутое приложение). Отражает работоспособность приложения, выполняющегося на узле. Отчеты о работоспособности развернутого приложения описывают условия, специфические для конкретного приложения на узле, которые не могут быть отнесены к уровню пакетов служб, развернутых на том же узле. Примеры: не удается скачать пакет приложения на узле или возникли проблемы с настройкой субъектов безопасности приложения на узле. Развернутое приложение определяется именем приложения (URI) и именем узла (строка).
DeployedServicePackage(развернутый пакет службы). Отражает состояние работоспособности для пакета службы, работающего на узле в кластере. Описываются условия, относящиеся к конкретному пакету службы и не влияющие на другие пакеты служб того же приложения на том же узле. Пример: не удается запустить пакет кода в пакете службы или не удается прочитать пакет конфигурации. Развернутый пакет службы определяется именем приложения (универсальный код ресурса (URI)), именем узла (строка), именем манифеста службы (строка) и идентификатором активации пакета службы (строка).

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

Иерархия работоспособности состоит из отношений между родительскими и дочерними объектами. Кластер состоит из узлов и приложений. Приложения включают службы и развернутые приложения. В развернутые приложения входят развернутые пакеты служб. Службы состоят из разделов, а каждый раздел включает одну или несколько реплик. Между узлами и развернутыми сущностями существует особая связь. Если ответственный за узел системный компонент (служба диспетчера отработки отказов) сообщает о неработоспособности узла, то такая проблема затрагивает развернутые на узле приложения, пакеты служб и реплики.

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

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

Состояния работоспособности

Для описания работоспособности в Service Fabric используются три состояния: ОК, Warning и Error. Во всех отчетах, отправляемых в хранилище данных о работоспособности, должно быть указано одно из этих состояний. Эти же значения используются в качестве результата оценки работоспособности.

Возможные состояния работоспособности перечислены ниже:

OK. Сущность работоспособна. Известных проблем с сущностью или ее дочерними элементами (если таковые есть) не выявлено.
Предупреждение. В работе сущности возникли проблемы, но она по-прежнему может правильно функционировать. Например, возникли задержки, но они еще не вызывают проблем в работе. В некоторых случаях условие, вызвавшее предупреждение, может самоустраниться без внешнего вмешательства. В этих случаях отчеты о работоспособности повышают информированность и обеспечивают представление о том, что происходит. В других случаях без вмешательства пользователя предупреждение может перерасти в серьезную проблему.
Ошибка. Сущность неработоспособна. Следует выполнить определенные действия для исправления состояния сущности, так как она не может работать корректно.
Неизвестно. Сущность не существует в хранилище данных о работоспособности. Этот результат можно получить из распределенных запросов, которые объединяют данные от нескольких компонентов. Например, запрос списка узлов передается в FailoverManager, ClusterManager и HealthManager, а запрос списка приложений передается в ClusterManager и HealthManager. В этих запросах объединяются результаты, полученные от нескольких компонентов системы. Если один из компонентов системы передаст сущность, которая отсутствует в хранилище данных о работоспособности, то в объединенном результате будет указано состояние работоспособности "Неизвестно". Сущность может отсутствовать в хранилище, так как отчеты о работоспособности еще не были обработаны или сущность не была очищена после удаления.

Политики работоспособности

Для определения работоспособности сущности хранилище данных о работоспособности применяет к отчетам по ней и ее дочерним элементам политики работоспособности.

Примечание

Политики можно указать в манифесте кластера (для оценки работоспособности кластера и узла) или в манифесте приложения (для оценки состояния приложения и его дочерних элементов). Запросы на оценку работоспособности также можно включать в пользовательские политики оценки работоспособности (политики, которые применяются только в ходе определенной оценки).

По умолчанию в Service Fabric действуют строгие правила (работоспособными должны быть все элементы) для иерархических отношений между родительскими и дочерними объектами. Если хотя бы один дочерний элемент неработоспособен, родительский объект также считается неработоспособным.

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

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

Политика работоспособности кластера включает следующие параметры.

ConsiderWarningAsError. Указывает, следует ли при оценке работоспособности обрабатывать предупреждения как ошибки. По умолчанию: false.
MaxPercentUnhealthyApplications. Указывает максимально допустимый процент неработоспособных приложений, превышение которого вызывает состояние Error при оценке кластера.
MaxPercentUnhealthyNodes. Указывает максимально допустимый процент неработоспособных узлов, превышение которого вызывает состояние Error при оценке кластера. В крупных кластерах всегда есть отключенные узлы или узлы в состоянии восстановления. Следует учитывать это при настройке параметра.
ApplicationTypeHealthPolicyMap. Сопоставление политики работоспособности для типа приложения используется во время оценки работоспособности кластера для описания особых типов приложений. По умолчанию все приложения помещаются в пул и оцениваются с помощью MaxPercentUnhealthyApplications. Если некоторые типы приложений должны обрабатываться иначе, их можно исключить из глобального пула. Тогда для их оценки будут применяться процентные значения, которые на карте связаны с соответствующим именем типа приложения. Например, в кластере существуют тысячи приложений различных типов и несколько экземпляров управляющих приложений особого типа. Управляющие приложения никогда не должны находиться в состоянии ошибки. Вы можете установить для параметра MaxPercentUnhealthyApplications значение 20 %, чтобы некоторое количество ошибок считалось допустимым. Для типа приложения ControlApplicationType нужно присвоить значение 0 параметру MaxPercentUnhealthyApplications. Таким образом, если некоторые из многих приложений находятся в неработоспособном состоянии, но их доля не превышает допустимой глобальной доли неработоспособных приложений, состояние работоспособности кластера будет оцениваться как "Предупреждение". Состояние "Предупреждение" не влияет на обновление кластера или другие операции мониторинга, вызванные состоянием "Ошибка". Но если хотя бы одно управляющее приложение будет иметь состояние "Ошибка", кластер будет считаться неработоспособным. Это приведет к откату или приостановке обновления кластера в зависимости от конфигурации обновлений. Для типов приложений, определенных в сопоставлении, все экземпляры приложений будут извлечены из глобального пула приложений. Они оцениваются на основе общего числа приложений заданного типа с помощью соответствующего параметра MaxPercentUnhealthyApplications из сопоставления. Все остальные приложения остаются в глобальном пуле и оцениваются с помощью параметра MaxPercentUnhealthyApplications.

Следующий пример содержит фрагмент манифеста кластера. Для определения записей в сопоставлении типов приложений укажите имя параметра с префиксом "ApplicationTypeMaxPercentUnhealthyApplications-", за которым следует имя типа приложения.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="ApplicationTypeMaxPercentUnhealthyApplications-ControlApplicationType" Value="0" />
  </Section>
</FabricSettings>
```
NodeTypeHealthPolicyMap. Сопоставление политики работоспособности для типа узла используется при оценке работоспособности кластера для описания особых типов узлов. Типы узлов сравниваются с процентными значениями, которые связаны с соответствующим именем типа узла в сопоставлении. Определение этого значения не влияет на глобальный пул узлов, используемых для MaxPercentUnhealthyNodes. Например, кластер содержит сотни узлов различных типов и есть несколько типов узлов, которые выполняют важную работу. Ни один из узлов этого типа не должен отключаться. Можно указать глобальное значение MaxPercentUnhealthyNodes, равное 20 %, чтобы допустить некоторые сбои для всех узлов, но для типа узла SpecialNodeType установите для параметра MaxPercentUnhealthyNodes значение 0. Таким образом, если некоторые из узлов находятся в неработоспособном состоянии, но их доля не превышает допустимой глобальной доли, состояние работоспособности кластера будет оцениваться как "Предупреждение". Состояние "Предупреждение" не влияет на обновление кластера или другие операции мониторинга, вызванные состоянием "Ошибка". Но даже один узел типа SpecialNodeType в состоянии работоспособности "Ошибка" сделает кластер неработоспособным и активирует откат или приостановит обновление кластера в зависимости от конфигурации обновления. И наоборот, если установить глобальное значение MaxPercentUnhealthyNodes равное 0 и указать для SpecialNodeType максимальный процент неработоспособных узлов равный 100, при одном узле типа SpecialNodeType в состоянии ошибки кластер будет находиться в состоянии ошибки, т. к. глобальное ограничение в данном случае является более строгим.

Следующий пример содержит фрагмент манифеста кластера. Чтобы определить записи в сопоставлении типа узла, перед именем параметра укажите "NodeTypeMaxPercentUnhealthyNodes-", за которым следует имя типа узла.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="NodeTypeMaxPercentUnhealthyNodes-SpecialNodeType" Value="0" />
  </Section>
</FabricSettings>
```

Политика работоспособности приложения

Политика работоспособности приложения описывает, как выполняется оценка и агрегирование событий, состояний приложения и его дочерних элементов. Ее можно определить в манифесте приложения (файл ApplicationManifest.xmlв пакете приложения). Если политика не определена, платформа Service Fabric предполагает, что сущность неработоспособна, если в отчете по ней или ее дочернему элементу указано состояние Warning или Error. В политике можно настроить такие параметры:

ConsiderWarningAsError. Указывает, следует ли при оценке работоспособности обрабатывать предупреждения как ошибки. По умолчанию: false.
MaxPercentUnhealthyDeployedApplications. Указывает максимально допустимый процент неработоспособных приложений, превышение которого вызывает состояние Error при оценке приложения. Это выраженное в процентах частное от деления количества неработоспособных развернутых приложений на количество узлов в кластере, на которых сейчас развернуты приложения. Расчет округляется: на небольшом количестве узлов допускается один сбой. Значение в процентах по умолчанию: ноль.
DefaultServiceTypeHealthPolicy. Задает политику работоспособности для типов служб по умолчанию, которая заменяет политику работоспособности по умолчанию для всех типов служб в приложении.
ServiceTypeHealthPolicyMap. Обеспечивает сопоставление политики работоспособности службы для каждого типа службы. Эти политики заменяют стандартные политики работоспособности для каждого указанного типа службы. Например, если приложение использует службы с типами "шлюз без отслеживания состояния" и "механизм с отслеживанием состояния", для их оценки можно настроить разные политики работоспособности. Настройка отдельных политик для разных типов служб позволяет отслеживать работоспособность на более детализированном уровне.

Политика работоспособности типа службы

Политика работоспособности типа службы определяет способ оценки и агрегации состояний служб и дочерних элементов службы. Политика включает следующие параметры.

MaxPercentUnhealthyPartitionsPerService. Указывает максимально допустимый процент неработоспособных разделов, превышение которого приведет к оценке службы как неработоспособной. Значение в процентах по умолчанию: ноль.
MaxPercentUnhealthyReplicasPerPartition. Указывает максимально допустимый процент неработоспособных реплик, превышение которого приведет к оценке раздела как неработоспособного. Значение в процентах по умолчанию: ноль.
MaxPercentUnhealthyServices. Указывает максимально допустимый процент неработоспособных служб, превышение которого приведет к оценке приложения как неработоспособного. Значение в процентах по умолчанию: ноль.

Следующий пример содержит фрагмент манифеста приложения.

    <Policies>
        <HealthPolicy ConsiderWarningAsError="true" MaxPercentUnhealthyDeployedApplications="20">
            <DefaultServiceTypeHealthPolicy
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="10"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="FrontEndServiceType"
                   MaxPercentUnhealthyServices="0"
                   MaxPercentUnhealthyPartitionsPerService="20"
                   MaxPercentUnhealthyReplicasPerPartition="0"/>
            <ServiceTypeHealthPolicy ServiceTypeName="BackEndServiceType"
                   MaxPercentUnhealthyServices="20"
                   MaxPercentUnhealthyPartitionsPerService="0"
                   MaxPercentUnhealthyReplicasPerPartition="0">
            </ServiceTypeHealthPolicy>
        </HealthPolicy>
    </Policies>

Оценка работоспособности

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

Агрегирование отчетов о работоспособности

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

Сводное состояние работоспособности определяется по отчетам с наихудшими оценками состояния сущности. Если есть хотя бы один отчет о работоспособности со значением Error, сводным состоянием будет Error.

Агрегирование отчетов о работоспособности с состоянием Error.

Сущность оценки работоспособности, в отношении которой регистрируется один или несколько отчетов об ошибках, получает состояние "Ошибка". Это справедливо и для отчета о работоспособности с истекшим сроком действия, независимо от состояния его работоспособности.

Если отчетов со значением Error нет, но есть одно или несколько значений Warning, сводным состоянием может быть как Error, так и Warning (в зависимости от флага политики ConsiderWarningAsError).

Схема агрегирования отчетов о работоспособности, включающая отчет с состоянием Warning и флаг ConsiderWarningAsError со значением False.

Схема агрегирования отчетов о работоспособности, включающая отчет с состоянием Warning и флаг ConsiderWarningAsError со значением False (по умолчанию).

Агрегирование данных о работоспособности дочерних элементов

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

Агрегирование данных о работоспособности дочерних элементов.

Агрегирование состояний дочерних элементов на основе политик работоспособности.

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

Если все дочерние элементы находятся в состоянии ОК, их сводным состоянием также будет ОК.
Если дочерние элементы имеют состояния ОК и Warning, их сводным состоянием будет Warning.
Если число дочерних элементов с состоянием Error превышает максимальный допустимый процент неработоспособных дочерних элементов, сводным состоянием родительского элемента будет Error.
В противном случае сводным состоянием будет Warning.

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

Создавать отчеты для сущностей Service Fabric могут системные компоненты, приложения Service Fabric, а также внутренние и внешние модули мониторинга. Создатели отчетов определяют работоспособность контролируемых сущностей локально на основе определенных условий мониторинга. Для этого не нужно учитывать глобальное состояние или агрегированные данные. Желательно использовать простые информаторы, а не сложные конструкции, которые оценивают множество параметров при выборе отправляемой информации.

Для отправки данных о работоспособности в хранилище создателям отчетов необходимо определить, какая сущность затронута, а затем создать отчет о ее работоспособности. Чтобы отправить отчет, используйте API FabricClient.HealthClient.ReportHealth, предоставляемые для объектов Partition или CodePackageActivationContext интерфейсы API отчетов о работоспособности, командлеты PowerShell или REST.

Отчеты о работоспособности

Отчеты о работоспособности для каждой сущности в кластере содержат такие сведения:

SourceId. Это строка обозначает создателя отчета, содержащего сведения о событии, которое затрагивает работоспособность.
Entity identifier. Сущность, к которой применяется отчет. Этот идентификатор зависит от типа сущности:
- Cluster. Нет.
- Node. Имя узла (строка).
- приложение. Имя приложения (URI). Имя экземпляра приложения, развернутого в кластере.
- Service. Имя службы (URI). Имя экземпляра службы, развернутого в кластере.
- Partition. Идентификатор раздела (GUID). Уникальный идентификатор раздела.
- Replica. Идентификатор реплики службы с отслеживанием состояния или идентификатор экземпляра службы без отслеживания состояния (INT64).
- DeployedApplication. Имя приложения (URI) и имя узла (строка).
- DeployedServicePackage. Имя приложения (URI), имя узла (строка) и имя манифеста службы (строка).
Property. Строка (не фиксированное перечисление), позволяющая создателям отчетов классифицировать событие, связанное с работоспособностью, используя конкретное свойство сущности. Например, создатель отчетов A может отправить отчет о работоспособности для свойства storage узла Node01, а создатель отчетов B — отчет о работоспособности для свойства connectivity того же узла. В хранилище данных о работоспособности эти отчеты считаются независимыми событиями работоспособности для сущности Node01.
Описание. Строка, позволяющая создателям отчетов добавлять подробные сведения о событии работоспособности. Параметры SourceId, Property и HealthState должны полностью описывать содержимое отчета. Эта строка с описанием содержит адаптированные сведения об отчете, которые упрощают интерпретацию данных в отчете для пользователей и администраторов.
HealthState. Перечисление , описывающее указанное в отчете состояние. Допустимы значения ОК, Warning (предупреждение) и Error (ошибка).
TimeToLive. Период времени, в течение которого отчет о работоспособности действителен. В сочетании с параметром RemoveWhenExpiredуказывает, как хранилище данных о работоспособности должно оценивать события с истекшим сроком действия. По умолчанию срок действия не ограничен и отчет действителен вечно.
RemoveWhenExpired(кластер). Логическое значение. Если задано значение True, отчет о работоспособности с истекшим сроком действия автоматически удаляется из хранилища данных о работоспособности. Такой отчет больше не влияет на оценку состояния сущности. Используется, если отчет действителен только в течение заданного периода времени, и автор не должен явно очищать его. Также используется для удаления отчетов из хранилища данных о работоспособности (например, устройство наблюдения было изменено и прекратило отправку отчетов с предыдущим источником и свойством). Отчет может быть отправлен с небольшим сроком жизни и установленным флагом RemoveWhenExpired, чтобы удалить все предыдущие состояния из хранилища данных о работоспособности. Если задано значение False, отчет с истекшим сроком действия в ходе оценки рассматривается как ошибка. Значение False указывает хранилищу данных о работоспособности о том, что источник должен периодически отправлять отчеты об этом свойстве. В противном случае это указывает на сбой в модуле наблюдения. При оценке работоспособности этого модуля наблюдения такое состояние рассматривается как ошибка.
SequenceNumber. Постоянно растущее положительное целое число, которое представляет порядковый номер отчетов. Хранилище данных о работоспособности использует этот номер для выявления устаревших отчетов, полученных с опозданием из-за задержек в сети или по другим причинам. Если порядковый номер отчета меньше номера последнего примененного отчета для тех же сущности, источника и свойства или равен этому номеру, такой отчет отклоняется. Если параметр не указан, порядковый номер создается автоматически. Это необходимо для включения порядкового номера, только в рамках отчетности о переходах между состояниями. В таком случае источник должен помнить, какие отчеты он отправлял, а также хранить данные для восстановления при отработке отказа.

Эти четыре параметра (SourceId, Entity Identifier, Property и HealthState) являются обязательными для всех отчетов. Строка с идентификатором источника (SourceId) не может начинаться с префиксаSystem.— он зарезервирован для системных отчетов. Для одной и той же сущности может быть создан только один отчет с указанием одних и тех же источника и свойства. Если для одних и тех же источника и свойства создаются несколько отчетов, один из них переопределит остальные либо на стороне клиента работоспособности (при объединении в пакет), либо на стороне хранилища данных о работоспособности. Замена выполняется на основе порядкового номера: старые отчеты заменяются новыми (с большим порядковым номером).

События работоспособности

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

Добавляемые метаданные:

SourceUtcTimestamp. Время передачи отчета клиенту работоспособности (в формате UTC).
LastModifiedUtcTimestamp. Время последнего изменения отчета на стороне сервера (UTC).
IsExpired. Флаг, указывающий, истек ли срок действия отчета в момент выполнения запроса хранилищем данных о работоспособности. Срок действия события может истечь, только если флаг RemoveWhenExpired имеет значение False. В противном случае событие не возвращается запросом и удаляется из хранилища.
LastOkTransitionAt, LastWarningTransitionAt, LastErrorTransitionAt. Время последнего перехода между состояниями ОК, Warning или Error. Эти поля содержат историю переходов события из одного состояния работоспособности в другое.

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

Генерирование предупреждения, если свойство находится в состоянии Warning или Error более X минут. Проверка условия за некоторый период позволяет избежать появления предупреждений о временных проблемах. Например, если состояние Warning сохраняется более пяти минут, предупреждение может быть таким: (HealthState == Warning and Now - LastWarningTransitionTime > 5 minutes).
Генерирование предупреждений, связанных с условиями, которые изменились за последние X минут. Если состояние Error включено в отчет раньше, чем X минут назад, его можно проигнорировать (так как этот сигнал уже был получен).
Если состояние свойства меняется с "Warning" на "Error" и обратно, можно определить, как долго сохраняется неработоспособность (т. е. состояние, отличное от "ОК"). Например, если свойство является неработоспособным более пяти минут, предупреждение может быть таким: (HealthState != Ok and Now - LastOkTransitionTime > 5 minutes).

Пример: отправка отчетов и оценка работоспособности приложения

В приведенном ниже фрагменте отправляется отчет о работоспособности приложения fabric:/WordCount из источника MyWatchdog с помощью PowerShell. Отчет содержит сведения по свойству Availability: состояние работоспособности — Error, срок жизни TimeToLive — не ограничен. Затем выполняется запрос работоспособности приложения, который возвращает сводное состояние Error и рассматриваемое событие работоспособности в списке других событий работоспособности.

PS C:\> Send-ServiceFabricApplicationHealthReport –ApplicationName fabric:/WordCount –SourceId "MyWatchdog" –HealthProperty "Availability" –HealthState Error

PS C:\> Get-ServiceFabricApplicationHealth fabric:/WordCount -ExcludeHealthStatistics


ApplicationName                 : fabric:/WordCount
AggregatedHealthState           : Error
UnhealthyEvaluations            :
                                  Error event: SourceId='MyWatchdog', Property='Availability'.

ServiceHealthStates             :
                                  ServiceName           : fabric:/WordCount/WordCountService
                                  AggregatedHealthState : Error

                                  ServiceName           : fabric:/WordCount/WordCountWebService
                                  AggregatedHealthState : Ok

DeployedApplicationHealthStates :
                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_0
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_2
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_3
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_4
                                  AggregatedHealthState : Ok

                                  ApplicationName       : fabric:/WordCount
                                  NodeName              : _Node_1
                                  AggregatedHealthState : Ok

HealthEvents                    :
                                  SourceId              : System.CM
                                  Property              : State
                                  HealthState           : Ok
                                  SequenceNumber        : 360
                                  SentAt                : 3/22/2016 7:56:53 PM
                                  ReceivedAt            : 3/22/2016 7:56:53 PM
                                  TTL                   : Infinite
                                  Description           : Application has been created.
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Error->Ok = 3/22/2016 7:56:53 PM, LastWarning = 1/1/0001 12:00:00 AM

                                  SourceId              : MyWatchdog
                                  Property              : Availability
                                  HealthState           : Error
                                  SequenceNumber        : 131032204762818013
                                  SentAt                : 3/23/2016 3:27:56 PM
                                  ReceivedAt            : 3/23/2016 3:27:56 PM
                                  TTL                   : Infinite
                                  Description           :
                                  RemoveWhenExpired     : False
                                  IsExpired             : False
                                  Transitions           : Ok->Error = 3/23/2016 3:27:56 PM, LastWarning = 1/1/0001 12:00:00 AM

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

Эта модель работоспособности обеспечивает масштабирование облачных служб и базовой платформы Service Fabric, так как мониторинг и диагностика работоспособности распределены между разными мониторами в кластере. В других системах используется единая централизованная служба на уровне кластера, которая анализирует все потенциально полезные сведения, генерируемые службами. Такой подход затрудняет масштабирование, не позволяя собирать конкретные сведения для точного выявления первопричин проблем, в том числе потенциальных.

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