Adicionar relatórios de estado de funcionamento personalizados do Service Fabric
O Azure Service Fabric introduz um modelo de estado de funcionamento concebido para sinalizar condições de aplicação e cluster em mau estado de funcionamento em entidades específicas. O modelo de estado de funcionamento utiliza repórteres de saúde (componentes do sistema e cães de guarda). O objetivo é o diagnóstico e reparação fáceis e rápidos. Os escritores de serviços precisam pensar antecipadamente sobre a saúde. Qualquer condição que possa afetar o estado de funcionamento deve ser reportada, especialmente se puder ajudar a sinalizar problemas próximos da raiz. As informações de estado de funcionamento podem poupar tempo e esforço na depuração e investigação. A utilidade é especialmente clara quando o serviço está em funcionamento em escala na cloud (privada ou no Azure).
Os repórteres do Service Fabric monitorizam as condições de interesse identificadas. Comunicam essas condições com base na sua vista local. O arquivo de estado de funcionamento agrega os dados de estado de funcionamento enviados por todos os repórteres para determinar se as entidades estão globalmente em bom estado de funcionamento. O modelo destina-se a ser rico, flexível e fácil de utilizar. A qualidade dos relatórios de estado de funcionamento determina a precisão da vista de estado de funcionamento do cluster. Os falsos positivos que apresentam incorretamente problemas de mau estado de funcionamento podem afetar negativamente as atualizações ou outros serviços que utilizam dados de estado de funcionamento. Exemplos desses serviços são serviços de reparação e mecanismos de alerta. Por conseguinte, alguns pensaram ser necessários para fornecer relatórios que capturem condições de interesse da melhor forma possível.
Para conceber e implementar relatórios de estado de funcionamento, os watchdogs e os componentes do sistema têm de:
- Defina a condição em que estão interessados, a forma como é monitorizado e o impacto na funcionalidade do cluster ou da aplicação. Com base nestas informações, decida sobre a propriedade do relatório de estado de funcionamento e o estado de funcionamento.
- Determine a entidade à qual o relatório se aplica.
- Determine onde o relatório é feito, a partir do serviço ou de um cão de guarda interno ou externo.
- Defina uma origem utilizada para identificar o repórter.
- Escolha uma estratégia de relatórios, periodicamente ou em transições. A forma recomendada é periodicamente, uma vez que requer código mais simples e é menos propenso a erros.
- Determine quanto tempo o relatório para condições de mau estado de funcionamento deve permanecer no arquivo de estado de funcionamento e como deve ser limpo. Com estas informações, decida o tempo de vida do relatório e o comportamento de remoção na expiração.
Conforme mencionado, os relatórios podem ser feitos a partir de:
- A réplica de serviço do Service Fabric monitorizada.
- Cães de guarda internos implementados como um serviço do Service Fabric (por exemplo, um serviço sem estado do Service Fabric que monitoriza as condições e os relatórios de problemas). Os watchdogs podem ser implementados em todos os nós ou podem ser afinizados no serviço monitorizado.
- Os watchdogs internos que são executados nos nós do Service Fabric mas não são implementados como serviços do Service Fabric.
- Cães de guarda externos que pesquisam o recurso fora do cluster do Service Fabric (por exemplo, serviço de monitorização como o Gomez).
Nota
Fora da caixa, o cluster é preenchido com relatórios de estado de funcionamento enviados pelos componentes do sistema. Leia mais em Utilizar relatórios de estado de funcionamento do sistema para resolução de problemas. Os relatórios do utilizador têm de ser enviados em entidades de estado de funcionamento que já tenham sido criadas pelo sistema.
Assim que a estrutura dos relatórios de estado de funcionamento estiver clara, os relatórios de estado de funcionamento podem ser enviados facilmente. Pode utilizar FabricClient para comunicar o estado de funcionamento se o cluster não for seguro ou se o cliente de recursos de infraestrutura tiver privilégios de administrador. Os relatórios podem ser feitos através da API com FabricClient.HealthManager.ReportHealth, através do PowerShell ou através do REST. Os botões de configuração são apresentados em lotes para melhorar o desempenho.
Nota
O estado de funcionamento do relatório é síncrono e representa apenas o trabalho de validação do lado do cliente. O facto de o relatório ser aceite pelo cliente de estado de funcionamento ou pelos Partition objetos ou CodePackageActivationContext não significa que seja aplicado no arquivo. É 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 tem de ser aplicado foi eliminada, etc.
Cliente de estado de funcionamento
Os relatórios de estado de funcionamento são enviados ao gestor de estado de funcionamento através de um cliente de estado de funcionamento, que se encontra dentro do cliente de recursos de infraestrutura. O gestor de estado de funcionamento guarda relatórios no arquivo de estado de funcionamento. O cliente de estado de funcionamento pode ser configurado com as seguintes definições:
- HealthReportSendInterval: o atraso entre a hora em que o relatório é adicionado ao cliente e a hora em que é enviado para o gestor de estado de funcionamento. Utilizado para criar relatórios em lote numa única mensagem, em vez de enviar uma mensagem para cada relatório. O batching melhora o desempenho. Predefinição: 30 segundos.
- HealthReportRetrySendInterval: o intervalo no qual o cliente de estado de funcionamento reenvia relatórios de estado de funcionamento acumulados ao gestor de estado de funcionamento. Predefinição: 30 segundos, mínimo: 1 segundo.
- HealthOperationTimeout: o período de tempo limite para uma mensagem de relatório enviada ao gestor de estado de funcionamento. Se uma mensagem exceder o limite de tempo, o cliente de estado de funcionamento volta a repeti-la até que o gestor de estado de funcionamento confirme que o relatório foi processado. Predefinição: dois minutos.
Nota
Quando os relatórios são colocados em lote, o cliente de recursos de infraestrutura tem de ser mantido ativo durante, pelo menos, o HealthReportSendInterval para garantir que são enviados. Se a mensagem for perdida ou se o gestor de estado de funcionamento não as conseguir aplicar devido a erros transitórios, o cliente de recursos de infraestrutura tem de ser mantido vivo durante mais tempo para lhe dar a oportunidade de tentar novamente.
A memória intermédia no cliente tem em consideração a exclusividade dos relatórios. Por exemplo, se um repórter incorreto em particular estiver a reportar 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 batching estiver configurado, o número de relatórios enviados para o gestor de estado de funcionamento é 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 são criados ao transmitir FabricClientSettings com os valores pretendidos para entradas relacionadas com o estado de funcionamento.
O exemplo seguinte cria um cliente de recursos de infraestrutura e especifica que os relatórios devem ser enviados quando são adicionados. Em tempos limite e erros que podem ser repetidos, as repetições ocorrem 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 que mantenha as definições de cliente de recursos de infraestrutura predefinidas, que são definidas HealthReportSendInterval como 30 segundos. Esta definição garante um desempenho ideal devido ao batching. Para relatórios críticos que têm de ser enviados o mais rapidamente possível, utilize HealthReportSendOptions com a API Immediate true in FabricClient.HealthClient.ReportHealth . Os relatórios imediatos ignoram o intervalo de criação de lotes. Utilize este sinalizador com cuidado; queremos tirar partido do batching do cliente de estado de funcionamento sempre que possível. O envio imediato também é útil quando o cliente de recursos de infraestrutura está a fechar (por exemplo, o processo determinou um estado inválido e precisa de ser encerrado para evitar efeitos colaterais). Garante um melhor envio dos relatórios acumulados. Quando um relatório é adicionado com o sinalizador Imediato, o cliente de estado de funcionamento cria um lote de todos os relatórios acumulados desde o último envio.
Os mesmos parâmetros podem ser especificados quando uma ligação a um cluster é criada através do PowerShell. O exemplo seguinte inicia uma ligação a 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 através -Immediate do comutador 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 recursos de infraestrutura internos. Por predefinição, este cliente está configurado para enviar relatórios em lote a cada 30 segundos. Pode alterar o intervalo de lote com a definição HttpGatewayHealthReportSendInterval de configuração do cluster em HttpGateway. Conforme mencionado, uma melhor opção é enviar os relatórios com Immediate verdadeiro.
Nota
Para garantir que os serviços não autorizados não conseguem comunicar o estado de funcionamento das entidades no cluster, configure o servidor para aceitar pedidos apenas de clientes protegidos. O FabricClient utilizado para relatórios tem de ter a segurança ativada para poder comunicar com o cluster (por exemplo, com Kerberos ou autenticação de certificados). Leia mais sobre a segurança do cluster.
Relatório a partir de serviços com privilégios baixos
Se os serviços do Service Fabric não tiverem acesso de administrador ao cluster, pode comunicar o estado de funcionamento das entidades a partir do contexto atual através Partition de ou CodePackageActivationContext.
- Para serviços sem estado, utilize IStatelessServicePartition.ReportInstanceHealth para reportar a instância de serviço atual.
- Para serviços com estado, utilize IStatefulServicePartition.ReportReplicaHealth para reportar a réplica atual.
- Utilize IServicePartition.ReportPartitionHealth para comunicar sobre a entidade de partição atual.
- Utilize CodePackageActivationContext.ReportApplicationHealth para comunicar sobre a aplicação atual.
- Utilize CodePackageActivationContext.ReportDeployedApplicationHealth para comunicar a aplicação atual implementada no nó atual.
- Utilize CodePackageActivationContext.ReportDeployedServicePackageHealth para reportar um pacote de serviço para a aplicação implementada no nó atual.
Nota
Internamente, e a PartitionCodePackageActivationContext suspensão de um cliente de estado de funcionamento configurado com predefinições. Conforme explicado para o cliente de estado de funcionamento, os relatórios são colocados em lotes e enviados num temporizador. Os objetos devem ser mantidos vivos para poderem enviar o relatório.
Pode especificar HealthReportSendOptions ao enviar relatórios através Partition de APIs de estado de funcionamento.CodePackageActivationContext Se tiver relatórios críticos que têm de ser enviados o mais rapidamente possível, utilize HealthReportSendOptions com Imediato true. Os relatórios imediatos ignoram o intervalo de criação de lotes do cliente de estado de funcionamento interno. Conforme mencionado anteriormente, utilize este sinalizador com cuidado; queremos tirar partido do batching do cliente de estado de funcionamento sempre que possível.
Criação de relatórios de estado de funcionamento
O primeiro passo para gerar relatórios de alta qualidade é identificar as condições que podem afetar o estado de funcionamento do serviço. Qualquer condição que possa ajudar a sinalizar problemas no serviço ou cluster quando inicia ou ainda melhor, antes de ocorrer um problema, pode potencialmente poupar milhares de milhões de dólares. Os benefícios incluem menos tempo de inatividade, menos horas nocturnas gastas a investigar e reparar problemas e uma maior satisfação dos clientes.
Assim que as condições forem identificadas, os escritores de cães de guarda precisam de descobrir a melhor forma de monitorizá-las para equilíbrio entre sobrecarga e utilidade. Por exemplo, considere um serviço que faz cálculos complexos que utilizam alguns ficheiros temporários numa partilha. Um cão de guarda pode monitorizar a partilha para garantir que existe espaço suficiente disponível. Pode escutar notificações de alterações de ficheiros ou diretórios. Pode comunicar um aviso se for atingido um limiar inicial e comunicar um erro se a partilha estiver cheia. Num aviso, um sistema de reparação pode começar a limpar ficheiros mais antigos na partilha. Num erro, um sistema de reparação pode mover a réplica de serviço para outro nó. Tenha em atenção como os estados de condição são descritos em termos de estado de funcionamento: o estado da condição que pode ser considerado em bom estado de funcionamento (ok) ou em mau estado de funcionamento (aviso ou erro).
Assim que os detalhes da monitorização estiverem definidos, um escritor de cães de guarda tem de 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 a utilização da partilha e, em seguida, comunicar sempre que tenta escrever um ficheiro. A vantagem desta abordagem é que os relatórios são simples. Tem de ter cuidado para evitar que os erros do watchdog afetem a funcionalidade do serviço.
Os relatórios a partir do serviço monitorizado nem sempre são uma opção. Um cão de guarda dentro do serviço pode não conseguir detetar as condições. Pode não ter a lógica ou os dados para fazer a determinação. A sobrecarga da monitorização das condições pode ser elevada. As condições também podem não ser específicas de um serviço, mas afetam as interações entre serviços. Outra opção é ter cães de guarda no cluster como processos separados. Os cães de guarda monitorizam as condições e o relatório, sem afetar os serviços principais de forma alguma. Por exemplo, estes watchdogs podem ser implementados como serviços sem estado na mesma aplicação, implementados em todos os nós ou nos mesmos nós que o serviço.
Por vezes, um cão de guarda em execução no cluster também não é uma opção. Se a condição monitorizada for a disponibilidade ou funcionalidade do serviço como os utilizadores a veem, é melhor ter os watchdogs no mesmo local que os clientes do utilizador. Aí, podem testar as operações da mesma forma que os utilizadores as chamam. Por exemplo, pode ter um cão de guarda fora do cluster, emitir pedidos para o serviço e verificar a latência e a correção do resultado. (Para um serviço de calculadora, por exemplo, 2+2 devolve 4 num período de tempo razoável?)
Assim que os detalhes do cão de guarda tiverem sido finalizados, deve decidir sobre um ID de origem que o identifique exclusivamente. Se vários cães de guarda do mesmo tipo estiverem a viver no cluster, têm de comunicar em entidades diferentes ou, se reportarem na mesma entidade, utilizem iD ou propriedade de origem diferente. Desta forma, os seus relatórios podem coexistir. A propriedade do relatório de estado de funcionamento deve capturar a condição monitorizada. (No exemplo acima, a propriedade pode ser ShareSize.) Se vários relatórios se aplicarem à mesma condição, a propriedade deve conter algumas informações dinâmicas que permitem que os relatórios coexistam. Por exemplo, se várias partilhas precisarem de ser monitorizadas, o nome da propriedade pode ser ShareSize-sharename.
Nota
Não utilize o arquivo de estado de funcionamento para manter as informações de estado. Apenas as informações relacionadas com o estado de funcionamento devem ser comunicadas como estado de funcionamento, uma vez que estas informações afetam a avaliação do estado de funcionamento de uma entidade. O arquivo de estado de funcionamento não foi concebido como um arquivo para fins gerais. Utiliza a lógica de avaliação do estado de funcionamento para agregar todos os dados para o estado de funcionamento. O envio de informações não relacionadas com o estado de funcionamento (como o estado de relatório com um estado de funcionamento de OK) não afeta o estado de funcionamento agregado, mas pode afetar negativamente o desempenho do arquivo de estado de funcionamento.
O próximo ponto de decisão é a entidade a comunicar. 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 numa partição, comunique na partição e não no serviço. No entanto, há casos de canto em que é necessário mais pensamento. Se a condição afetar uma entidade, como uma réplica, mas o desejo for ter a condição sinalizada durante mais do que a duração da réplica, deve ser comunicada na partição. Caso contrário, quando a réplica é eliminada, o arquivo de estado de funcionamento limpa todos os relatórios. Os escritores de watchdog devem pensar nas durações da entidade e do relatório. Tem de ser claro quando um relatório deve ser limpo de um arquivo (por exemplo, quando já não se aplica um erro comunicado numa entidade).
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 principal e serviços sem estado secundários implementados 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 os pedidos recebidos e enviam sinais de confirmação. Uma condição que pode ser monitorizada é o comprimento da fila de processamento principal. Se o comprimento da fila principal atingir um limiar, será comunicado um aviso. O aviso indica que os secundários não conseguem processar a carga. Se a fila atingir o comprimento máximo e os comandos forem ignorados, é comunicado um erro, uma vez que o serviço não consegue 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 primária principal. O tempo de vida é de dois minutos e é enviado periodicamente a cada 30 segundos. Se o principal ficar inativo, o relatório é limpo automaticamente a partir do arquivo. Se a réplica de serviço estiver ativada, mas estiver num impasse ou se tiver outros problemas, o relatório expira no arquivo de estado de funcionamento. Neste caso, a entidade é avaliada com o erro.
Outra condição que pode ser monitorizada é o tempo de execução da tarefa. O mestre distribui tarefas para os secundários com base no tipo de tarefa. Consoante a estrutura, o mestre pode consultar os secundários para obter o estado da tarefa. Também pode esperar que os secundários enviem sinais de confirmação quando terminarem. No segundo caso, tem de ter cuidado para detetar situações em que os secundários morrem ou as mensagens são perdidas. Uma opção é que o mestre envie um pedido de ping para a mesma secundária, que envia de volta o respetivo estado. Se não for recebido nenhum estado, o mestre considera-o uma falha e reagenda a tarefa. Este comportamento pressupõe que as tarefas são idempotentes.
A condição monitorizada pode ser traduzida como um aviso se a tarefa não for efetuada num determinado período de tempo (t1, por exemplo, 10 minutos). Se a tarefa não estiver concluída a tempo (t2, por exemplo, 20 minutos), a condição monitorizada pode ser traduzida como Erro. Este relatório pode ser feito de várias formas:
- A réplica primária mestra comunica sobre si mesma periodicamente. Pode ter uma propriedade para todas as tarefas pendentes na fila. Se, pelo menos, uma tarefa demorar mais tempo, o estado do relatório na propriedade PendingTasks é um aviso ou erro, conforme adequado. Se não existirem tarefas pendentes ou todas as tarefas iniciadas serem executadas, o estado do relatório será OK. As tarefas são persistentes. Se o primário ficar inativo, a primária recentemente promovida pode continuar a comunicar corretamente.
- Outro processo de watchdog (na cloud ou externo) verifica as tarefas (de fora, com base no resultado da tarefa pretendido) para ver se estão concluídas. Se não respeitarem os limiares, será enviado um relatório no serviço principal. Também é enviado um relatório em cada tarefa que inclui o identificador de tarefas, como PendingTask+taskId. Os relatórios devem ser enviados apenas em estados em mau estado de funcionamento. Defina o tempo de vida para alguns minutos e marque os relatórios para serem removidos quando expirarem para garantir a limpeza.
- O secundário que está a executar relatórios de tarefas quando demora mais tempo do que o esperado para executá-lo. Reporta 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 limpos nessa altura. Pode comunicar sobre o serviço secundário. Se o secundário concluir a tarefa, a instância secundária limpa o relatório do arquivo. 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, o relatório é feito nos casos descritos acima, os relatórios são capturados no estado de funcionamento da aplicação quando o estado de funcionamento é avaliado.
Relatório periodicamente vs. na transição
Ao utilizar o modelo de relatórios de estado de funcionamento, os watchdogs podem enviar relatórios periodicamente ou em transições. A forma recomendada para relatórios de watchdog é periodicamente, porque o código é muito mais simples e menos propenso a erros. Os cães de guarda devem esforçar-se por ser o mais simples possível para evitar erros que desencadeiem relatórios incorretos. Os relatórios em mau estado de funcionamento incorretos afetam avaliações e cenários de estado de funcionamento com base no estado de funcionamento, incluindo atualizações. Os relatórios em bom estado de funcionamento incorretos ocultam problemas no cluster, o que não é pretendido.
Para relatórios periódicos, o watchdog pode ser implementado com um temporizador. Numa chamada de retorno de temporizador, o cão de guarda pode verificar o estado e enviar um relatório com base no estado atual. Não é necessário ver que relatório foi enviado anteriormente ou fazer quaisquer otimizações em termos de mensagens. O cliente de estado de funcionamento tem lógica de criação de batches para ajudar no desempenho. Enquanto o cliente de estado de funcionamento é mantido ativo, volta a tentar internamente até que o relatório seja reconhecido pelo arquivo de estado de funcionamento ou o watchdog gere um relatório mais recente com a mesma entidade, propriedade e origem.
Os relatórios sobre transições requerem um processamento cuidadoso do estado. O cão de guarda monitoriza algumas condições e reporta apenas quando as condições mudam. O lado positivo desta abordagem é que são necessários menos relatórios. A desvantagem é que a lógica do cão de guarda é complexa. O cão de guarda tem de manter as condições ou os relatórios, para que possam ser inspecionados para determinar as alterações de estado. Na ativação pós-falha, é necessário ter cuidado com os relatórios adicionados, mas ainda não enviados para o arquivo de estado de funcionamento. O número de sequência tem de estar a aumentar cada vez mais. Caso contrário, os relatórios são rejeitados como obsoletos. Nos casos raros em que a perda de dados é incorrida, a sincronização pode ser necessária entre o estado do repórter e o estado do arquivo de estado de funcionamento.
A criação de relatórios sobre transições faz sentido para os serviços que comunicam sobre si próprios, através do Partition ou CodePackageActivationContextdo . Quando o objeto local (réplica ou pacote de serviço implementado/aplicação implementada) é removido, todos os respetivos relatórios também são removidos. Esta limpeza automática relaxa a necessidade de sincronização entre o repórter e o arquivo de estado de funcionamento. Se o relatório se destinar à partição principal ou à aplicação principal, tem de ter cuidado ao realizar a ativação pós-falha para evitar relatórios obsoletos no arquivo de estado de funcionamento. A lógica tem de ser adicionada para manter o estado correto e limpar o relatório do arquivo quando já não for necessário.
Implementar relatórios de estado de funcionamento
Assim que os detalhes da entidade e do relatório estiverem claros, o envio de relatórios de estado de funcionamento pode ser feito através da API, do PowerShell ou do REST.
API
Para comunicar através da API, tem de criar um relatório de estado de funcionamento específico do tipo de entidade em que pretende reportar. Dê o relatório a um cliente de estado de funcionamento. Em alternativa, crie uma informação de estado de funcionamento e transmita-as para métodos de relatório corretos em Partition ou CodePackageActivationContext para comunicar as entidades atuais.
O exemplo seguinte mostra relatórios periódicos de um cão de guarda no cluster. O watchdog verifica se um recurso externo pode ser acedido a partir de um nó. O recurso é necessário para um manifesto de serviço na aplicação. Se o recurso não estiver disponível, os outros serviços na aplicação ainda poderão funcionar corretamente. Por conseguinte, o relatório é enviado na entidade do pacote de serviço implementada 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 estado de funcionamento com Send-ServiceFabricEntityTypeHealthReport.
O exemplo seguinte mostra relatórios periódicos sobre valores de CPU num nó. Os relatórios devem ser enviados a cada 30 segundos e têm um tempo de vida de dois minutos. Se expirarem, o repórter tem problemas, pelo que o nó é avaliado com o erro. Quando a CPU está acima de um limiar, o relatório tem um estado de funcionamento de aviso. Quando a CPU permanece acima de um limiar durante mais do que o tempo configurado, é reportada como um erro. Caso contrário, o repórter envia um estado de funcionamento 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 seguinte comunica um aviso transitório numa réplica. Obtém primeiro o ID da partição e, em seguida, o ID de réplica do serviço em que está interessado. Em seguida, envia um relatório do PowershellWatcher na propriedade ResourceDependency. O relatório é de interesse durante apenas dois minutos e é removido automaticamente do arquivo.
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 estado de funcionamento com pedidos REST com POST que vão para a entidade pretendida e têm no corpo a descrição do relatório de estado de funcionamento. Por exemplo, veja como enviar relatórios de estado de funcionamento do cluster REST ou relatórios de estado de funcionamento do serviço. Todas as entidades são suportadas.
Passos seguintes
Com base nos dados de estado de funcionamento, os escritores de serviços e os administradores de clusters/aplicações podem pensar em formas de consumir as informações. Por exemplo, podem configurar alertas com base no estado de funcionamento para detetar problemas graves antes de provocarem interrupções. Os administradores também podem configurar sistemas de reparação para corrigir problemas automaticamente.
Introdução à Monitorização do Estado de Funcionamento do Service Fabric
Ver relatórios de estado de funcionamento do Service Fabric
Como comunicar e verificar o estado de funcionamento do serviço
Utilizar relatórios de estado de funcionamento do sistema para resolução de problemas