Добавление пользовательских отчетов о работоспособности Service Fabric

Статья
2025-04-08

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

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

Для проектирования и внедрения отчетов о состоянии системы контрольные компоненты и системные компоненты должны:

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

Как уже упоминалось, отчеты можно предоставить с помощью:

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

Примечание.

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

После ясного проектирования отчетов о работоспособности можно легко отправлять отчеты о работоспособности. Вы можете использовать FabricClient, чтобы сообщить о состоянии, если кластер не защищен или если fabric client имеет права администратора. Отчеты можно выполнять через API с помощью FabricClient.HealthManager.ReportHealth, с помощью PowerShell или REST. Пакетные отчеты конфигурации для повышения производительности.

Примечание.

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

Клиент работоспособности

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

HealthReportSendInterval: задержка между временем добавления отчета в систему клиента и временем отправки менеджеру работоспособности. Используется для пакетных отчетов в одно сообщение, а не для отправки одного сообщения для каждого отчета. Пакетная обработка повышает производительность. Значение по умолчанию: 30 секунд.
HealthReportRetrySendInterval: интервал, с которым клиент работоспособности повторно отправляет отчеты о работоспособности диспетчеру работоспособности. Значение по умолчанию: 30 секунд, минимальное: 1 секунда.
HealthOperationTimeout: период ожидания сообщения о состоянии, отправленного диспетчеру работоспособности. Если истекает время ожидания для сообщения, клиент работоспособности производит повторную попытку, пока диспетчер работоспособности не подтвердит, что отчет был обработан. Значение по умолчанию: две минуты.

Примечание.

Когда отчеты объединяются в пакеты, клиент Fabric должен оставаться активным по крайней мере в течение времени, указанного в интервале отправки отчетов о состоянии, чтобы обеспечить их отправку. Если сообщение потеряно или диспетчер работоспособности не может применить их из-за временных ошибок, клиент fabric должен оставаться активным дольше, чтобы дать ему возможность повторить попытку.

Буферизация клиента учитывает уникальность отчетов. Например, если конкретный плохой репортер сообщает 100 отчетов в секунду на то же свойство той же сущности, отчеты заменяются последней версией. В очереди клиента может быть не более одного такого отчёта. Если пакетная обработка настроена, количество отчетов, отправляемых менеджеру работоспособности, ограничивается одним за каждый интервал отправки. Этот отчет является последним добавленным отчетом, который отражает самое текущее состояние сущности. Укажите параметры конфигурации при FabricClient создании путем передачи FabricClientSettings с требуемыми значениями для записей о работоспособности.

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

var clientSettings = new FabricClientSettings()
{
    HealthOperationTimeout = TimeSpan.FromSeconds(120),
    HealthReportSendInterval = TimeSpan.FromSeconds(0),
    HealthReportRetrySendInterval = TimeSpan.FromSeconds(40),
};
var fabricClient = new FabricClient(clientSettings);

Рекомендуется сохранить параметры клиента Fabric по умолчанию, задающие значение HealthReportSendInterval в 30 секунд. Этот параметр обеспечивает оптимальную производительность из-за пакетной обработки. Для критически важных отчетов, которые должны быть отправлены как можно скорее, используйте HealthReportSendOptions с Immediate true в FabricClient.HealthClient.ReportHealth API. Немедленные отчеты обходят интервал пакетной обработки. Используйте этот флаг с осторожностью; мы хотим по возможности воспользоваться пакетной обработкой запросов здоровья клиента. Немедленная отправка также полезна при закрытии клиента Fabric (например, процесс определил неверное состояние и должен завершить работу, чтобы избежать побочных эффектов). Это обеспечивает оптимальную отправку накопленных отчетов. При добавлении отчета с флагом немедленной обработки клиент системы мониторинга пакетирует все накопленные отчеты с момента последней отправки.

Те же параметры можно указать при создании подключения к кластеру с помощью PowerShell. В следующем примере запускается подключение к локальному кластеру:

PS C:\> Connect-ServiceFabricCluster -HealthOperationTimeoutInSec 120 -HealthReportSendIntervalInSec 0 -HealthReportRetrySendIntervalInSec 40
True

ConnectionEndpoint   :
FabricClientSettings : {
                       ClientFriendlyName                   : PowerShell-1944858a-4c6d-465f-89c7-9021c12ac0bb
                       PartitionLocationCacheLimit          : 100000
                       PartitionLocationCacheBucketCount    : 1024
                       ServiceChangePollInterval            : 00:02:00
                       ConnectionInitializationTimeout      : 00:00:02
                       KeepAliveInterval                    : 00:00:20
                       HealthOperationTimeout               : 00:02:00
                       HealthReportSendInterval             : 00:00:00
                       HealthReportRetrySendInterval        : 00:00:40
                       NotificationGatewayConnectionTimeout : 00:00:00
                       NotificationCacheUpdateTimeout       : 00:00:00
                       }
GatewayInformation   : {
                       NodeAddress                          : localhost:19000
                       NodeId                               : 1880ec88a3187766a6da323399721f53
                       NodeInstanceId                       : 130729063464981219
                       NodeName                             : Node.1
                       }

Аналогично API, отчеты можно отправлять при помощи переключателя -Immediate, который отправляется немедленно, независимо от значения параметра HealthReportSendInterval.

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

Примечание.

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

Отчет из служб с низким уровнем привилегий

Если у служб Service Fabric нет доступа администратора к кластеру, можно отчитаться о состоянии сущностей из текущего контекста через Partition или CodePackageActivationContext.

Для служб без отслеживания состояния используйте IStatlessServicePartition.ReportInstanceHealth , чтобы сообщить о текущем экземпляре службы.
Для служб с отслеживанием состояния используйте IStatefulServicePartition.ReportReplicaHealth, чтобы сообщить о текущей реплике.
Используйте IServicePartition.ReportPartitionHealth, чтобы сообщить о текущей сущности раздела.
Используйте CodePackageActivationContext.ReportApplicationHealth , чтобы сообщить о текущем приложении.
Используйте CodePackageActivationContext.ReportDeployedApplicationHealth , чтобы сообщить о текущем приложении, развернутом на текущем узле.
Используйте CodePackageActivationContext.ReportDeployedServicePackageHealth , чтобы сообщить о пакете службы для приложения, развернутого на текущем узле.

Примечание.

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

Вы можете указать HealthReportSendOptions при отправке отчетов через Partition и CodePackageActivationContext API здоровья. Если у вас есть критически важные отчеты, которые должны быть отправлены как можно скорее, используйте HealthReportSendOptions с функцией Немедленно true. Немедленные отчеты обходят интервал пакетной обработки внутреннего клиента работоспособности. Как упоминалось ранее, используйте этот флаг с осторожностью; мы хотим воспользоваться упорядоченной обработкой системного клиента при любой возможности.

Проектирование отчетов о состоянии здоровья

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

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

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

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

Иногда наблюдатель, работающий в кластере, не является вариантом. Если отслеживаемое условие является доступностью или функциональностью службы, как пользователи видят ее, лучше иметь контрольные группы в том же месте, что и клиенты пользователей. Там они могут протестировать операции таким же образом, как пользователи вызывают их. Например, у вас может быть наблюдатель, который находится за пределами кластера, выдает запросы к службе и проверяет задержку и правильность результата. (Например, для службы калькулятора 2+2 возвращает 4 за разумное время?)

Завершив подготовку сведений о наблюдателях, необходимо выбрать исходный идентификатор, который однозначно идентифицирует его. Если несколько контрольных групп одного типа находятся в кластере, они должны сообщать о разных сущностях или, если они сообщают об одной сущности, используйте другой исходный идентификатор или свойство. Таким образом, их отчеты могут сосуществовать. Свойство отчета о состоянии здоровья должно фиксировать мониторинг состояния. (В приведенном выше примере свойство может быть ShareSize.) Если несколько отчетов применяются к одному условию, свойство должно содержать некоторую динамическую информацию, которая позволяет отчетам сосуществовать. Например, если необходимо отслеживать несколько общих папок, имя свойства может быть shareSize-sharename.

Примечание.

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

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

Давайте рассмотрим пример, который объединяет точки, которые я описал. Рассмотрим приложение Service Fabric, состоящее из основной постоянной службы с отслеживанием состояния и дополнительных служб без отслеживания состояния, развернутых на всех узлах (один вторичный тип службы для каждого типа задачи). Мастер имеет очередь обработки, содержащую команды, которые будут выполняться вторичными узлами. Вторичные файлы выполняют входящие запросы и отправляют сигналы обратного подтверждения. Одним из условий, которые можно отслеживать, является длина основной очереди обработки. Если длина главной очереди достигает порогового значения, сообщается предупреждение. Предупреждение указывает, что вторичные файлы не могут обрабатывать нагрузку. Если очередь достигает максимальной длины и команды удаляются, сообщается об ошибке, так как служба не может восстановиться. Отчеты могут находиться в свойстве QueueStatus. Наблюдатель живет внутри службы, и он периодически отправляется на главную первичную реплику. Время жизни составляет две минуты. Оно отправляется периодически каждые 30 секунд. Если основной сервер выходит из строя, отчет автоматически очищается из хранилища данных. Если реплика службы включена, но она заблокирована или имеет другие проблемы, отчет истекает в хранилище работоспособности. В этом случае сущность вычисляется по ошибке.

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

Отслеживаемое условие можно перевести как предупреждение, если задача не выполняется в определенное время (например, 10 минут). Если задача не завершена в течение времени (t2, например 20 минут), отслеживаемое условие может быть переведено в виде ошибки. Эти отчеты можно сделать несколькими способами:

Эталонная первичная реплика периодически сообщает о себе. Вы можете иметь одно свойство для всех ожидающих задач в очереди. Если хотя бы одна задача длится дольше, состояние отчета в свойстве PendingTasks отображается как предупреждение или ошибка, в зависимости от обстоятельств. Если нет ожидающих задач или всех запущенных задач, состояние отчета — ОК. Задачи постоянные. Если основной сервер выходит из строя, вновь назначенный основной может продолжать предоставлять отчеты должным образом.
Другой процесс наблюдения (в облаке или вне) проверяет задачи (извне на основе требуемого результата задачи), чтобы узнать, завершены ли они. Если они не соблюдают пороговые значения, отчет отправляется в мастер-сервис. Отчет также отправляется для каждой задачи, которая включает идентификатор задачи, например PendingTask+taskId. Отчеты следует отправлять только в неисправных состояниях. Установите время жизни на несколько минут и отметьте отчёты, которые следует удалить после истечения срока, чтобы гарантировать их очистку.
Вторичный сервер сообщает о задаче, если ее выполнение занимает больше времени, чем ожидалось. Он сообщает об экземпляре службы в свойстве PendingTasks. Отчет указывает экземпляр службы, имеющий проблемы, но не фиксирует ситуацию, когда экземпляр умирает. Затем отчеты приводятся в порядок. Это может сообщить об вторичной службе. Если дополнительный экземпляр завершает задачу, вторичный экземпляр очищает отчет из хранилища. Отчет не фиксирует ситуацию, когда сообщение подтверждения потеряно, и задача не завершена с точки зрения мастера.

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

Отчеты периодически и при переходе

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

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

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

Написание отчетов о переходах имеет смысл для служб, которые отчитываются о себе, через Partition или CodePackageActivationContext. При удалении локального объекта (реплики или развернутого пакета службы или развернутого приложения) все отчеты также удаляются. Эта автоматическая очистка снижает необходимость синхронизации между репортером и хранилищем данных о состоянии. Если отчет предназначен для родительского раздела или родительского приложения, следует уделить внимание переключению на резерв, чтобы избежать появления устаревших отчетов в хранилище работоспособности. Логика должна быть добавлена для поддержания правильного состояния и удаления отчета из хранилища, когда больше не нужно.

Внедрение отчетности о состоянии здоровья

После очистки сведений о сущности и отчете отправка отчетов о работоспособности можно выполнить с помощью API, PowerShell или REST.

API (Интерфейс программирования приложений)

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

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

private static Uri ApplicationName = new Uri("fabric:/WordCount");
private static string ServiceManifestName = "WordCount.Service";
private static string NodeName = FabricRuntime.GetNodeContext().NodeName;
private static Timer ReportTimer = new Timer(new TimerCallback(SendReport), null, 30 * 1000, 30 * 1000);
private static FabricClient Client = new FabricClient(new FabricClientSettings() { HealthReportSendInterval = TimeSpan.FromSeconds(0) });

public static void SendReport(object obj)
{
    // Test whether the resource can be accessed from the node
    HealthState healthState = this.TestConnectivityToExternalResource();

    // Send report on deployed service package, as the connectivity is needed by the specific service manifest
    // and can be different on different nodes
    var deployedServicePackageHealthReport = new DeployedServicePackageHealthReport(
        ApplicationName,
        ServiceManifestName,
        NodeName,
        new HealthInformation("ExternalSourceWatcher", "Connectivity", healthState));

    // TODO: handle exception. Code omitted for snippet brevity.
    // Possible exceptions: FabricException with error codes
    // FabricHealthStaleReport (non-retryable, the report is already queued on the health client),
    // FabricHealthMaxReportsReached (retryable; user should retry with exponential delay until the report is accepted).
    Client.HealthManager.ReportHealth(deployedServicePackageHealthReport);
}

PowerShell

Отправка отчетов о работоспособности, используя Send-ServiceFabricEntityTypeHealthReport.

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

PS C:\> Send-ServiceFabricNodeHealthReport -NodeName Node.1 -HealthState Warning -SourceId PowershellWatcher -HealthProperty CPU -Description "CPU is above 80% threshold" -TimeToLiveSec 120

PS C:\> Get-ServiceFabricNodeHealth -NodeName Node.1
NodeName              : Node.1
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='CPU', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.FM
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 5
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Fabric node is up.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : CPU
                        HealthState           : Warning
                        SequenceNumber        : 130741236814913394
                        SentAt                : 4/21/2015 9:01:21 PM
                        ReceivedAt            : 4/21/2015 9:01:21 PM
                        TTL                   : 00:02:00
                        Description           : CPU is above 80% threshold
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:01:21 PM

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

PS C:\> $partitionId = (Get-ServiceFabricPartition -ServiceName fabric:/WordCount/WordCount.Service).PartitionId

PS C:\> $replicaId = (Get-ServiceFabricReplica -PartitionId $partitionId | where {$_.ReplicaRole -eq "Primary"}).ReplicaId

PS C:\> Send-ServiceFabricReplicaHealthReport -PartitionId $partitionId -ReplicaId $replicaId -HealthState Warning -SourceId PowershellWatcher -HealthProperty ResourceDependency -Description "The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes." -TimeToLiveSec 120 -RemoveWhenExpired

PS C:\> Get-ServiceFabricReplicaHealth  -PartitionId $partitionId -ReplicaOrInstanceId $replicaId


PartitionId           : 8f82daff-eb68-4fd9-b631-7a37629e08c0
ReplicaId             : 130740415594605869
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='PowershellWatcher', Property='ResourceDependency', HealthState='Warning', ConsiderWarningAsError=false.

HealthEvents          :
                        SourceId              : System.RA
                        Property              : State
                        HealthState           : Ok
                        SequenceNumber        : 130740768777734943
                        SentAt                : 4/21/2015 8:01:17 AM
                        ReceivedAt            : 4/21/2015 8:02:12 AM
                        TTL                   : Infinite
                        Description           : Replica has been created.
                        RemoveWhenExpired     : False
                        IsExpired             : False
                        Transitions           : ->Ok = 4/21/2015 8:02:12 AM

                        SourceId              : PowershellWatcher
                        Property              : ResourceDependency
                        HealthState           : Warning
                        SequenceNumber        : 130741243777723555
                        SentAt                : 4/21/2015 9:12:57 PM
                        ReceivedAt            : 4/21/2015 9:12:57 PM
                        TTL                   : 00:02:00
                        Description           : The external resource that the primary is using has been rebooted at 4/21/2015 9:01:21 PM. Expect processing delays for a few minutes.
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : ->Warning = 4/21/2015 9:12:32 PM

ОТДЫХ

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

Дальнейшие действия

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

Общие сведения о мониторинге работоспособности Service Fabric

Просмотр отчетов о состоянии Service Fabric

Как сообщить о работоспособности службы и проверить её состояние

Использование отчетов о работоспособности системы для устранения неполадок

Мониторинг и диагностика состояния служб в локальной среде разработки

Обновление приложения Service Fabric