Introdução à monitorização do estado de funcionamento do Service Fabric

Artigo
06/01/2023

O Azure Service Fabric apresenta um modelo de estado de funcionamento que fornece relatórios e avaliações de estado de funcionamento avançadas, flexíveis e extensíveis. O modelo permite a monitorização quase em tempo real do estado do cluster e dos serviços em execução no mesmo. Pode obter facilmente informações de estado de funcionamento e corrigir potenciais problemas antes de estes se propagarem e causarem falhas massivas. No modelo típico, os serviços enviam relatórios com base nas vistas locais e essas informações são agregadas para fornecer uma vista geral ao nível do cluster.

Os componentes do Service Fabric utilizam este modelo de estado de funcionamento avançado para comunicar o estado atual. Pode utilizar o mesmo mecanismo para comunicar o estado de funcionamento das suas aplicações. Se investir em relatórios de estado de funcionamento de alta qualidade que capturam as suas condições personalizadas, pode detetar e corrigir problemas para a sua aplicação em execução muito mais facilmente.

Veja esta página para obter um vídeo de formação que descreva o modelo de estado de funcionamento do Service Fabric e como é utilizado:

Nota

Iniciámos o subsistema de estado de funcionamento para resolver a necessidade de atualizações monitorizadas. O Service Fabric fornece atualizações monitorizadas de aplicações e clusters que garantem a disponibilidade total, sem tempo de inatividade e sem intervenção mínima para nenhum utilizador. Para atingir estes objetivos, a atualização verifica o estado de funcionamento com base nas políticas de atualização configuradas. Uma atualização só pode prosseguir quando o estado de funcionamento respeitar os limiares pretendidos. Caso contrário, a atualização é revertida automaticamente ou colocada em pausa para dar aos administradores a oportunidade de corrigir os problemas. Para saber mais sobre as atualizações de aplicações, veja este artigo.

Arquivo de estado de funcionamento

O arquivo de estado de funcionamento mantém informações relacionadas com o estado de funcionamento sobre entidades no cluster para obter e avaliar facilmente. É implementado como um serviço com estado persistente do Service Fabric para garantir elevada disponibilidade e escalabilidade. O arquivo de estado de funcionamento faz parte da aplicação fabric:/System e está disponível quando o cluster está em execução.

Entidades de estado de funcionamento e hierarquia

As entidades de estado de funcionamento estão organizadas numa hierarquia lógica que captura interações e dependências entre diferentes entidades. O arquivo de estado de funcionamento cria automaticamente entidades de estado de funcionamento e hierarquia com base em relatórios recebidos de componentes do Service Fabric.

As entidades de estado de funcionamento espelham as entidades do Service Fabric. (Por exemplo, a entidade da aplicação de estado de funcionamento corresponde a uma instância de aplicação implementada no cluster, enquanto a entidade do nó de estado de funcionamento corresponde a um nó de cluster do Service Fabric.) A hierarquia de estado de funcionamento captura as interações das entidades do sistema e é a base para uma avaliação avançada do estado de funcionamento. Pode saber mais sobre os principais conceitos do Service Fabric na descrição geral técnica do Service Fabric. Para obter mais informações sobre a aplicação, veja Modelo de aplicação do Service Fabric.

As entidades de estado de funcionamento e a hierarquia permitem que o cluster e as aplicações sejam efetivamente comunicados, depurados e monitorizados. O modelo de estado de funcionamento fornece uma representação granular precisa do estado de funcionamento das muitas peças móveis no cluster.

As entidades de estado de funcionamento, organizadas numa hierarquia com base nas relações principal-subordinado.

As entidades de estado de funcionamento são:

Cluster. Representa o estado de funcionamento de um cluster do Service Fabric. Os relatórios de estado de funcionamento do cluster descrevem as condições que afetam todo o cluster. Estas condições afetam várias entidades no cluster ou no próprio cluster. Com base na condição, o repórter não pode restringir o problema a uma ou mais crianças em mau estado de funcionamento. Os exemplos incluem o cérebro da divisão do cluster devido a problemas de criação de partições de rede ou comunicação.
Nó. Representa o estado de funcionamento de um nó do Service Fabric. Os relatórios de estado de funcionamento do nó descrevem as condições que afetam a funcionalidade do nó. Normalmente, afetam todas as entidades implementadas em execução no mesmo. Os exemplos incluem o nó sem espaço em disco (ou outras propriedades em toda a máquina, como memória, ligações) e quando um nó está inativo. A entidade do nó é identificada pelo nome do nó (cadeia).
Aplicação. Representa o estado de funcionamento de uma instância de aplicação em execução no cluster. Os relatórios do estado de funcionamento da aplicação descrevem as condições que afetam o estado de funcionamento geral da aplicação. Não podem ser reduzidas a crianças individuais (serviços ou aplicações implementadas). Os exemplos incluem a interação ponto a ponto entre diferentes serviços na aplicação. A entidade da aplicação é identificada pelo nome da aplicação (URI).
Serviço. Representa o estado de funcionamento de um serviço em execução no cluster. Estado de funcionamento dos serviços relatórios descrevem as condições que afetam o estado de funcionamento geral do serviço. O repórter não consegue restringir o problema a uma partição ou réplica em mau estado de funcionamento. Os exemplos incluem uma configuração de serviço (como a porta ou a partilha de ficheiros externo) que está a causar problemas em todas as partições. A entidade de serviço é identificada pelo nome do serviço (URI).
Partição. Representa o estado de funcionamento de uma partição de serviço. Os relatórios de estado de funcionamento da partição descrevem as condições que afetam todo o conjunto de réplicas. Os exemplos incluem quando o número de réplicas está abaixo da contagem de destino e quando uma partição está em perda de quórum. A entidade de partição é identificada pelo ID de partição (GUID).
Réplica. Representa o estado de funcionamento de uma réplica de serviço com estado ou de uma instância de serviço sem estado. A réplica é a unidade mais pequena na qual os watchdogs e os componentes do sistema podem reportar para uma aplicação. Para serviços com estado, os exemplos incluem uma réplica primária que não consegue replicar operações para secundários e replicação lenta. Além disso, uma instância sem estado pode comunicar quando está a ficar sem recursos ou tem problemas de conectividade. A entidade de réplica é identificada pelo ID de partição (GUID) e pelo ID da réplica ou da instância (longo).
DeployedApplication. Representa o estado de funcionamento de uma aplicação em execução num nó. Os relatórios de estado de funcionamento da aplicação implementados descrevem condições específicas da aplicação no nó que não podem ser reduzidas aos pacotes de serviço implementados no mesmo nó. Os exemplos incluem erros quando o pacote de aplicação não pode ser transferido nesse nó e problemas ao configurar os principais de segurança da aplicação no nó. A aplicação implementada é identificada pelo nome da aplicação (URI) e pelo nome do nó (cadeia).
DeployedServicePackage. Representa o estado de funcionamento de um pacote de serviço em execução num nó no cluster. Descreve condições específicas de um pacote de serviço que não afetam os outros pacotes de serviço no mesmo nó da mesma aplicação. Os exemplos incluem um pacote de código no pacote de serviço que não pode ser iniciado e um pacote de configuração que não pode ser lido. O pacote de serviço implementado é identificado pelo nome da aplicação (URI), nome do nó (cadeia), nome do manifesto do serviço (cadeia) e ID de ativação do pacote de serviço (cadeia).

A granularidade do modelo de estado de funcionamento facilita a deteção e a correção de problemas. Por exemplo, se um serviço não estiver a responder, é possível comunicar que a instância da aplicação está em mau estado de funcionamento. No entanto, os relatórios a esse nível não são ideais, uma vez que o problema pode não estar a afetar todos os serviços nessa aplicação. O relatório deve ser aplicado ao serviço em mau estado de funcionamento ou a uma partição subordinada específica, se mais informações apontarem para essa partição. Os dados surgem automaticamente através da hierarquia e uma partição em mau estado de funcionamento torna-se visível ao nível do serviço e da aplicação. Esta agregação ajuda a identificar e resolver a causa principal do problema mais rapidamente.

A hierarquia de estado de funcionamento é composta por relações principal-subordinado. Um cluster é composto por nós e aplicações. As aplicações têm serviços e aplicações implementadas. As aplicações implementadas implementaram pacotes de serviço. Os serviços têm partições e cada partição tem uma ou mais réplicas. Existe uma relação especial entre nós e entidades implementadas. Um nó em mau estado de funcionamento, conforme comunicado pelo componente do sistema de autoridade, o serviço Gestor de Ativação Pós-falha, afeta as aplicações implementadas, os pacotes de serviço e as réplicas implementadas no mesmo.

A hierarquia de estado de funcionamento representa o estado mais recente do sistema com base nos relatórios de estado de funcionamento mais recentes, que são informações quase em tempo real. Os watchdogs internos e externos podem comunicar as mesmas entidades com base na lógica específica da aplicação ou nas condições monitorizadas personalizadas. Os relatórios de utilizador coexistem com os relatórios do sistema.

Planeie investir na forma de comunicar e responder ao estado de funcionamento durante a conceção de um grande serviço cloud. Este investimento inicial facilita a depuração, monitorização e operação do serviço.

Estados de saúde

O Service Fabric utiliza três estados de estado de funcionamento para descrever se uma entidade está ou não em bom estado de funcionamento: OK, aviso e erro. Qualquer relatório enviado para o arquivo de estado de funcionamento tem de especificar um destes estados. O resultado da avaliação do estado de funcionamento é um destes estados.

Os possíveis estados de funcionamento são:

Ok, ok. A entidade está em bom estado de funcionamento. Não existem problemas conhecidos comunicados sobre o mesmo ou os respetivos subordinados (quando aplicável).
Aviso. A entidade tem alguns problemas, mas ainda pode funcionar corretamente. Por exemplo, existem atrasos, mas ainda não causam problemas funcionais. Em alguns casos, a condição de aviso pode corrigir-se sem intervenção externa. Nestes casos, os relatórios de saúde aumentam a consciencialização e dão visibilidade ao que se está a passar. Noutros casos, a condição de aviso pode degradar-se para um problema grave sem a intervenção do utilizador.
Erro. A entidade está em mau estado de funcionamento. Deve ser tomada uma ação para corrigir o estado da entidade, uma vez que não pode funcionar corretamente.
Desconhecido. A entidade não existe no arquivo de estado de funcionamento. Este resultado pode ser obtido a partir das consultas distribuídas que intercalam resultados de vários componentes. Por exemplo, a consulta obter lista de nós vai para FailoverManager, ClusterManager e HealthManager; A consulta obter lista de aplicações vai para ClusterManager e HealthManager. Estas consultas intercalam resultados de vários componentes do sistema. Se outro componente do sistema devolver uma entidade que não está presente no arquivo de estado de funcionamento, o resultado intercalado tem um estado de funcionamento desconhecido. Uma entidade não está armazenada porque os relatórios de estado de funcionamento ainda não foram processados ou a entidade foi limpa após a eliminação.

Políticas de estado de funcionamento

O arquivo de estado de funcionamento aplica políticas de estado de funcionamento para determinar se uma entidade está em bom estado de funcionamento com base nos seus relatórios e nos respetivos subordinados.

Nota

As políticas de estado de funcionamento podem ser especificadas no manifesto do cluster (para avaliação do estado de funcionamento do cluster e do nó) ou no manifesto da aplicação (para avaliação de aplicações e qualquer um dos respetivos subordinados). Os pedidos de avaliação do estado de funcionamento também podem passar em políticas de avaliação de estado de funcionamento personalizadas, que são utilizadas apenas para essa avaliação.

Por predefinição, o Service Fabric aplica regras estritas (tudo tem de estar em bom estado de funcionamento) para a relação hierárquica principal-subordinado. Se uma das crianças tiver um evento em mau estado de funcionamento, o elemento principal é considerado mau estado de funcionamento.

Política de estado de funcionamento do cluster

A política de estado de funcionamento do cluster é utilizada para avaliar o estado de funcionamento do cluster e os estados de funcionamento dos nós. A política pode ser definida no manifesto do cluster. Se não estiver presente, é utilizada a política predefinida (zero falhas toleradas).

A política de estado de funcionamento do cluster contém:

ConsidereWarningAsError. Especifica se deve tratar os relatórios de estado de funcionamento do aviso como erros durante a avaliação do estado de funcionamento. Predefinição: false.
MaxPercentUnhealthyApplications. Especifica a percentagem máxima tolerada de aplicações que podem estar em mau estado de funcionamento antes de o cluster ser considerado como erro.
MaxPercentUnhealthyNodes. Especifica a percentagem máxima tolerada de nós que podem estar em mau estado de funcionamento antes de o cluster ser considerado como erro. Em clusters grandes, alguns nós estão sempre inativos ou sem reparações, pelo que esta percentagem deve ser configurada para tolerar isso.
ApplicationTypeHealthPolicyMap. O mapa da política de estado de funcionamento do tipo de aplicação pode ser utilizado durante a avaliação do estado de funcionamento do cluster para descrever tipos de aplicações especiais. Por predefinição, todas as aplicações são colocadas num conjunto e avaliadas com MaxPercentUnhealthyApplications. Se alguns tipos de aplicações devem ser tratados de forma diferente, podem ser retirados do conjunto global. Em vez disso, são avaliadas em relação às percentagens associadas ao nome do tipo de aplicação no mapa. Por exemplo, num cluster existem milhares de aplicações de diferentes tipos e algumas instâncias de aplicação de controlo de um tipo de aplicação especial. As aplicações de controlo nunca devem estar incorrer em erros. Pode especificar maxPercentUnhealthyApplications global para 20% para tolerar algumas falhas, mas para o tipo de aplicação "ControlApplicationType" defina MaxPercentUnhealthyApplications como 0. Desta forma, se algumas das muitas aplicações estiverem em mau estado de funcionamento, mas abaixo da percentagem global de mau estado de funcionamento, o cluster será avaliado como Aviso. Um estado de funcionamento de aviso não afeta a atualização do cluster ou outra monitorização acionada pelo estado de funcionamento do erro. Mas mesmo uma aplicação de controlo com erro tornaria o cluster em mau estado de funcionamento, o que aciona a reversão ou coloca a atualização do cluster em pausa, dependendo da configuração da atualização. Para os tipos de aplicações definidos no mapa, todas as instâncias da aplicação são retiradas do conjunto global de aplicações. São avaliadas com base no número total de aplicações do tipo de aplicação, com as MaxPercentUnhealthyApplications específicas do mapa. Todas as restantes aplicações permanecem no conjunto global e são avaliadas com MaxPercentUnhealthyApplications.

O exemplo seguinte é um excerto de um manifesto de cluster. Para definir entradas no mapa do tipo de aplicação, prefixe o nome do parâmetro com "ApplicationTypeMaxPercentUnhealthyApplications-", seguido do nome do tipo de aplicação.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="ApplicationTypeMaxPercentUnhealthyApplications-ControlApplicationType" Value="0" />
  </Section>
</FabricSettings>
```
NodeTypeHealthPolicyMap. O mapa da política de estado de funcionamento do tipo de nó pode ser utilizado durante a avaliação do estado de funcionamento do cluster para descrever tipos de nós especiais. Os tipos de nó são avaliados em relação às percentagens associadas ao nome do tipo de nó no mapa. Definir este valor não tem qualquer efeito no conjunto global de nós utilizados para MaxPercentUnhealthyNodes. Por exemplo, um cluster tem centenas de nós de diferentes tipos e alguns tipos de nós que alojam trabalhos importantes. Nenhum nó nesse tipo deve estar inativo. Pode especificar global MaxPercentUnhealthyNodes a 20% para tolerar algumas falhas para todos os nós, mas para o tipo SpecialNodeTypede nó , defina como MaxPercentUnhealthyNodes 0. Desta forma, se alguns dos muitos nós estiverem em mau estado de funcionamento, mas abaixo da percentagem global de mau estado de funcionamento, o cluster será avaliado como estando no estado de funcionamento aviso. Um Estado de funcionamento de aviso não afeta a atualização do cluster ou outra monitorização acionada por um estado de funcionamento do Erro. Mas mesmo um nó do tipo SpecialNodeType num Estado de funcionamento do erro tornaria o cluster em mau estado de funcionamento e acionaria a reversão ou colocaria em pausa a atualização do cluster, dependendo da configuração da atualização. Por outro lado, definir o global MaxPercentUnhealthyNodes como 0 e definir a SpecialNodeType percentagem máxima de nós em mau estado de funcionamento como 100 com um nó do tipo SpecialNodeType num estado de erro ainda colocaria o cluster num estado de erro porque a restrição global é mais rigorosa neste caso.

O exemplo seguinte é um excerto de um manifesto de cluster. Para definir entradas no mapa do tipo de nó, prefixe o nome do parâmetro com "NodeTypeMaxPercentUnhealthyNodes-", seguido do nome do tipo de nó.
```
<FabricSettings>
  <Section Name="HealthManager/ClusterHealthPolicy">
    <Parameter Name="ConsiderWarningAsError" Value="False" />
    <Parameter Name="MaxPercentUnhealthyApplications" Value="20" />
    <Parameter Name="MaxPercentUnhealthyNodes" Value="20" />
    <Parameter Name="NodeTypeMaxPercentUnhealthyNodes-SpecialNodeType" Value="0" />
  </Section>
</FabricSettings>
```

Política de estado de funcionamento da aplicação

A política de estado de funcionamento da aplicação descreve como a avaliação de eventos e a agregação de estados subordinados é feita para aplicações e respetivos subordinados. Pode ser definido no manifesto da aplicação, ApplicationManifest.xml, no pacote de aplicações. Se não forem especificadas políticas, o Service Fabric assume que a entidade está em mau estado de funcionamento se tiver um relatório de estado de funcionamento ou um subordinado no estado de funcionamento do aviso ou erro. As políticas configuráveis são:

ConsidereWarningAsError. Especifica se deve tratar os relatórios de estado de funcionamento do aviso como erros durante a avaliação do estado de funcionamento. Predefinição: false.
MaxPercentUnhealthyDeployedApplications. Especifica a percentagem máxima tolerada de aplicações implementadas que podem estar em mau estado de funcionamento antes de a aplicação ser considerada como erro. Esta percentagem é calculada ao dividir o número de aplicações implementadas em mau estado de funcionamento em relação ao número de nós em que as aplicações estão atualmente implementadas no cluster. O cálculo arredonda para tolerar uma falha num pequeno número de nós. Percentagem predefinida: zero.
DefaultServiceTypeHealthPolicy. Especifica a política de estado de funcionamento do tipo de serviço predefinida, que substitui a política de estado de funcionamento predefinida para todos os tipos de serviço na aplicação.
ServiceTypeHealthPolicyMap. Fornece um mapa das políticas de estado de funcionamento do serviço por tipo de serviço. Estas políticas substituem as políticas de estado de funcionamento do tipo de serviço predefinidas para cada tipo de serviço especificado. Por exemplo, se uma aplicação tiver um tipo de serviço de gateway sem estado e um tipo de serviço de motor com monitorização de estado, pode configurar as políticas de estado de funcionamento para a respetiva avaliação de forma diferente. Quando especifica a política por tipo de serviço, pode obter um controlo mais granular do estado de funcionamento do serviço.

Política de estado de funcionamento do tipo de serviço

A política de estado de funcionamento do tipo de serviço especifica como avaliar e agregar os serviços e os subordinados dos serviços. A política contém:

MaxPercentUnhealthyPartitionsPerService. Especifica a percentagem máxima tolerada de partições em mau estado de funcionamento antes de um serviço ser considerado em mau estado de funcionamento. Percentagem predefinida: zero.
MaxPercentUnhealthyReplicasPerPartition. Especifica a percentagem máxima tolerada de réplicas em mau estado de funcionamento antes de uma partição ser considerada em mau estado de funcionamento. Percentagem predefinida: zero.
MaxPercentUnhealthyServices. Especifica a percentagem máxima tolerada de serviços em mau estado de funcionamento antes de a aplicação ser considerada em mau estado de funcionamento. Percentagem predefinida: zero.

O exemplo seguinte é um excerto de um manifesto de aplicação:

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

Avaliação do estado de funcionamento

Os utilizadores e os serviços automatizados podem avaliar o estado de funcionamento de qualquer entidade em qualquer altura. Para avaliar o estado de funcionamento de uma entidade, o arquivo de estado de funcionamento agrega todos os relatórios de estado de funcionamento na entidade e avalia todos os respetivos subordinados (quando aplicável). O algoritmo de agregação de estado de funcionamento utiliza políticas de estado de funcionamento que especificam como avaliar relatórios de estado de funcionamento e como agregar estados de estado de funcionamento subordinados (quando aplicável).

Agregação de relatórios de estado de funcionamento

Uma entidade pode ter vários relatórios de estado de funcionamento enviados por diferentes repórteres (componentes do sistema ou watchdogs) em diferentes propriedades. A agregação utiliza as políticas de estado de funcionamento associadas, em particular o membro ConsiderWarningAsError da política de estado de funcionamento da aplicação ou do cluster. ConsiderWarningAsError especifica como avaliar avisos.

O estado de funcionamento agregado é acionado pelos piores relatórios de estado de funcionamento da entidade. Se existir, pelo menos, um relatório de estado de funcionamento do erro, o estado de funcionamento agregado é um erro.

Agregação de relatórios de estado de funcionamento com relatório de erros.

Uma entidade de estado de funcionamento que tenha um ou mais relatórios de estado de funcionamento de erros é avaliada como Erro. O mesmo acontece com um relatório de saúde expirado, independentemente do seu estado de funcionamento.

Se não existirem relatórios de erro e um ou mais avisos, o estado de funcionamento agregado será aviso ou erro, dependendo do sinalizador de política ConsiderWarningAsError.

Agregação de relatórios de estado de funcionamento com relatório de aviso e ConsiderWarningAsError false.

Agregação de relatórios de estado de funcionamento com relatório de aviso e ConsiderWarningAsError definido como falso (predefinição).

Agregação do estado de funcionamento subordinado

O estado de funcionamento agregado de uma entidade reflete os estados de estado de funcionamento subordinado (quando aplicável). O algoritmo para agregar estados de estado de funcionamento subordinado utiliza as políticas de estado de funcionamento aplicáveis com base no tipo de entidade.

Agregação do estado de funcionamento das entidades subordinados.

Agregação subordinada com base em políticas de saúde.

Depois de o arquivo de saúde ter avaliado todas as crianças, agrega os seus estados de saúde com base na percentagem máxima configurada de crianças em mau estado de funcionamento. Esta percentagem é retirada da política com base na entidade e no tipo subordinado.

Se todas as crianças tiverem estados OK, o estado de funcionamento agregado da criança é OK.
Se as crianças tiverem estados ok e aviso, o estado de funcionamento agregado da criança será avisado.
Se existirem crianças com estados de erro que não respeitam a percentagem máxima permitida de crianças em mau estado de funcionamento, o estado de funcionamento principal agregado é um erro.
Se as crianças com estados de erro respeitarem a percentagem máxima permitida de crianças em mau estado de funcionamento, o estado de funcionamento principal agregado é um aviso.

Relatórios de estado de funcionamento

Os componentes do sistema, as aplicações do System Fabric e os watchdogs internos/externos podem comunicar com entidades do Service Fabric. Os jornalistas fazem determinações locais sobre o estado de funcionamento das entidades monitorizadas, com base nas condições que estão a monitorizar. Não precisam de analisar nenhum estado global ou agregar dados. O comportamento desejado é ter repórteres simples, e não organismos complexos que precisam olhar para muitas coisas para inferir que informações enviar.

Para enviar dados de estado de funcionamento para o arquivo de estado de funcionamento, um repórter tem de identificar a entidade afetada e criar um relatório de estado de funcionamento. Para enviar o relatório, utilize a API FabricClient.HealthClient.ReportHealth , as APIs de estado de funcionamento dos Partition relatórios expostas nos objetos ou CodePackageActivationContext , cmdlets do PowerShell ou REST.

Relatórios de estado de funcionamento

Os relatórios de estado de funcionamento de cada uma das entidades no cluster contêm as seguintes informações:

SourceId. Uma cadeia que identifica exclusivamente o repórter do evento de estado de funcionamento.
Identificador de entidade. Identifica a entidade onde o relatório é aplicado. Difere com base no tipo de entidade:
- Cluster. Nenhum.
- Nó. Nome do nó (cadeia).
- Aplicação. Nome da aplicação (URI). Representa o nome da instância da aplicação implementada no cluster.
- Serviço. Nome do serviço (URI). Representa o nome da instância de serviço implementada no cluster.
- Partição. ID de Partição (GUID). Representa o identificador exclusivo da partição.
- Réplica. O ID da réplica de serviço com estado ou o ID da instância de serviço sem estado (INT64).
- DeployedApplication. Nome da aplicação (URI) e nome do nó (cadeia).
- DeployedServicePackage. Nome da aplicação (URI), nome do nó (cadeia) e nome do manifesto de serviço (cadeia).
Propriedade. Uma cadeia (não uma enumeração fixa) que permite ao repórter categorizar o evento de estado de funcionamento para uma propriedade específica da entidade. Por exemplo, o repórter A pode comunicar o estado de funcionamento da propriedade Node01 "Storage" e o repórter B pode comunicar o estado de funcionamento da propriedade "Conectividade" do Nó01. No arquivo de estado de funcionamento, estes relatórios são tratados como eventos de estado de funcionamento separados para a entidade Node01.
Descrição. Uma cadeia que permite a um repórter fornecer informações detalhadas sobre o evento de estado de funcionamento. SourceId, Property e HealthState devem descrever totalmente o relatório. A descrição adiciona informações legíveis por humanos sobre o relatório. O texto facilita a compreensão do relatório de estado de funcionamento por parte dos administradores e utilizadores.
HealthState. Uma enumeração que descreve o estado de funcionamento do relatório. Os valores aceites são OK, Aviso e Erro.
TimeToLive. Um período de tempo que indica quanto tempo o relatório de estado de funcionamento é válido. Juntamente com RemoveWhenExpired, permite ao arquivo de estado de funcionamento saber como avaliar eventos expirados. Por predefinição, o valor é infinito e o relatório é válido para sempre.
RemoveWhenExpired. Um booleano. Se definido como verdadeiro, o relatório de estado de funcionamento expirado é removido automaticamente do arquivo de estado de funcionamento e o relatório não afeta a avaliação do estado de funcionamento da entidade. Utilizado quando o relatório é válido apenas por um período de tempo especificado e o repórter não precisa de o limpar explicitamente. Também é utilizado para eliminar relatórios do arquivo de estado de funcionamento (por exemplo, um cão de guarda é alterado e deixa de enviar relatórios com a origem e propriedade anteriores). Pode enviar um relatório com um breve TimeToLive juntamente com RemoveWhenExpired para limpar qualquer estado anterior do arquivo de estado de funcionamento. Se o valor estiver definido como falso, o relatório expirado será tratado como um erro na avaliação do estado de funcionamento. O valor falso indica ao arquivo de estado de funcionamento que a origem deve comunicar periodicamente nesta propriedade. Se não, deve haver algo de errado com o cão de guarda. O estado de funcionamento do cão de guarda é capturado ao considerar o evento como um erro.
SequenceNumber. Um número inteiro positivo que tem de ser cada vez maior, representa a ordem dos relatórios. É utilizado pelo arquivo de estado de funcionamento para detetar relatórios obsoletos recebidos em atraso devido a atrasos na rede ou outros problemas. Um relatório é rejeitado se o número de sequência for menor ou igual ao número aplicado mais recentemente para a mesma entidade, origem e propriedade. Se não for especificado, o número de sequência é gerado automaticamente. É necessário colocar o número de sequência apenas quando se comunica em transições de estado. Nesta situação, a origem tem de se lembrar dos relatórios que enviou e manter as informações para recuperação na ativação pós-falha.

Estas quatro partes de information--SourceId, identificador de entidade, Propriedade e HealthState -- são necessárias para cada relatório de estado de funcionamento. A cadeia SourceId não tem permissão para começar com o prefixo "System.", que está reservado para relatórios de sistema. Para a mesma entidade, existe apenas um relatório para a mesma origem e propriedade. Vários relatórios da mesma origem e propriedade substituem-se mutuamente, quer no lado do cliente de estado de funcionamento (se estiverem em lotes) quer no lado do arquivo de estado de funcionamento. A substituição baseia-se em números de sequência; Os relatórios mais recentes (com números de sequência mais elevados) substituem os relatórios mais antigos.

Eventos de estado de funcionamento

Internamente, o arquivo de estado de funcionamento mantém eventos de estado de funcionamento, que contêm todas as informações dos relatórios e metadados adicionais. Os metadados incluem a hora em que o relatório foi dado ao cliente de estado de funcionamento e a hora em que foi modificado do lado do servidor. Os eventos de estado de funcionamento são devolvidos por consultas de estado de funcionamento.

Os metadados adicionados contêm:

SourceUtcTimestamp. A hora em que o relatório foi dado ao cliente de estado de funcionamento (Hora Universal Coordenada).
LastModifiedUtcTimestamp. A hora em que o relatório foi modificado pela última vez no lado do servidor (Hora Universal Coordenada).
IsExpired. Um sinalizador para indicar se o relatório expirou quando a consulta foi executada pelo arquivo de estado de funcionamento. Um evento só pode expirar se RemoveWhenExpired for falso. Caso contrário, o evento não é devolvido pela consulta e é removido do arquivo.
LastOkTransitionAt, LastWarningTransitionAt, LastErrorTransitionAt. A última vez para transições OK/aviso/erro. Estes campos dão o histórico das transições de estado de funcionamento para o evento.

Os campos de transição de estado podem ser utilizados para alertas mais inteligentes ou informações de eventos de estado de funcionamento "históricos". Ativam cenários como:

Alertar quando uma propriedade estiver em aviso/erro durante mais de X minutos. Verificar a condição durante um período de tempo evita alertas sobre condições temporárias. Por exemplo, um alerta se o estado de funcionamento tiver sido avisado durante mais de cinco minutos pode ser traduzido para (HealthState == Aviso e Agora - LastWarningTransitionTime > 5 minutos).
Alerta apenas sobre as condições que foram alteradas nos últimos X minutos. Se um relatório já estava com o erro antes da hora especificada, pode ser ignorado porque já foi sinalizado anteriormente.
Se uma propriedade estiver a alternar entre o aviso e o erro, determine durante quanto tempo está em mau estado de funcionamento (ou seja, não ESTÁ OK). Por exemplo, um alerta se a propriedade não estiver em bom estado de funcionamento durante mais de cinco minutos pode ser traduzido para (HealthState != Ok e Agora - LastOkTransitionTime > 5 minutos).

Exemplo: Comunicar e avaliar o estado de funcionamento da aplicação

O exemplo seguinte envia um relatório de estado de funcionamento através do PowerShell nos recursos de infraestrutura da aplicação :/WordCount a partir da origem MyWatchdog. O relatório de estado de funcionamento contém informações sobre a propriedade de estado de funcionamento "disponibilidade" num estado de funcionamento de erros, com TimeToLive infinito. Em seguida, consulta o estado de funcionamento da aplicação, que devolve erros de estado de funcionamento agregado e os eventos de estado de funcionamento comunicados na lista de eventos de estado de funcionamento.

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

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


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

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

                                  ServiceName           : fabric:/WordCount/WordCountWebService
                                  AggregatedHealthState : Ok

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

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

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

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

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

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

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

Utilização do modelo de estado de funcionamento

O modelo de estado de funcionamento permite dimensionar os serviços cloud e a plataforma do Service Fabric subjacente, uma vez que as determinações de monitorização e estado de funcionamento são distribuídas entre os diferentes monitores dentro do cluster. Outros sistemas têm um único serviço centralizado ao nível do cluster que analisa todas as informações potencialmente úteis emitidas pelos serviços. Esta abordagem dificulta a escalabilidade. Também não lhes permite recolher informações específicas para ajudar a identificar problemas e potenciais problemas o mais próximo possível da causa raiz.

O modelo de estado de funcionamento é utilizado fortemente para monitorização e diagnóstico, para avaliar o estado de funcionamento do cluster e da aplicação e para atualizações monitorizadas. Outros serviços utilizam dados de estado de funcionamento para efetuar reparações automáticas, criar o histórico de estado de funcionamento do cluster e emitir alertas sobre determinadas condições.