Adicionar relatórios personalizados de estado de funcionamento do Service Fabric
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 integridade 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. Comunicam essas condições com base na sua visão local. O armazenamento de saúde agrega dados de saúde enviados por todos os repórteres para determinar se as entidades estão globalmente saudáveis. O modelo destina-se a ser rico, flexível e fácil de usar. A qualidade dos relatórios de integridade determina a precisão da exibição de integridade do cluster. Falsos positivos que mostram erroneamente problemas não íntegros podem afetar negativamente atualizações ou outros serviços que usam dados de integridade. 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 nessas informações, decida sobre a propriedade do relatório de integridade e o estado de saúde.
- Determine a entidade à qual o relatório se aplica.
- Determine onde a denúncia é feita, de dentro do serviço ou de um cão de guarda 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 armazenamento de saúde e como ele deve ser liberado. 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 de serviço do Service Fabric monitorada.
- Vigilantes internos implantados como um serviço do Service Fabric (por exemplo, um serviço sem estado do Service Fabric que monitora 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).
Nota
Pronto para uso, 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 integridade estiver claro, os relatórios de integridade podem ser enviados facilmente. Você pode usar FabricClient para relatar a integridade se o cluster não for seguro ou se o cliente de malha 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. Botões de configuração relatórios em lote para melhorar o desempenho.
Nota
A integridade do relatório é síncrona e representa apenas o trabalho de validação no lado do cliente. O fato de o relatório ser aceito pelo cliente de saúde ou pelos Partition objetos não CodePackageActivationContext significa que ele 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 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.
Nota
Quando os relatórios são enviados em lote, o cliente de malha deve ser mantido ativo pelo menos durante o HealthReportSendInterval para garantir que eles sejam enviados. Se a mensagem for perdida ou o gerente de integridade não puder aplicá-las devido a erros transitórios, o cliente de malha deve ser mantido ativo por mais tempo para dar a chance de tentar novamente.
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. No máximo, um desses relatórios existe na fila do cliente. 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 de malha e especifica que os relatórios devem ser enviados quando 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 lotes. Use esta bandeira com cuidado; Queremos aproveitar o lote 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 -Immediate switch para serem enviados imediatamente, independentemente do HealthReportSendInterval valor.
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.
Nota
Para garantir que serviços não autorizados não possam relatar a integridade em relação às entidades no cluster, configure o servidor para aceitar solicitações somente de clientes protegidos. 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, você poderá relatar a integridade de entidades do contexto atual até Partition ou CodePackageActivationContext.
- Para serviços sem estado, use IStatelessServicePartition.ReportInstanceHealth para relatar a instância de serviço atual.
- Para serviços com monitoração de estado, use IStatefulServicePartition.ReportReplicaHealth para relatar 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 relatar um pacote de serviço para o aplicativo implantado no nó atual.
Nota
Internamente, o Partition e o CodePackageActivationContext hold um cliente de integridade configurado com as configurações padrão. Como explicado para o cliente de saúde, os relatórios são agrupados e enviados em um temporizador. 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 Partition APIs de CodePackageActivationContext integridade. 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 lote do cliente de integridade interno. Como mencionado anteriormente, use esta bandeira com cuidado; Queremos aproveitar o lote do cliente de saúde sempre que possível.
Relatórios de integridade do projeto
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 vigilância precisam descobrir a melhor maneira de monitorá-las para o equilíbrio entre sobrecarga e 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 o compartilhamento estiver cheio. Em um aviso, um sistema de reparo pode começar a limpar arquivos mais antigos no compartilhamento. Em caso de erro, um sistema de reparo 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 monitoramento são definidos, um escritor de cão de guarda precisa descobrir como implementar o cão de guarda. 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 cão de guarda 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 watchdogs 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 cão de guarda tenham sido finalizados, você deve decidir sobre um ID de origem que o identifique exclusivamente. Se vários watchdogs do mesmo tipo estiverem vivendo no cluster, eles deverão relatar entidades diferentes ou, se relatarem sobre a mesma entidade, usar ID de origem ou propriedade diferente. Desta forma, os seus relatórios podem coexistir. A propriedade do relatório de integridade 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.
Nota
Não use o armazenamento de integridade para manter informações de status. 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 usa a lógica de avaliação de integridade para agregar todos os dados no estado de saúde. O envio de informações não relacionadas à integridade (como relatar o status com um estado de integridade OK) não afeta o estado de integridade agregado, mas pode afetar negativamente o desempenho do repositório de integridade.
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 esquinos 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 armazenamento 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 limpo de uma loja (por exemplo, quando um erro relatado em uma entidade não se aplica mais).
Vejamos um exemplo que reúne os pontos que descrevi. Considere um aplicativo do Service Fabric composto por um serviço persistente com monitoração de estado mestre e serviços sem estado secundários 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á relatado. 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á se recuperar. 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 primário ficar inativo, o relatório será limpo automaticamente da loja. 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 o cuidado de detetar situações em que secundárias morrem ou mensagens são perdidas. 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 principal principal relata sobre si mesma periodicamente. Você pode ter uma 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 cair, o primário recém-promovido poderá continuar a relatar 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 no serviço mestre. 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 secundário que está executando uma tarefa relata quando leva mais tempo do que o esperado para executá-la. Ele relata 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 limpos. Poderia informar sobre o serviço secundário. Se o secundário concluir a tarefa, a instância secundária limpará o relatório do armazenamento. 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, a notificação é feita nos casos descritos acima, os relatórios são capturados na integridade do aplicativo quando a saúde é avaliada.
Relatórios periódicos vs. sobre a transição
Usando o modelo de relatório de integridade, os vigilantes podem enviar relatórios periodicamente ou sobre 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 íntegros incorretos afetam as avaliações de integridade e os cenários baseados na integridade, incluindo atualizações. Relatórios de integridade incorretos ocultam problemas no cluster, o que não é desejado.
Para relatórios periódicos, o cão de guarda pode ser implementado com um temporizador. Em um retorno de chamada de temporizador, o cão de guarda 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. O cliente de saúde tem lógica de lote para ajudar no desempenho. Enquanto o cliente de saúde é mantido vivo, ele tenta novamente internamente até que o relatório seja reconhecido pelo armazenamento de saúde ou o cão de guarda 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 cão de guarda é 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. No failover, deve-se tomar cuidado com relatórios adicionados, mas ainda não enviados para o armazenamento 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 a perda de dados é incorrida, a sincronização pode ser necessária entre o estado do repórter e o estado do armazenamento 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. Essa limpeza automática relaxa a necessidade de sincronização entre o repórter e o armazenamento de saúde. Se o relatório for para partição pai ou aplicativo pai, deve-se tomar cuidado com o failover para evitar relatórios obsoletos no repositório de integridade. A lógica deve ser adicionada para manter o estado correto e limpar o relatório do armazenamento quando não for mais necessário.
Implementar relatórios de integridade
Quando os detalhes da entidade e do relatório estiverem claros, o envio de relatórios de integridade poderá ser feito por meio da API, PowerShell ou REST.
API
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 integridade e passe-a para métodos de relatório corretos ou Partition CodePackageActivationContext para relatar entidades atuais.
O exemplo a seguir mostra relatórios periódicos de um cão de guarda dentro do cluster. O cão de guarda verifica se um recurso externo pode ser acessado 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 integridade com o 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 a CPU está acima de um limite, o relatório tem um estado de alerta de integridade. Quando a CPU permanece acima de um limite por mais do que o tempo configurado, isso é relatado como um erro. Caso contrário, o repórter envia um estado de integridade de 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
REST
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 integridade, os criadores de serviços e os administradores de cluster/aplicativos 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
Exibir relatórios de integridade do Service Fabric
Como relatar e verificar a integridade do serviço
Usar relatórios de integridade do sistema para solução de problemas