Adicionar relatórios de integridade personalizados do Service Fabric

2025-04-04

O Azure Service Fabric apresenta um modelo de integridade projetado para sinalizar condições de cluster e aplicativo não íntegros em entidades específicas. O modelo de saúde utiliza repórteres de saúde (componentes do sistema e watchdogs). O objetivo é um diagnóstico e reparação fácil e rápido. Os redatores de serviços precisam pensar antecipadamente sobre saúde. Qualquer condição que possa afetar a saúde deve ser relatada, especialmente se puder ajudar a sinalizar problemas próximos à raiz. As informações de saúde podem economizar tempo e esforço na depuração e investigação. A utilidade é especialmente clara quando o serviço está instalado e em execução em escala na nuvem (privada ou Azure).

Os repórteres do Service Fabric monitoram as condições de interesse identificadas. Relatam essas condições com base na sua perspetiva local. A loja de saúde agrega dados de saúde enviados por todos os repórteres para determinar se as entidades estão saudáveis a nível global. O modelo destina-se a ser rico, flexível e fácil de usar. A qualidade dos relatórios de saúde determina a precisão da visão de saúde do cluster. Falsos positivos que indicam erroneamente problemas de saúde podem afetar negativamente as atualizações ou outros serviços que usam dados de saúde. Exemplos desses serviços são os serviços de reparação e os mecanismos de alerta. Portanto, é necessário algum pensamento para fornecer relatórios que captem as condições de interesse da melhor maneira possível.

Para conceber e implementar relatórios de saúde, os vigilantes e os componentes do sistema devem:

Defina a condição em que estão interessados, a forma como é monitorizada e o impacto na funcionalidade do cluster ou da aplicação. Com base nestas informações, decida sobre o atributo do relatório de integridade e o estado de saúde.
Determine a entidade à qual o relatório se aplica.
Determine onde o relatório é feito, se de dentro do serviço ou de um órgão de fiscalização interno ou externo.
Defina uma fonte usada para identificar o repórter.
Escolha uma estratégia de relatórios, periodicamente ou em transições. A maneira recomendada é periodicamente, pois requer um código mais simples e é menos propenso a erros.
Determine quanto tempo o relatório para condições insalubres deve permanecer no local de saúde e como ele deve ser removido. Usando essas informações, decida o tempo de vida do relatório e remova o comportamento na expiração.

Como mencionado, a comunicação de informações pode ser feita a partir de:

A réplica monitorada do serviço Service Fabric.
Monitorização interna implantada como um serviço no Service Fabric (por exemplo, um serviço sem estado no Service Fabric que efetua a monitorização de condições e emite relatórios). Os watchdogs podem ser implantados em todos os nós ou podem ser afins ao serviço monitorado.
Vigilantes internos que são executados nos nós do Service Fabric, mas não são implementados como serviços do Service Fabric.
Watchdogs externos que investigam o recurso de fora do cluster do Service Fabric (por exemplo, serviço de monitoramento como Gomez).

Observação

Logo após a instalação, o cluster é preenchido com relatórios de integridade enviados pelos componentes do sistema. Leia mais em Usando relatórios de integridade do sistema para solução de problemas. Os relatórios dos usuários devem ser enviados em entidades de saúde que já foram criadas pelo sistema.

Quando o design do relatório de saúde estiver claro, os relatórios de saúde podem ser enviados facilmente. Você pode usar FabricClient para relatar o estado de saúde se o cluster não for seguro ou se o FabricClient tiver privilégios de administrador. Os relatórios podem ser feitos por meio da API usando FabricClient.HealthManager.ReportHealth, por meio do PowerShell ou por meio de REST. Ajustes de configuração para gerar relatórios em lote e melhorar o desempenho.

Observação

A saúde do relatório é síncrona e representa apenas o trabalho de validação no lado do cliente. O facto de o relatório ser aceite pelo cliente de saúde ou pelos Partition ou CodePackageActivationContext objetos não significa que seja aplicado na loja. Ele é enviado de forma assíncrona e, possivelmente, em lote com outros relatórios. O processamento no servidor ainda pode falhar: o número de sequência pode estar obsoleto, a entidade na qual o relatório deve ser aplicado foi excluída, etc.

Cliente de saúde

Os relatórios de saúde são enviados ao gestor de saúde através de um cliente de saúde, que vive dentro do cliente de tecido. O gestor de saúde guarda os relatórios na loja de saúde. O cliente de monitorização de integridade pode ser configurado com as seguintes configurações:

HealthReportSendInterval: O atraso entre o momento em que o relatório é adicionado ao cliente e o momento em que é enviado ao gestor de saúde. Usado para agrupar relatórios em uma única mensagem, em vez de enviar uma mensagem para cada relatório. O processamento em lote melhora o desempenho. Padrão: 30 segundos.
HealthReportRetrySendInterval: O intervalo no qual o cliente de saúde reenvia relatórios de integridade acumulados para o gerente de integridade. Padrão: 30 segundos, mínimo: 1 segundo.
HealthOperationTimeout: O período de tempo limite para uma mensagem de relatório enviada ao gerente de integridade. Se uma mensagem expirar, o cliente de saúde a repetirá até que o gerente de saúde confirme que o relatório foi processado. Padrão: dois minutos.

Observação

Quando os relatórios são enviados em lote, o "fabric client" deve ser mantido ativo por pelo menos o intervalo de envio de relatórios de saúde ("HealthReportSendInterval") para garantir que sejam enviados. Se a mensagem for perdida ou o gestor de saúde não puder aplicá-las devido a erros transitórios, o cliente de malha deve ser mantido ativo por mais tempo para possibilitar uma nova tentativa.

O buffering no cliente leva em consideração a exclusividade dos relatórios. Por exemplo, se um determinado repórter incorreto estiver relatando 100 relatórios por segundo na mesma propriedade da mesma entidade, os relatórios serão substituídos pela última versão. Na fila do cliente, existe no máximo um desses relatórios. Se o processamento em lote estiver configurado, o número de relatórios enviados ao gerente de integridade será de apenas um por intervalo de envio. Este relatório é o último relatório adicionado, que reflete o estado mais atual da entidade. Especifique os parâmetros de configuração quando FabricClient for criado passando FabricClientSettings com os valores desejados para entradas relacionadas à integridade.

O exemplo a seguir cria um cliente do Fabric e especifica que os relatórios devem ser enviados assim que forem adicionados. Em tempos limite e erros que podem ser repetidos, as repetições acontecem a cada 40 segundos.

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

Recomendamos manter as configurações padrão do cliente de malha, que são definidas HealthReportSendInterval como 30 segundos. Essa configuração garante um desempenho ideal devido ao processamento em lote. Para relatórios críticos que devem ser enviados o mais rápido possível, use HealthReportSendOptions com Immediate true na API FabricClient.HealthClient.ReportHealth . Os relatórios imediatos ignoram o intervalo de agrupamento. Use este indicador com cuidado; queremos aproveitar o processamento em lotes do cliente de saúde sempre que possível. O envio imediato também é útil quando o cliente de malha está fechando (por exemplo, o processo determinou um estado inválido e precisa ser desligado para evitar efeitos colaterais). Ele garante o melhor esforço de envio dos relatórios acumulados. Quando um relatório é adicionado com o sinalizador Immediate, o cliente de integridade agrupa todos os relatórios acumulados desde o último envio.

Os mesmos parâmetros podem ser especificados quando uma conexão com um cluster é criada por meio do PowerShell. O exemplo a seguir inicia uma conexão com um cluster local:

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
                       }

Da mesma forma que a API, os relatórios podem ser enviados usando a opção -Immediate para serem enviados imediatamente, independentemente do valor HealthReportSendInterval.

Para REST, os relatórios são enviados para o gateway do Service Fabric, que tem um cliente de malha interna. Por padrão, esse cliente é configurado para enviar relatórios em lote a cada 30 segundos. Você pode alterar o intervalo de lote com a definição HttpGatewayHealthReportSendInterval de configuração do cluster em HttpGateway. Como mencionado, uma opção melhor é enviar os relatórios com Immediate true.

Observação

Para garantir que serviços não autorizados não possam relatar o estado de saúde em relação às entidades no cluster, configure o servidor para aceitar solicitações somente de clientes seguros. O FabricClient usado para relatórios deve ter a segurança habilitada para poder se comunicar com o cluster (por exemplo, com Kerberos ou autenticação de certificado). Leia mais sobre segurança de cluster.

Relatório de dentro de serviços de baixo privilégio

Se os serviços do Service Fabric não tiverem acesso de administrador ao cluster, poderá relatar o estado de saúde de entidades do contexto atual através de Partition ou CodePackageActivationContext.

Para serviços sem estado, use IStatelessServicePartition.ReportInstanceHealth para relatar a instância de serviço atual.
Para serviços com estado, use IStatefulServicePartition.ReportReplicaHealth para informar sobre a réplica atual.
Use IServicePartition.ReportPartitionHealth para relatar a entidade de partição atual.
Use CodePackageActivationContext.ReportApplicationHealth para relatar o aplicativo atual.
Use CodePackageActivationContext.ReportDeployedApplicationHealth para relatar o aplicativo atual implantado no nó atual.
Use CodePackageActivationContext.ReportDeployedServicePackageHealth para reportar sobre um pacote de serviço da aplicação implantada no nó atual.

Observação

Internamente, o Partition e o CodePackageActivationContext têm um cliente de monitorização configurado com as configurações padrão. Como explicado de acordo com o cliente de saúde, os relatórios são agrupados e enviados num determinado período de tempo. Os objetos devem ser mantidos vivos para ter a chance de enviar o relatório.

Você pode especificar HealthReportSendOptions ao enviar relatórios por meio de APIs de Partition e CodePackageActivationContext saúde. Se você tiver relatórios críticos que devem ser enviados o mais rápido possível, use HealthReportSendOptions com Immediate true. Os relatórios imediatos ignoram o intervalo de agrupamento do cliente de monitorização de integridade interno. Como mencionado anteriormente, use este sinalizador com cuidado. Queremos aproveitar a aglomeração do cliente do serviço de saúde sempre que possível.

Relatórios de saúde do design

O primeiro passo para gerar relatórios de alta qualidade é identificar as condições que podem impactar a saúde do serviço. Qualquer condição que possa ajudar a sinalizar problemas no serviço ou cluster quando ele é iniciado - ou ainda melhor, antes que um problema aconteça - pode economizar bilhões de dólares. Os benefícios incluem menos tempo de inatividade, menos horas noturnas gastas investigando e reparando problemas e maior satisfação do cliente.

Uma vez que as condições são identificadas, os escritores de monitorização precisam descobrir a melhor maneira de monitorizá-las, procurando um equilíbrio entre a sobrecarga de trabalho e a utilidade. Por exemplo, considere um serviço que faz cálculos complexos que usam alguns arquivos temporários em um compartilhamento. Um órgão de fiscalização poderia monitorar o compartilhamento para garantir que haja espaço suficiente disponível. Ele poderia ouvir notificações de alterações de arquivos ou diretórios. Ele pode relatar um aviso se um limite inicial for atingido e relatar um erro se a partição estiver cheia. Após um aviso, um sistema de reparação pode começar a limpar os arquivos mais antigos na pasta partilhada. Em caso de erro, um sistema de reparação pode mover a réplica de serviço para outro nó. Observe como os estados de condição são descritos em termos de saúde: o estado da condição que pode ser considerada saudável (ok) ou não saudável (aviso ou erro).

Uma vez que os detalhes de monitorização são definidos, um responsável pelo watchdog precisa descobrir como implementar o watchdog. Se as condições puderem ser determinadas a partir do serviço, o cão de guarda pode fazer parte do próprio serviço monitorizado. Por exemplo, o código de serviço pode verificar o uso do compartilhamento e, em seguida, relatar toda vez que tentar gravar um arquivo. A vantagem dessa abordagem é que a geração de relatórios é simples. Deve-se tomar cuidado para evitar que bugs de vigilância afetem a funcionalidade do serviço.

A geração de relatórios a partir do serviço monitorado nem sempre é uma opção. Um monitor ou controlador dentro do serviço pode não ser capaz de detetar as condições. Pode não ter a lógica ou os dados para fazer a determinação. A sobrecarga de monitoramento das condições pode ser alta. As condições também podem não ser específicas de um serviço, mas afetar as interações entre serviços. Outra opção é ter processos de monitorização no cluster como processos separados. Os vigilantes monitorizam as condições e reportam, sem afetar de forma alguma os principais serviços. Por exemplo, esses watchdogs podem ser implementados como serviços sem estado no mesmo aplicativo, implantados em todos os nós ou nos mesmos nós que o serviço.

Às vezes, um cão de guarda rodando no cluster também não é uma opção. Se a condição monitorada for a disponibilidade ou funcionalidade do serviço como os usuários o veem, é melhor ter os vigilantes no mesmo lugar que os clientes do usuário. Lá, eles podem testar as operações da mesma forma que os usuários as chamam. Por exemplo, você pode ter um cão de guarda que vive fora do cluster, emite solicitações para o serviço e verifica a latência e a correção do resultado. (Para um serviço de calculadora, por exemplo, 2+2 retorna 4 em um período razoável de tempo?)

Uma vez que os detalhes do supervisor tenham sido finalizados, deves decidir um identificador de origem que o identifique de forma exclusiva. Se vários vigilantes do mesmo tipo estiverem a operar no cluster, devem monitorizar diferentes entidades ou, se monitorizarem a mesma entidade, usar uma ID de origem ou uma propriedade diferente. Desta forma, os seus relatórios podem coexistir. A propriedade do relatório de saúde deve capturar a condição monitorada. (Para o exemplo acima, a propriedade pode ser ShareSize.) Se vários relatórios se aplicarem à mesma condição, a propriedade deverá conter algumas informações dinâmicas que permitam a coexistência de relatórios. Por exemplo, se vários compartilhamentos precisarem ser monitorados, o nome da propriedade poderá ser ShareSize-sharename.

Observação

Não use a loja de saúde para manter informações de estado. Apenas informações relacionadas à saúde devem ser reportadas como saúde, pois essas informações impactam na avaliação de saúde de uma entidade. A loja de saúde não foi projetada como uma loja de uso geral. Ele utiliza a lógica de avaliação de saúde para agregar todos os dados no estado de saúde. O envio de informações não relacionadas à saúde (como relatar um estado de saúde como OK) não afeta o estado de saúde agregado, mas pode afetar negativamente o desempenho da loja de saúde.

O próximo ponto de decisão é sobre qual entidade reportar. Na maioria das vezes, a condição identifica claramente a entidade. Escolha a entidade com a melhor granularidade possível. Se uma condição afetar todas as réplicas em uma partição, informe sobre a partição, não sobre o serviço. No entanto, há casos raros em que é necessária mais reflexão. Se a condição afetar uma entidade, como uma réplica, mas o desejo for ter a condição sinalizada por mais do que a duração da vida útil da réplica, ela deve ser relatada na partição. Caso contrário, quando a réplica é excluída, o repositório de integridade limpa todos os seus relatórios. Os redatores do watchdog devem pensar sobre a vida útil da entidade e do relatório. Deve ficar claro quando um relatório deve ser removido da loja (por exemplo, quando um erro relatado sobre uma entidade já não é relevante).

Vejamos um exemplo que reúne os pontos que descrevi. Considere uma aplicação do Service Fabric composta por um serviço persistente com estado primário e serviços sem estado secundário implantados em todos os nós (um tipo de serviço secundário para cada tipo de tarefa). O mestre tem uma fila de processamento que contém comandos a serem executados por secundários. Os secundários executam as solicitações recebidas e enviam sinais de confirmação. Uma condição que pode ser monitorada é o comprimento da fila de processamento mestre. Se o comprimento da fila mestra atingir um limite, um aviso será emitido. O aviso indica que os secundários não conseguem lidar com a carga. Se a fila atingir o comprimento máximo e os comandos forem descartados, um erro será relatado, pois o serviço não poderá recuperar-se. Os relatórios podem estar na propriedade QueueStatus. O cão de guarda vive dentro do serviço e é enviado periodicamente na réplica principal principal. O tempo de vida é de dois minutos e é enviado periodicamente a cada 30 segundos. Se o servidor primário ficar inativo, o relatório será removido automaticamente do armazenamento. Se a réplica do serviço estiver ativada, mas estiver bloqueada ou com outros problemas, o relatório expirará no repositório de integridade. Neste caso, a entidade é avaliada com erro.

Outra condição que pode ser monitorada é o tempo de execução da tarefa. O mestre distribui tarefas para os secundários com base no tipo de tarefa. Dependendo do design, o mestre pode sondar os secundários para obter o status da tarefa. Também pode esperar que os secundários enviem sinais de confirmação quando terminarem. No segundo caso, deve-se ter cuidado em detetar situações em que os sistemas secundários falham ou as mensagens se perdem. Uma opção é que o mestre envie uma solicitação de ping para o mesmo secundário, que envia de volta seu status. Se nenhum status for recebido, o mestre considerará uma falha e reagendará a tarefa. Esse comportamento pressupõe que as tarefas são idempotentes.

A condição monitorada pode ser traduzida como um aviso se a tarefa não for feita em um determinado tempo (t1, por exemplo, 10 minutos). Se a tarefa não for concluída a tempo (t2, por exemplo, 20 minutos), a condição monitorada pode ser traduzida como Erro. Esses relatórios podem ser feitos de várias maneiras:

A réplica mestre primária faz relatórios sobre si mesma periodicamente. Você pode ter uma única propriedade para todas as tarefas pendentes na fila. Se pelo menos uma tarefa demorar mais, o status do relatório na propriedade PendingTasks será um aviso ou erro, conforme apropriado. Se não houver tarefas pendentes ou todas as tarefas iniciadas na execução, o status do relatório será OK. As tarefas são persistentes. Se o primário falhar, o primário recém-promovido poderá continuar a funcionar corretamente.
Outro processo de vigilância (na nuvem ou externa) verifica as tarefas (de fora, com base no resultado desejado) para ver se elas foram concluídas. Se eles não respeitarem os limites, um relatório será enviado através do serviço principal. Um relatório também é enviado em cada tarefa que inclui o identificador da tarefa, como PendingTask+taskId. Os relatórios devem ser enviados apenas em estados não íntegros. Defina o tempo de vida para alguns minutos e marque os relatórios a serem removidos quando expirarem para garantir a limpeza.
O sistema secundário que está a executar uma tarefa relata quando esta demora mais tempo do que o esperado. Ele informa sobre a instância de serviço na propriedade PendingTasks. O relatório identifica a instância de serviço que tem problemas, mas não captura a situação em que a instância morre. Os relatórios são então revistos. Poderia fazer um relatório sobre o serviço secundário. Se o secundário concluir a tarefa, a instância secundária limpará o relatório da armazenagem. O relatório não captura a situação em que a mensagem de confirmação é perdida e a tarefa não é concluída do ponto de vista do mestre.

No entanto, quando a notificação é feita nos casos descritos acima, os relatórios são capturados no estado de saúde da aplicação quando a saúde é medida.

Relatórios periódicos vs. sobre a transição

Usando o modelo de relatório de saúde do sistema, os monitores podem enviar relatórios periodicamente ou durante transições. A maneira recomendada para relatórios de vigilância é periodicamente, porque o código é muito mais simples e menos propenso a erros. Os vigilantes devem se esforçar para ser o mais simples possível para evitar bugs que desencadeiam relatórios incorretos. Relatórios não saudáveis incorretos afetam as avaliações de saúde e os cenários baseados na saúde, incluindo melhoramentos. Relatórios saudáveis incorretos ocultam problemas no cluster, o que é indesejável.

Para relatórios periódicos, o watchdog pode ser implementado com um temporizador. Num retorno de chamada de temporizador, o watchdog pode verificar o estado e enviar um relatório com base no estado atual. Não há necessidade de ver qual relatório foi enviado anteriormente ou fazer otimizações em termos de mensagens. A aplicação de saúde possui uma lógica de agrupamento para melhorar o desempenho. Enquanto o cliente de monitorização é mantido vivo, ele tenta novamente internamente até que o relatório seja reconhecido pelo repositório de saúde ou o monitor de sistema gere um relatório mais recente com a mesma entidade, propriedade e fonte.

A elaboração de relatórios sobre transições requer um tratamento cuidadoso do estado. O órgão de fiscalização monitora algumas condições e informa apenas quando as condições mudam. A vantagem desta abordagem é que são necessários menos relatórios. A desvantagem é que a lógica do sistema de monitorização é complexa. O órgão de fiscalização deve manter as condições ou os relatórios, para que possam ser inspecionados para determinar mudanças de estado. Durante o failover, deve-se tomar cuidado com os relatórios adicionados, mas ainda não enviados para o registo de saúde. O número sequencial deve ser cada vez maior. Caso contrário, os relatórios são rejeitados como obsoletos. Nos raros casos em que ocorre perda de dados, a sincronização pode ser necessária entre o estado do repórter e o estado do repositório de integridade.

A elaboração de relatórios sobre transições faz sentido para os serviços que se reportam a si próprios, através Partition ou CodePackageActivationContext. Quando o objeto local (réplica ou pacote de serviço implantado/aplicativo implantado) é removido, todos os seus relatórios também são removidos. Esta limpeza automática reduz a necessidade de sincronização entre a aplicação de reporte e o sistema de gestão de saúde. Se o relatório for para partição pai ou aplicativo pai, deve-se ter cuidado durante o failover para evitar relatórios obsoletos no armazenamento de saúde. A lógica deve ser adicionada para manter o estado correto e remover o relatório do armazenamento quando não for mais necessário.

Implementar relatórios de saúde

Quando os detalhes da entidade e do relatório estiverem claros, o envio de relatórios de saúde poderá ser feito por meio da API, PowerShell ou REST.

API (Interface de Programação de Aplicações)

Para gerar relatórios por meio da API, você precisa criar um relatório de integridade específico para o tipo de entidade sobre o qual eles desejam relatar. Entregue o relatório a um cliente de saúde. Como alternativa, crie uma informação de saúde e passe-a para métodos de relatório corretos em Partition ou CodePackageActivationContext para reportar sobre as entidades atuais.

O exemplo a seguir mostra relatórios periódicos de um watchdog dentro do cluster. O monitor verifica se um recurso externo pode ser acedido de dentro de um nó. O recurso é necessário para um manifesto de serviço dentro do aplicativo. Se o recurso não estiver disponível, os outros serviços dentro do aplicativo ainda podem funcionar corretamente. Portanto, o relatório é enviado na entidade do pacote de serviço implantado a cada 30 segundos.

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

Envie relatórios de saúde com Send-ServiceFabricEntityTypeHealthReport.

O exemplo a seguir mostra relatórios periódicos sobre valores de CPU em um nó. Os relatórios devem ser enviados a cada 30 segundos, e eles têm um tempo de vida de dois minutos. Se eles expirarem, o repórter tem problemas, então o nó é avaliado com erro. Quando o processador está acima de um limite, o relatório tem um estado de saúde de alerta. Quando a CPU permanece acima de um limite por mais do que o tempo configurado, isso é relatado como um erro. Caso contrário, o relator envia um estado de saúde como OK.

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

O exemplo a seguir relata um aviso transitório em uma réplica. Primeiro, ele obtém o ID da partição e, em seguida, o ID da réplica para o serviço em que está interessado. Em seguida, ele envia um relatório do PowershellWatcher sobre a propriedade ResourceDependency. O relatório é interessante por apenas dois minutos e é removido da loja automaticamente.

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

DESCANSO

Envie relatórios de integridade usando REST com solicitações POST que vão para a entidade desejada e têm no corpo a descrição do relatório de integridade. Por exemplo, veja como enviar relatórios de integridade do cluster REST ou relatórios de integridade do serviço. Todas as entidades são suportadas.

Próximos passos

Com base nos dados de saúde, os redatores de serviços e os administradores de clusters/aplicações podem pensar em maneiras de consumir as informações. Por exemplo, eles podem configurar alertas com base no status de saúde para detetar problemas graves antes que eles provoquem interrupções. Os administradores também podem configurar sistemas de reparo para corrigir problemas automaticamente.

Introdução ao monitoramento da integridade do Service Fabric

Ver relatórios de integridade do Service Fabric

Como reportar e verificar a integridade do serviço

Usar relatórios de integridade do sistema para solução de problemas

Monitorar e diagnosticar serviços localmente

Atualização do aplicativo Service Fabric