Utilizar relatórios de saúde do sistema para resolver problemas
Os componentes do Azure Service Fabric fornecem, prontos para uso, relatórios de integridade do sistema sobre todas as entidades no cluster. A loja de saúde cria e elimina entidades baseando-se nos relatórios do sistema. Ele também os organiza em uma hierarquia que captura as interações da entidade.
Observação
Para entender os conceitos relacionados à saúde, leia mais em Modelo de saúde do Service Fabric.
Os relatórios de integridade do sistema fornecem visibilidade sobre a funcionalidade do cluster e do aplicativo e sinalizam problemas. Para aplicativos e serviços, os relatórios de integridade do sistema verificam se as entidades estão implementadas e se comportando corretamente da perspetiva do Service Fabric. Os relatórios não fornecem nenhum monitoramento de integridade da lógica de negócios do serviço ou deteção de processos que não estão respondendo. Os serviços do usuário podem enriquecer os dados de saúde com informações específicas para sua lógica.
Observação
Os relatórios de estado do sistema enviados por sistemas de monitorização são visíveis somente depois que os componentes do sistema criam uma entidade. Quando uma entidade é excluída, a loja de saúde exclui automaticamente todos os relatórios de saúde associados a ela. O mesmo é verdadeiro quando uma nova instância da entidade é criada. Um exemplo é quando uma nova réplica de instância de serviço persistente e com estado é criada. Todos os relatórios associados à instância antiga são removidos e limpos da loja.
Os relatórios de componentes do sistema são identificados pela fonte, que começa com o prefixo "System.". Os vigilantes não podem usar o mesmo prefixo para suas fontes, pois relatórios com parâmetros inválidos são rejeitados.
Vamos olhar para alguns relatórios do sistema para entender o que os desencadeia e aprender a corrigir os problemas potenciais que eles representam.
Observação
O Service Fabric continua a adicionar relatórios sobre condições de interesse que melhoram a visibilidade do que está acontecendo no cluster e nos aplicativos. Os relatórios existentes podem ser aprimorados com mais detalhes para ajudar a solucionar o problema mais rapidamente.
Relatórios de integridade do sistema de cluster
A entidade de integridade do cluster é automaticamente criada no repositório de integridade. Se tudo funcionar corretamente, não haverá um relatório do sistema.
Perda de vizinhança
System.Federation relata um erro quando deteta uma perda de bairro. O relatório é de nodos individuais e o ID do nodo está incluído no nome da propriedade. Se um bairro for perdido em todo o anel do Service Fabric, normalmente você pode esperar dois eventos que representam ambos os lados do relatório de lacunas. Se mais bairros desaparecerem, haverá mais eventos.
O relatório especifica o tempo limite de locação global como o tempo de vida útil (TTL). O relatório é reenviado a cada metade do tempo de duração do TTL enquanto a condição permanecer ativa. O evento é removido automaticamente quando expira. O comportamento Remover quando expirado garante que o relatório seja removido do armazenamento de integridade corretamente, mesmo que o nó de relatório esteja inativo.
- SourceId: System.Federation
- Propriedade: Começa com Bairro e inclui informações sobre os nós.
- Próximos passos: Investigar por que o bairro está perdido. Por exemplo, verifique a comunicação entre nós do cluster.
Reconstruir
O serviço Gerenciador de Failover (FM) gerencia informações sobre os nós do cluster. Quando o FM perde seus dados e entra em perda de dados, ele não pode garantir que tenha as informações mais atualizadas sobre os nós do cluster. Nesse caso, o sistema passa por uma reconstrução, e System.FM reúne dados de todos os nós no cluster para reconstruir seu estado. Às vezes, devido a problemas de rede ou nó, a reconstrução pode ficar presa ou paralisada. O mesmo pode acontecer com o serviço Failover Manager Master (FMM). O FMM é um serviço de sistema sem estado que controla onde todos os FMs estão no cluster. O nó principal do FMM é sempre aquele com o ID mais próximo de 0. Se esse nó for removido, uma reconstrução é iniciada. Quando uma das condições anteriores acontece, System.FM ou System.FMM sinaliza-o através de um relatório de erros. A reconstrução pode ficar presa em uma de duas fases:
Aguardando transmissão: FM/FMM aguarda a resposta da mensagem de transmissão dos outros nós.
- Próximas etapas: Investigue se há um problema de conexão de rede entre nós.
Esperando pelos nós: O FM/FMM já recebeu uma resposta de difusão dos outros nós e está aguardando uma resposta de nós específicos. O relatório de saúde lista os nós para os quais o FM/FMM está a aguardar uma resposta.
- Próximas etapas: Investigue a conexão de rede entre o FM/FMM e os nós listados. Investigue cada nó listado em busca de outros problemas possíveis.
SourceID: System.FM ou System.FMM
Imóvel: Reconstruir.
Próximas etapas: investigue a conexão de rede entre os nós, bem como o estado de quaisquer nós específicos listados na descrição do relatório de integridade.
Status do nó de semente
System.FM relata um aviso de nível de cluster se alguns nós semente não forem saudáveis. Os nós-semente são os nós que mantêm a disponibilidade do cluster subjacente. Esses nós ajudam a garantir que o cluster permaneça ativo, estabelecendo concessões com outros nós e servindo como critérios de desempate durante certos tipos de falhas de rede. Se a maioria dos nós iniciais estiverem inativos no cluster e não forem restaurados, o cluster será desligado automaticamente.
Um nó semente é considerado não saudável se o estado do nó for Inativo, Removido ou Desconhecido. O relatório de alerta sobre o estado dos nós de semente listará todos os nós de semente em mau estado com informações detalhadas.
- Fonte: System.FM
- Propriedade: SeedNodeStatus
- Próximas etapas: Se esse aviso for exibido no cluster, siga as instruções abaixo para corrigi-lo: Para cluster executando o Service Fabric versão 6.5 ou superior: Para o cluster do Service Fabric no Azure, depois que o nó semente ficar inativo, o Service Fabric tentará alterá-lo para um nó não semente automaticamente. Para que isso aconteça, certifique-se de que o número de nós não-semente no tipo de nó primário seja maior ou igual ao número de nós de semente inativos. Se necessário, adicione mais nós ao tipo de nó primário para alcançar esse objetivo. Dependendo do status do cluster, pode levar algum tempo para corrigir o problema. Feito isso, o relatório de aviso é automaticamente apagado.
Para o cluster autônomo do Service Fabric, para limpar o relatório de aviso, todos os nós de propagação precisam se tornar íntegros. Dependendo do motivo pelo qual os nós de semente não estão saudáveis, diferentes ações precisam ser tomadas: se o nó de semente estiver inativo, os utilizadores precisam ativar esse nó de semente; se o nó de semente for Removido ou Desconhecido, esse nó de semente precisará ser removido do cluster. O relatório de aviso é automaticamente limpo quando todos os nós de propagação se tornam íntegros.
Para cluster que executa a versão do Service Fabric anterior à 6.5: nesse caso, o relatório de aviso precisa ser limpo manualmente. Os usuários devem certificar-se de que todos os nós semente estejam saudáveis antes de limpar o relatório: se o nó semente estiver inativo, os usuários precisarão ativá-lo; se o nó semente for Removido ou Desconhecido, esse nó semente precisará ser removido do cluster. Depois que todos os nós de semente se tornarem íntegros, use o seguinte comando do PowerShell para limpar o relatório de aviso:
PS C:\> Send-ServiceFabricClusterHealthReport -SourceId "System.FM" -HealthProperty "SeedNodeStatus" -HealthState OK
Relatórios de integridade do nó do sistema
System.FM, que representa o serviço Gerenciador de Failover, é a autoridade que gerencia informações sobre nós de cluster. Cada nó deve ter um relatório de System.FM mostrando seu estado. As entidades do nó são eliminadas quando o estado do nó é removido. Para obter mais informações, consulte RemoveNodeStateAsync.
Status do nó: ativo/inativo
System.FM informa como OK quando o nó se junta ao anel (ele está ativo e funcionando). Ele relata um erro quando o nó sai do anel (ele está inativo, seja para atualização ou simplesmente porque falhou). A hierarquia de saúde criada pela loja de saúde atua em entidades implantadas em correlação com relatórios de nó System.FM. Ele considera o nó um pai virtual de todas as entidades implantadas. As entidades implantadas nesse nó são expostas através de interrogações se o nó for relatado como ativo pelo System.FM, com a mesma instância da associada às entidades. Quando o System.FM informa que um nó está inativo ou foi reiniciado como uma nova instância, o repositório de integridade limpa automaticamente as entidades implantadas que podem existir apenas no nó inativo ou na instância anterior do nó.
- Fonte: System.FM
- Propriedade: Estado.
- Próximas etapas: Se o nó estiver inativo para uma atualização, ele deve ficar operacional depois de ter sido atualizado. Nesse caso, o estado de saúde deve voltar para OK. Se o nó não voltar ou falhar, o problema precisa de mais investigação.
O exemplo a seguir mostra o evento System.FM com um estado de integridade OK para nó acima:
PS C:\> Get-ServiceFabricNodeHealth _Node_0
NodeName : _Node_0
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Ok
SequenceNumber : 8
SentAt : 7/14/2017 4:54:51 PM
ReceivedAt : 7/14/2017 4:55:14 PM
TTL : Infinite
Description : Fabric node is up.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:14 PM, LastWarning = 1/1/0001 12:00:00 AM
Expiração do certificado
System.FabricNode relata um aviso quando os certificados usados pelo nó estão perto da expiração. Há três certificados por nó: Certificate_cluster, Certificate_server e Certificate_default_client. Quando a expiração estiver a pelo menos duas semanas de distância, o estado de integridade do relatório é OK. Quando a expiração é dentro de duas semanas, o tipo de relatório é um aviso. O TTL desses eventos é infinito e eles são removidos quando um nó sai do cluster.
- SourceId: System.FabricNode
- Propriedade: Começa com Certificado e contém mais informações sobre o tipo de certificado.
- Próximas etapas: atualize os certificados se eles estiverem perto da expiração.
Violação da capacidade de carga
O balanceador de carga do Service Fabric relata um aviso quando detecta uma violação de capacidade de um nó.
- SourceId: System.PLB
- Propriedade: Começa com Capacidade.
- Próximos passos: Consulte as métricas fornecidas e reveja a capacidade atual no nó.
Incompatibilidade da capacidade do nó para métricas de governança de recursos
System.Hosting relata um aviso se as capacidades de nó definidas no manifesto do cluster forem maiores do que as capacidades reais do nó para métricas de governança de recursos (memória e núcleos de CPU). Um relatório de integridade aparece quando o primeiro pacote de serviço que usa governança de recursos regista num nó especificado.
- SourceId: System.Hosting
- Propriedade: Governança de Recursos.
- Próximas etapas: esse problema pode ser um problema porque os pacotes de serviços de governança não são aplicados como esperado e a governança de recursos não funciona corretamente. Atualize o manifesto do cluster com as capacidades de nó corretas para essas métricas ou não as especifique e permita que o Service Fabric detete automaticamente os recursos disponíveis.
Relatórios de integridade do sistema de aplicações
System.CM, que representa o serviço Gerenciador de Cluster, é a autoridade que gerencia informações sobre um aplicativo.
Estado
System.CM relata como OK quando a aplicação é criada ou atualizada. Informa a loja de saúde quando a aplicação é eliminada, para que possa ser removida da loja.
- Fonte: System.CM
- Propriedade: Estado.
- Próximas etapas: Se o aplicativo tiver sido criado ou atualizado, ele deverá incluir o relatório de integridade do Gerenciador de Clusters. Caso contrário, verifique o estado do aplicativo emitindo uma consulta. Por exemplo, use o cmdlet do PowerShell Get-ServiceFabricApplication -ApplicationNameapplicationName.
O exemplo a seguir mostra o evento state no aplicativo fabric:/WordCount :
PS C:\> Get-ServiceFabricApplicationHealth fabric:/WordCount -ServicesFilter None -DeployedApplicationsFilter None -ExcludeHealthStatistics
ApplicationName : fabric:/WordCount
AggregatedHealthState : Ok
ServiceHealthStates : None
DeployedApplicationHealthStates : None
HealthEvents :
SourceId : System.CM
Property : State
HealthState : Ok
SequenceNumber : 282
SentAt : 7/13/2017 5:57:05 PM
ReceivedAt : 7/14/2017 4:55:10 PM
TTL : Infinite
Description : Application has been created.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/13/2017 5:57:05 PM, LastWarning = 1/1/0001 12:00:00 AM
Relatórios de saúde do sistema de serviços
System.FM, que representa o serviço Gerenciador de Failover, é a autoridade que gerencia informações sobre serviços.
Estado
System.FM reporta como OK quando o serviço é criado. Ele exclui a entidade do armazenamento de saúde quando o serviço é excluído.
- Fonte: System.FM
- Imóvel: Estado.
O exemplo a seguir mostra o evento state na malha de serviço :/WordCount/WordCountWebService:
PS C:\> Get-ServiceFabricServiceHealth fabric:/WordCount/WordCountWebService -ExcludeHealthStatistics
ServiceName : fabric:/WordCount/WordCountWebService
AggregatedHealthState : Ok
PartitionHealthStates :
PartitionId : 8bbcd03a-3a53-47ec-a5f1-9b77f73c53b2
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Ok
SequenceNumber : 14
SentAt : 7/13/2017 5:57:05 PM
ReceivedAt : 7/14/2017 4:55:10 PM
TTL : Infinite
Description : Service has been created.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/13/2017 5:57:18 PM, LastWarning = 1/1/0001 12:00:00 AM
Erro de correlação de serviço
System.PLB relata um erro quando deteta que a atualização de um serviço está correlacionada com outro serviço que cria uma cadeia de afinidade. O relatório é limpo quando ocorre uma atualização bem-sucedida.
- SourceId: System.PLB
- Propriedade: DescriçãoDoServiço.
- Próximos passos: Verifique as descrições de serviço correlacionadas.
Relatórios de integridade do sistema de partição
System.FM, que representa o serviço Gerenciador de Failover, é a autoridade que gerencia informações sobre partições de serviço.
Estado
System.FM informa como OK quando a partição foi criada e está íntegra. Quando a partição é excluída, a entidade é excluída do repositório de integridade.
Se a partição estiver abaixo da contagem mínima de réplicas, ela relatará um erro. Se a partição não estiver abaixo da contagem mínima de réplicas, mas estiver abaixo da contagem de réplicas de destino, será emitido um aviso. Se a partição estiver em perda de quórum, System.FM relata um erro.
Outros eventos notáveis incluem um aviso quando a reconfiguração leva mais tempo do que o esperado e quando a compilação leva mais tempo do que o esperado. Os tempos esperados para a compilação e reconfiguração são configuráveis com base nos cenários de serviço. Por exemplo, se um serviço tiver um terabyte de estado, como o Banco de Dados SQL do Azure, a compilação levará mais tempo do que para um serviço com uma pequena quantidade de estado.
- Fonte: System.FM
- Propriedade: Estado.
- Próximas etapas: Se o estado de integridade não estiver OK, é possível que algumas réplicas não tenham sido criadas, abertas ou promovidas para primária ou secundária corretamente.
Se a descrição descrever a perda de quórum, examinar o relatório de integridade detalhado para réplicas que estão inativas e trazê-las de volta ajuda a colocar a partição online novamente.
Se a descrição descrever uma partição presa na reconfiguração, o relatório de estado na réplica primária fornecerá informações adicionais.
Para outros relatórios de integridade do System.FM, seriam apresentados relatórios quer sobre as réplicas, quer sobre a partição ou o serviço de outros componentes do sistema.
Os exemplos a seguir descrevem alguns desses relatórios.
O exemplo a seguir mostra uma partição saudável:
PS C:\> Get-ServiceFabricPartition fabric:/WordCount/WordCountWebService | Get-ServiceFabricPartitionHealth -ExcludeHealthStatistics -ReplicasFilter None
PartitionId : 8bbcd03a-3a53-47ec-a5f1-9b77f73c53b2
AggregatedHealthState : Ok
ReplicaHealthStates : None
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Ok
SequenceNumber : 70
SentAt : 7/13/2017 5:57:05 PM
ReceivedAt : 7/14/2017 4:55:10 PM
TTL : Infinite
Description : Partition is healthy.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/13/2017 5:57:18 PM, LastWarning = 1/1/0001 12:00:00 AM
O exemplo a seguir mostra a saúde de uma partição que está abaixo da contagem-alvo de réplicas. A próxima etapa é obter a descrição da partição, que mostra como ela está configurada: MinReplicaSetSize é três e TargetReplicaSetSize é sete. Em seguida, obtenha o número de nós no cluster, que neste caso é cinco. Portanto, nesse caso, duas réplicas não podem ser colocadas, porque o número de réplicas de destino é maior do que o número de nós disponíveis.
PS C:\> Get-ServiceFabricPartition fabric:/WordCount/WordCountService | Get-ServiceFabricPartitionHealth -ReplicasFilter None -ExcludeHealthStatistics
PartitionId : af2e3e44-a8f8-45ac-9f31-4093eb897600
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.FM', Property='State', HealthState='Warning', ConsiderWarningAsError=false.
ReplicaHealthStates : None
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Warning
SequenceNumber : 123
SentAt : 7/14/2017 4:55:39 PM
ReceivedAt : 7/14/2017 4:55:44 PM
TTL : Infinite
Description : Partition is below target replica or instance count.
fabric:/WordCount/WordCountService 7 2 af2e3e44-a8f8-45ac-9f31-4093eb897600
N/S Ready _Node_2 131444422260002646
N/S Ready _Node_4 131444422293113678
N/S Ready _Node_3 131444422293113679
N/S Ready _Node_1 131444422293118720
N/P Ready _Node_0 131444422293118721
(Showing 5 out of 5 replicas. Total available replicas: 5)
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 7/14/2017 4:55:44 PM, LastOk = 1/1/0001 12:00:00 AM
SourceId : System.PLB
Property : ServiceReplicaUnplacedHealth_Secondary_af2e3e44-a8f8-45ac-9f31-4093eb897600
HealthState : Warning
SequenceNumber : 131445250939703027
SentAt : 7/14/2017 4:58:13 PM
ReceivedAt : 7/14/2017 4:58:14 PM
TTL : 00:01:05
Description : The Load Balancer was unable to find a placement for one or more of the Service's Replicas:
Secondary replica could not be placed due to the following constraints and properties:
TargetReplicaSetSize: 7
Placement Constraint: N/A
Parent Service: N/A
Constraint Elimination Sequence:
Existing Secondary Replicas eliminated 4 possible node(s) for placement -- 1/5 node(s) remain.
Existing Primary Replica eliminated 1 possible node(s) for placement -- 0/5 node(s) remain.
Nodes Eliminated By Constraints:
Existing Secondary Replicas -- Nodes with Partition's Existing Secondary Replicas/Instances:
--
FaultDomain:fd:/4 NodeName:_Node_4 NodeType:NodeType4 UpgradeDomain:4 UpgradeDomain: ud:/4 Deactivation Intent/Status: None/None
FaultDomain:fd:/3 NodeName:_Node_3 NodeType:NodeType3 UpgradeDomain:3 UpgradeDomain: ud:/3 Deactivation Intent/Status: None/None
FaultDomain:fd:/2 NodeName:_Node_2 NodeType:NodeType2 UpgradeDomain:2 UpgradeDomain: ud:/2 Deactivation Intent/Status: None/None
FaultDomain:fd:/1 NodeName:_Node_1 NodeType:NodeType1 UpgradeDomain:1 UpgradeDomain: ud:/1 Deactivation Intent/Status: None/None
Existing Primary Replica -- Nodes with Partition's Existing Primary Replica or Secondary Replicas:
--
FaultDomain:fd:/0 NodeName:_Node_0 NodeType:NodeType0 UpgradeDomain:0 UpgradeDomain: ud:/0 Deactivation Intent/Status: None/None
RemoveWhenExpired : True
IsExpired : False
Transitions : Error->Warning = 7/14/2017 4:56:14 PM, LastOk = 1/1/0001 12:00:00 AM
PS C:\> Get-ServiceFabricPartition fabric:/WordCount/WordCountService | select MinReplicaSetSize,TargetReplicaSetSize
MinReplicaSetSize TargetReplicaSetSize
----------------- --------------------
2 7
PS C:\> @(Get-ServiceFabricNode).Count
5
O exemplo a seguir mostra a integridade de uma partição que está presa na reconfiguração devido ao usuário não honrar o token de cancelamento no método RunAsync . Investigar o relatório de integridade de qualquer réplica marcada como primária (P) pode ajudar a aprofundar o problema.
PS C:\utilities\ServiceFabricExplorer\ClientPackage\lib> Get-ServiceFabricPartitionHealth 0e40fd81-284d-4be4-a665-13bc5a6607ec -ExcludeHealthStatistics
PartitionId : 0e40fd81-284d-4be4-a665-13bc5a6607ec
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.FM', Property='State', HealthState='Warning',
ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.FM
Property : State
HealthState : Warning
SequenceNumber : 7
SentAt : 8/27/2017 3:43:09 AM
ReceivedAt : 8/27/2017 3:43:32 AM
TTL : Infinite
Description : Partition reconfiguration is taking longer than expected.
fabric:/app/test1 3 1 0e40fd81-284d-4be4-a665-13bc5a6607ec
P/S Ready Node1 131482789658160654
S/P Ready Node2 131482789688598467
S/S Ready Node3 131482789688598468
(Showing 3 out of 3 replicas. Total available replicas: 3)
For more information see: https://aka.ms/sfhealth
RemoveWhenExpired : False
IsExpired : False
Transitions : Ok->Warning = 8/27/2017 3:43:32 AM, LastError = 1/1/0001 12:00:00 AM
Este relatório de saúde mostra o estado das réplicas da partição que está a ser reconfigurada:
P/S Ready Node1 131482789658160654
S/P Ready Node2 131482789688598467
S/S Ready Node3 131482789688598468
Para cada réplica, o relatório de integridade contém:
- Função de configuração anterior
- Função de configuração atual
- Estado da réplica
- Nó no qual a réplica está sendo executada
- ID da réplica
Num caso como o exemplo, é necessária uma investigação mais aprofundada. Investigue a integridade de cada réplica individual começando com as réplicas marcadas como Primary e Secondary (131482789658160654 e 131482789688598467) no exemplo anterior.
Violação de restrição de réplica
System.PLB emite um aviso se detetar uma violação de restrição de réplica e não conseguir localizar todas as réplicas de partição. Os detalhes do relatório mostram quais restrições e propriedades impedem o posicionamento da réplica.
- SourceId: System.PLB
- Property: Começa com ReplicaConstraintViolation.
Relatórios sobre o estado do sistema de réplica
System.RA, que representa o componente do agente de reconfiguração, é a autoridade sobre o estado da réplica.
Estado
System.RA indica êxito quando a réplica está criada.
- Fonte: System.RA
- Propriedade: Estado.
O exemplo a seguir mostra uma réplica íntegra:
PS C:\> Get-ServiceFabricPartition fabric:/WordCount/WordCountService | Get-ServiceFabricReplica | where {$_.ReplicaRole -eq "Primary"} | Get-ServiceFabricReplicaHealth
PartitionId : af2e3e44-a8f8-45ac-9f31-4093eb897600
ReplicaId : 131444422293118721
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.RA
Property : State
HealthState : Ok
SequenceNumber : 131445248920273536
SentAt : 7/14/2017 4:54:52 PM
ReceivedAt : 7/14/2017 4:55:13 PM
TTL : Infinite
Description : Replica has been created._Node_0
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:13 PM, LastWarning = 1/1/0001 12:00:00 AM
ReplicaOpenStatus, ReplicaCloseStatus, ReplicaChangeRoleStatus
Essa propriedade é usada para indicar avisos ou falhas ao tentar abrir uma réplica, fechar uma réplica ou fazer a transição de uma réplica de uma função para outra. Para obter mais informações, consulte Ciclo de vida da réplica. As falhas podem ser exceções lançadas das chamadas de API ou falhas do processo de host de serviço durante esse período. Para falhas resultantes de chamadas de API no código C#, o Service Fabric adiciona a exceção e o rastreamento de pilha ao relatório de integridade.
Estas advertências de saúde são emitidas depois de repetir a ação localmente um número de vezes (dependendo da política). O Service Fabric tenta novamente a ação até um limite máximo. Depois de atingido o limite máximo, poderá tentar agir para corrigir a situação. Essa tentativa pode fazer com que esses avisos sejam apagados, pois ele desiste da ação nesse nó. Por exemplo, se uma réplica não estiver a abrir num nó, o Service Fabric emite um aviso de saúde. Se a réplica continuar a falhar ao abrir-se, o Service Fabric atuará para se reparar. Essa ação pode envolver a tentativa da mesma operação em outro nó. Esta tentativa faz com que o aviso gerado para esta réplica seja eliminado.
- Fonte: System.RA
- Propriedade: ReplicaOpenStatus, ReplicaCloseStatus e ReplicaChangeRoleStatus.
- Próximas etapas: analise o código de serviço ou os registos de falhas para identificar porque a operação está falhando.
O exemplo a seguir mostra a integridade de uma réplica que está a gerar TargetInvocationException a partir do seu método "open". A descrição contém o ponto de falha, IStatefulServiceReplica.Open, o tipo de exceção TargetInvocationException e o rasto da pilha.
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId 337cf1df-6cab-4825-99a9-7595090c0b1b -ReplicaOrInstanceId 131483509874784794
PartitionId : 337cf1df-6cab-4825-99a9-7595090c0b1b
ReplicaId : 131483509874784794
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.RA', Property='ReplicaOpenStatus', HealthState='Warning',
ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : ReplicaOpenStatus
HealthState : Warning
SequenceNumber : 131483510001453159
SentAt : 8/27/2017 11:43:20 PM
ReceivedAt : 8/27/2017 11:43:21 PM
TTL : Infinite
Description : Replica had multiple failures during open on _Node_0 API call: IStatefulServiceReplica.Open(); Error = System.Reflection.TargetInvocationException (-2146232828)
Exception has been thrown by the target of an invocation.
at Microsoft.ServiceFabric.Replicator.RecoveryManager.d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Replicator.LoggingReplicator.d__137.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Replicator.DynamicStateManager.d__109.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Replicator.TransactionalReplicator.d__79.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Replicator.StatefulServiceReplica.d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Services.Runtime.StatefulServiceReplicaAdapter.d__0.MoveNext()
For more information see: https://aka.ms/sfhealth
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 8/27/2017 11:43:21 PM, LastOk = 1/1/0001 12:00:00 AM
O exemplo a seguir mostra uma réplica que está constantemente falhando durante o fechamento:
C:>Get-ServiceFabricReplicaHealth -PartitionId dcafb6b7-9446-425c-8b90-b3fdf3859e64 -ReplicaOrInstanceId 131483565548493142
PartitionId : dcafb6b7-9446-425c-8b90-b3fdf3859e64
ReplicaId : 131483565548493142
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.RA', Property='ReplicaCloseStatus', HealthState='Warning',
ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : ReplicaCloseStatus
HealthState : Warning
SequenceNumber : 131483565611258984
SentAt : 8/28/2017 1:16:01 AM
ReceivedAt : 8/28/2017 1:16:03 AM
TTL : Infinite
Description : Replica had multiple failures during close on _Node_1. The application
host has crashed.
For more information see: https://aka.ms/sfhealth
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 8/28/2017 1:16:03 AM, LastOk = 1/1/0001 12:00:00 AM
Reconfiguração
Essa propriedade é usada para indicar quando uma réplica que executa uma reconfiguração deteta que a reconfiguração está parada ou presa. Esse relatório de integridade pode estar na réplica cuja função atual é primária, exceto nos casos de uma reconfiguração primária de troca, em que pode estar na réplica que está sendo rebaixada de primária para secundária ativa.
A reconfiguração pode ser bloqueada por um dos seguintes motivos:
Uma ação na réplica local, a mesma réplica que executa a reconfiguração, não está sendo concluída. Nesse caso, investigar os relatórios de saúde nesta réplica de outros componentes, como o System.RAP ou o System.RE, pode fornecer informações adicionais.
Uma ação não está sendo concluída em uma réplica remota. As réplicas para as quais as ações estão pendentes são listadas no relatório de estado de integridade. Deve ser realizada uma investigação mais aprofundada nos relatórios de saúde para essas réplicas remotas. Também pode haver problemas de comunicação entre esse nó e o nó remoto.
Em casos raros, a reconfiguração pode ser bloqueada devido a problemas de comunicação ou outros problemas entre esse nó e o serviço Gerenciador de Failover.
- Fonte: System.RA
- Propriedade: Reconfiguração.
- Próximas etapas: Examine réplicas locais ou remotas dependendo da descrição do relatório de estado.
O exemplo a seguir mostra um relatório de saúde onde uma reconfiguração está bloqueada na réplica local. Neste exemplo, é devido a um serviço que não honra o token de cancelamento.
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId 9a0cedee-464c-4603-abbc-1cf57c4454f3 -ReplicaOrInstanceId 131483600074836703
PartitionId : 9a0cedee-464c-4603-abbc-1cf57c4454f3
ReplicaId : 131483600074836703
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.RA', Property='Reconfiguration', HealthState='Warning',
ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : Reconfiguration
HealthState : Warning
SequenceNumber : 131483600309264482
SentAt : 8/28/2017 2:13:50 AM
ReceivedAt : 8/28/2017 2:13:57 AM
TTL : Infinite
Description : Reconfiguration is stuck. Waiting for response from the local replica
For more information see: https://aka.ms/sfhealth
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 8/28/2017 2:13:57 AM, LastOk = 1/1/0001 12:00:00 AM
O exemplo a seguir mostra um relatório de saúde em que uma reconfiguração está bloqueada à espera de resposta de duas réplicas remotas. Neste exemplo, há três réplicas na partição, incluindo a primária atual.
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId 579d50c6-d670-4d25-af70-d706e4bc19a2 -ReplicaOrInstanceId 131483956274977415
PartitionId : 579d50c6-d670-4d25-af70-d706e4bc19a2
ReplicaId : 131483956274977415
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.RA', Property='Reconfiguration', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : Reconfiguration
HealthState : Warning
SequenceNumber : 131483960376212469
SentAt : 8/28/2017 12:13:57 PM
ReceivedAt : 8/28/2017 12:14:07 PM
TTL : Infinite
Description : Reconfiguration is stuck. Waiting for response from 2 replicas
Pending Replicas:
P/I Down 40 131483956244554282
S/S Down 20 131483956274972403
For more information see: https://aka.ms/sfhealth
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 8/28/2017 12:07:37 PM, LastOk = 1/1/0001 12:00:00 AM
Este relatório de integridade mostra que a reconfiguração está bloqueada aguardando uma resposta de duas réplicas:
P/I Down 40 131483956244554282
S/S Down 20 131483956274972403
Para cada réplica, são fornecidas as seguintes informações:
- Função de configuração anterior
- Função de configuração atual
- Estado da réplica
- ID do Nó
- ID da réplica
Para desbloquear a reconfiguração:
- As réplicas inativas devem ser ativadas.
- As réplicas em construção devem concluir a compilação e transitar para o estado pronto.
Chamada de API de serviço lenta
System.RAP e System.Replicator relatam um aviso se uma chamada para o código de serviço do usuário demorar mais do que o tempo configurado. O aviso é apagado quando a chamada é concluída.
- SourceId: System.RAP ou System.Replicator
- Propriedade: O nome da API lenta. A descrição fornece mais detalhes sobre o tempo que a API está pendente.
- Próximas etapas: investigue por que a chamada demora mais do que o esperado.
O exemplo a seguir mostra o evento de estado de saúde de System.RAP relativo a um serviço confiável que não está honrando o token de cancelamento em RunAsync:
PS C:\> Get-ServiceFabricReplicaHealth -PartitionId 5f6060fb-096f-45e4-8c3d-c26444d8dd10 -ReplicaOrInstanceId 131483966141404693
PartitionId : 5f6060fb-096f-45e4-8c3d-c26444d8dd10
ReplicaId : 131483966141404693
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.RA', Property='Reconfiguration', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RAP
Property : IStatefulServiceReplica.ChangeRole(S)Duration
HealthState : Warning
SequenceNumber : 131483966663476570
SentAt : 8/28/2017 12:24:26 PM
ReceivedAt : 8/28/2017 12:24:56 PM
TTL : Infinite
Description : The api IStatefulServiceReplica.ChangeRole(S) on _Node_1 is stuck. Start Time (UTC): 2017-08-28 12:23:56.347.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Warning = 8/28/2017 12:24:56 PM, LastOk = 1/1/0001 12:00:00 AM
A propriedade e o texto indicam qual API está bloqueada. Os próximos passos a seguir para cada tipo de API bloqueada são distintos. Qualquer API no IStatefulServiceReplica ou IStatelessServiceInstance geralmente é um bug no código de serviço. A seção a seguir descreve como eles se traduzem para o modelo de Serviços Confiáveis:
IStatefulServiceReplica.Open: Este aviso indica que uma chamada para
CreateServiceInstanceListeners,ICommunicationListener.OpenAsyncou, se substituída,OnOpenAsyncestá bloqueada.IStatefulServiceReplica.Close e IStatefulServiceReplica.Abort: O caso mais comum é um serviço que não respeita o token de cancelamento passado para
RunAsync. Também pode ser queICommunicationListener.CloseAsync, ou se tiver sido substituído,OnCloseAsyncesteja preso.IStatefulServiceReplica.ChangeRole(S) e IStatefulServiceReplica.ChangeRole(N)
RunAsync. Nesse cenário, a melhor solução é reiniciar a réplica.IStatefulServiceReplica.ChangeRole(P): O caso mais comum é que o serviço não retornou uma tarefa do
RunAsync.
Outras chamadas de API que podem ficar bloqueadas estão na interface do IReplicator . Por exemplo:
IReplicator.CatchupReplicaSet: Este aviso indica uma de duas coisas. Há réplicas insuficientes. Para ver se este é o caso, examine o estado das réplicas na partição ou o relatório de integridade do System.FM relativo a uma reconfiguração bloqueada. Ou as réplicas não estão reconhecendo operações. O cmdlet
Get-ServiceFabricDeployedReplicaDetaildo PowerShell pode ser usado para determinar o progresso de todas as réplicas. O problema está nas réplicas cujoLastAppliedReplicationSequenceNumbervalor fica atrás do valor doCommittedSequenceNumberprimário.IReplicator.BuildReplica(<Remote ReplicaId>): Este aviso indica um problema no processo de compilação. Para obter mais informações, consulte Ciclo de vida da réplica. Pode ser devido a uma configuração incorreta do endereço do replicador. Para obter mais informações, consulte Configurar serviços confiáveis com estado e Especificar recursos num manifesto de serviço. Também pode ser um problema no nó remoto.
Relatórios de integridade do sistema replicador
Fila de replicação cheia:System.Replicator relata um aviso quando a fila de replicação está cheia. Na principal, a fila de replicação geralmente fica cheia porque uma ou mais réplicas secundárias demoram a reconhecer as operações. No secundário, isso geralmente acontece quando o serviço demora a aplicar as operações. O aviso é apagado quando a fila não está mais cheia.
- SourceId: System.Replicator
- Propriedade: PrimaryReplicationQueueStatus ou SecondaryReplicationQueueStatus, dependendo da função de réplica.
- Próximas etapas: Se o relatório estiver no primário, verifique a conexão entre os nós no cluster. Se todas as conexões estiverem íntegras, pode haver pelo menos um secundário lento com alta latência de disco para aplicar operações. Se o relatório estiver no servidor secundário, verifique o uso e o desempenho do disco no nó primeiro. Em seguida, verifique a conexão de saída do nó lento para o principal.
RemoteReplicatorConnectionStatus:System.Replicator na réplica primária emite um aviso quando a conexão com um replicador secundário (remoto) não está saudável. O endereço do replicador remoto é mostrado na mensagem do relatório, o que torna mais conveniente detetar se a configuração errada foi passada ou se há problemas de rede entre os replicadores.
- SourceId: System.Replicator
- Propriedade: RemoteReplicatorConnectionStatus.
- Próximas etapas: Verifique a mensagem de erro e verifique se o endereço do replicador remoto está configurado corretamente. Por exemplo, se o replicador remoto for aberto com o endereço de escuta "localhost", ele não poderá ser acessado do lado de fora. Se o endereço parecer correto, verifique a conexão entre o nó primário e o endereço remoto para encontrar possíveis problemas de rede.
Fila de replicação cheia
System.Replicator relata um aviso quando a fila de replicação está cheia. No primário, a fila de replicação geralmente fica cheia porque uma ou mais réplicas secundárias demoram a reconhecer as operações. No secundário, isso geralmente acontece quando o serviço demora a aplicar as operações. O aviso é apagado quando a fila não está mais cheia.
- SourceId: System.Replicator
- Propriedade: PrimaryReplicationQueueStatus ou SecondaryReplicationQueueStatus, dependendo da função de réplica.
Operações lentas de nomenclatura
System.NamingService reporta o estado da réplica principal quando uma operação de nomenclatura demora mais do que o permitido. Exemplos de operações de nomeação são CreateServiceAsync ou DeleteServiceAsync. Mais métodos podem ser encontrados em FabricClient. Por exemplo, eles podem ser encontrados em métodos de gerenciamento de serviço ou métodos de gerenciamento de propriedade.
Observação
O serviço de Nomeação resolve nomes de serviço para um local dentro do cluster. Os usuários podem usá-lo para gerenciar nomes de serviço e propriedades. É um serviço do tipo particionado e persistente no Service Fabric. Uma das partições representa a Autoridade Responsável, que contém metadados sobre todos os nomes e serviços do Service Fabric. Os nomes do Service Fabric são mapeados para partições diferentes, denominadas partições Name Owner, tornando, assim, o serviço extensível. Leia mais sobre o serviço de nomenclatura.
Quando uma operação de Nomeação leva mais tempo do que o esperado, a operação é sinalizada com um relatório de aviso na réplica primária da partição do serviço de Nomeação que serve a operação. Se a operação for concluída com êxito, o aviso será apagado. Se a operação for concluída com um erro, o relatório de estado incluirá detalhes sobre o erro.
- SourceId: System.NamingService
- Propriedade: Começa com o prefixo "Duration_" e identifica a operação lenta e o nome do Service Fabric no qual a operação é aplicada. Por exemplo, se a criação do serviço no nome fabric:/MyApp/MyService demorar muito, a propriedade será Duration_AOCreateService.fabric:/MyApp/MyService. "AO" aponta para a função da partição de nomenclatura para esse nome e operação.
- Próximas etapas: Verifique por que a operação de nomeação falha. Cada operação pode ter diferentes causas raiz. Por exemplo, o serviço de eliminação poderá estar bloqueado. O serviço pode estar a falhar porque o anfitrião da aplicação continua a falhar num nó devido a um bug do utilizador no código do serviço.
O exemplo a seguir mostra uma operação de criação de serviço. A operação demorou mais do que a duração configurada. "AO" tenta novamente e envia trabalho para "NÃO". "NÃO" concluiu a última operação com TIMEOUT. Nesse caso, a mesma réplica é primária para as funções "AO" e "NO".
PartitionId : 00000000-0000-0000-0000-000000001000
ReplicaId : 131064359253133577
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.NamingService', Property='Duration_AOCreateService.fabric:/MyApp/MyService', HealthState='Warning', ConsiderWarningAsError=false.
HealthEvents :
SourceId : System.RA
Property : State
HealthState : Ok
SequenceNumber : 131064359308715535
SentAt : 4/29/2016 8:38:50 PM
ReceivedAt : 4/29/2016 8:39:08 PM
TTL : Infinite
Description : Replica has been created.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 4/29/2016 8:39:08 PM, LastWarning = 1/1/0001 12:00:00 AM
SourceId : System.NamingService
Property : Duration_AOCreateService.fabric:/MyApp/MyService
HealthState : Warning
SequenceNumber : 131064359526778775
SentAt : 4/29/2016 8:39:12 PM
ReceivedAt : 4/29/2016 8:39:38 PM
TTL : 00:05:00
Description : The AOCreateService started at 2016-04-29 20:39:08.677 is taking longer than 30.000.
RemoveWhenExpired : True
IsExpired : False
Transitions : Error->Warning = 4/29/2016 8:39:38 PM, LastOk = 1/1/0001 12:00:00 AM
SourceId : System.NamingService
Property : Duration_NOCreateService.fabric:/MyApp/MyService
HealthState : Warning
SequenceNumber : 131064360657607311
SentAt : 4/29/2016 8:41:05 PM
ReceivedAt : 4/29/2016 8:41:08 PM
TTL : 00:00:15
Description : The NOCreateService started at 2016-04-29 20:39:08.689 completed with FABRIC_E_TIMEOUT in more than 30.000.
RemoveWhenExpired : True
IsExpired : False
Transitions : Error->Warning = 4/29/2016 8:39:38 PM, LastOk = 1/1/0001 12:00:00 AM
Relatórios de integridade do sistema DeployedApplication
System.Hosting é a autoridade sobre entidades implantadas.
Ativação
System.Hosting assinala como OK quando uma aplicação foi ativada com êxito no nó. Caso contrário, ele relata um erro.
- SourceId: System.Hosting
- Propriedade: Ativação, incluindo a versão de lançamento.
- Próximas etapas: Se o aplicativo não estiver íntegro, investigue por que a ativação falhou.
O exemplo a seguir mostra uma ativação bem-sucedida:
PS C:\> Get-ServiceFabricDeployedApplicationHealth -NodeName _Node_1 -ApplicationName fabric:/WordCount -ExcludeHealthStatistics
ApplicationName : fabric:/WordCount
NodeName : _Node_1
AggregatedHealthState : Ok
DeployedServicePackageHealthStates :
ServiceManifestName : WordCountServicePkg
ServicePackageActivationId :
NodeName : _Node_1
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.Hosting
Property : Activation
HealthState : Ok
SequenceNumber : 131445249083836329
SentAt : 7/14/2017 4:55:08 PM
ReceivedAt : 7/14/2017 4:55:14 PM
TTL : Infinite
Description : The application was activated successfully.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:14 PM, LastWarning = 1/1/0001 12:00:00 AM
Baixar
System.Hosting relata um erro se o download do pacote do aplicativo falhar.
- SourceId: System.Hosting
- Propriedade: Download, incluindo a versão de lançamento.
- Próximas etapas: investigue por que o download falhou no nó.
Relatórios de integridade do sistema DeployedServicePackage
System.Hosting é a autoridade sobre entidades implantadas.
Ativação do pacote de serviço
System.Hosting informa que está OK se a ativação do pacote de serviço for bem-sucedida no nó. Caso contrário, ele relata um erro.
- SourceId: Sistema.Alojamento
- Propriedade: Ativação.
- Próximas etapas: investigue por que a ativação falhou.
Ativação do pacote de código
System.Hosting relata como OK para cada pacote de código se a ativação for bem-sucedida. Se a ativação falhar, ele relatará um aviso conforme configurado. Se CodePackage não for ativado ou terminar com um erro maior do que o CodePackageHealthErrorThreshold configurado, a hospedagem relatará um erro. Se um pacote de serviço contiver vários pacotes de código, um relatório de ativação será gerado para cada um deles.
- SourceId: System.Hosting
- Property: Usa o prefixo CodePackageActivation e contém o nome do pacote de código e o ponto de entrada como CodePackageActivation:CodePackageName:SetupEntryPoint/EntryPoint. Por exemplo, CodePackageActivation:Code:SetupEntryPoint.
Registo de tipo de serviço
System.Hosting informa como OK se o tipo de serviço tiver sido registrado com êxito. Ele relata um erro se o registro não foi feito a tempo, conforme configurado usando ServiceTypeRegistrationTimeout. Se o tempo de execução for fechado, o tipo de serviço não será registrado do nó e a hospedagem relatará um aviso.
- SourceId: System.Hosting
- Property: Usa o prefixo ServiceTypeRegistration e contém o nome do tipo de serviço. Por exemplo, ServiceTypeRegistration:FileStoreServiceType.
O exemplo a seguir mostra um pacote de serviço implantado íntegro:
PS C:\> Get-ServiceFabricDeployedServicePackageHealth -NodeName _Node_1 -ApplicationName fabric:/WordCount -ServiceManifestName WordCountServicePkg
ApplicationName : fabric:/WordCount
ServiceManifestName : WordCountServicePkg
ServicePackageActivationId :
NodeName : _Node_1
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.Hosting
Property : Activation
HealthState : Ok
SequenceNumber : 131445249084026346
SentAt : 7/14/2017 4:55:08 PM
ReceivedAt : 7/14/2017 4:55:14 PM
TTL : Infinite
Description : The ServicePackage was activated successfully.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:14 PM, LastWarning = 1/1/0001 12:00:00 AM
SourceId : System.Hosting
Property : CodePackageActivation:Code:EntryPoint
HealthState : Ok
SequenceNumber : 131445249084306362
SentAt : 7/14/2017 4:55:08 PM
ReceivedAt : 7/14/2017 4:55:14 PM
TTL : Infinite
Description : The CodePackage was activated successfully.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:14 PM, LastWarning = 1/1/0001 12:00:00 AM
SourceId : System.Hosting
Property : ServiceTypeRegistration:WordCountServiceType
HealthState : Ok
SequenceNumber : 131445249088096842
SentAt : 7/14/2017 4:55:08 PM
ReceivedAt : 7/14/2017 4:55:14 PM
TTL : Infinite
Description : The ServiceType was registered successfully.
RemoveWhenExpired : False
IsExpired : False
Transitions : Error->Ok = 7/14/2017 4:55:14 PM, LastWarning = 1/1/0001 12:00:00 AM
Baixar
System.Hosting relata um erro se o download do pacote de serviço falhar.
- SourceId: System.Hosting
- Propriedade: Download, incluindo a versão de lançamento.
- Próximas etapas: investigue por que o download falhou no nó.
Validação de atualização
System.Hosting reporta um erro se a validação durante a atualização falhar ou se a atualização falhar no nó.
- SourceId: System.Hosting
- Propriedade: Usa o prefixo FabricUpgradeValidation e contém a versão de atualização.
- Descrição: aponta para o erro encontrado.
Capacidade indefinida do nó para métricas de governança de recursos
System.Hosting emite um aviso se as capacidades do nó não estiverem definidas no manifesto do cluster e a configuração para deteção automática estiver desativada. O Service Fabric gera um aviso de saúde sempre que o pacote de serviço que utiliza a governança de recursos se regista num nó especificado.
- SourceId: System.Hosting
- Propriedade: Governação de Recursos.
- Próximas etapas: A maneira preferida de superar esse problema é alterar o manifesto do cluster para habilitar a deteção automática dos recursos disponíveis. Outra maneira é atualizar o manifesto do cluster com capacidades de nó especificadas corretamente para essas métricas.