Use system health reports to troubleshoot (Utilizar relatórios de estado de funcionamento do sistema para resolver problemas)
Os componentes do Azure Service Fabric fornecem relatórios de integridade do sistema em todas as entidades no cluster prontos para uso. O armazenamento de integridade cria e exclui entidades com base nos relatórios do sistema. Ele também os organiza em uma hierarquia que captura as interações da entidade.
Nota
Para entender os conceitos relacionados à integridade, leia mais em Modelo de integridade 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.
Nota
Os relatórios de integridade enviados por vigilantes do usuário são visíveis somente depois que os componentes do sistema criam uma entidade. Quando uma entidade é excluída, o armazenamento de integridade exclui automaticamente todos os relatórios de integridade associados a ela. O mesmo é verdadeiro quando uma nova instância da entidade é criada. Um exemplo é quando uma nova instância de réplica de serviço persistente com monitoração de estado é criada. Todos os relatórios associados à instância antiga são excluídos e limpos do armazenamento.
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.
Nota
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 é criada automaticamente no repositório de integridade. Se tudo funcionar corretamente, ele não tem um relatório do sistema.
Perda de vizinhança
System.Federation relata um erro quando deteta uma perda de bairro. O relatório é de nós individuais e o ID do nó 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 se perderem, há mais eventos.
O relatório especifica o tempo limite de locação global como o tempo de vida útil (TTL). O relatório é enviado a cada metade da duração do TTL enquanto a condição permanecer ativa. O evento é removido automaticamente quando expira. O comportamento Remover quando expirou garante que o relatório seja limpo do repositório de integridade corretamente, mesmo que o nó de relatório esteja inativo.
- SourceId: System.Federation
- Propriedade: Começa com Bairro e inclui informações do nó.
- Próximos passos: Investigar por que o bairro está perdido. Por exemplo, verifique a comunicação entre nós de 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 principal do FMM é sempre o nó com o ID mais próximo de 0. Se esse nó for descartado, uma reconstrução será acionada. 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.
Aguardando nós: FM/FMM já recebeu uma resposta de transmissão dos outros nós e está aguardando uma resposta de nós específicos. O relatório de integridade lista os nós para os quais o FM/FMM está aguardando uma resposta.
- Próximas etapas: Investigue a conexão de rede entre o FM/FMM e os nós listados. Investigue cada nó listado para outros possíveis problemas.
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 de propagação não estiverem íntegros. Os nós de propagação 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 semente estiver inativa no cluster e não forem trazidos de volta, o cluster será desligado automaticamente.
Um nó semente não estará íntegro se o status do nó for Inativo, Removido ou Desconhecido. O relatório de aviso para o status do nó de semente listará todos os nós de semente não íntegros 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 descendentes. Se necessário, adicione mais nós ao tipo de nó primário para conseguir isso. 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 íntegros, diferentes ações precisam ser tomadas: se o nó de semente estiver inativo, os usuários precisam trazer esse nó de semente para cima; se o nó semente for Removido ou Desconhecido, esse nó 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 de propagação se tornem íntegros antes de limpar o relatório: se o nó de semente estiver inativo, os usuários precisarão trazer esse nó de semente para cima; se o nó semente for Removido ou Desconhecido, esse nó semente precisará ser removido do cluster. Depois que todos os nós de propagação 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 sistema de nó
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 removidas quando o estado do nó é removido. Para obter mais informações, consulte RemoveNodeStateAsync.
Nó para cima/para baixo
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 integridade criada pelo repositório de integridade 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 por meio de consultas se o nó for relatado como ativo por System.FM, com a mesma instância que a instância associada às entidades. Quando System.FM relata que o nó está inativo ou reiniciado, como uma nova instância, o armazenamento de integridade limpa automaticamente as entidades implantadas que podem existir somente no nó inativo ou na instância anterior do nó.
- Fonte: System.FM
- Imóvel: Estado.
- Próximas etapas: Se o nó estiver inativo para uma atualização, ele deverá voltar a subir depois de ter sido atualizado. Nesse caso, o estado de integridade 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 deteta uma violação de capacidade do nó.
- SourceId: System.PLB
- Propriedade: Começa com Capacidade.
- Próximas etapas: Verifique as métricas fornecidas e visualize a capacidade atual no nó.
Incompatibilidade de capacidade de 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 (núcleos de memória e CPU). Um relatório de integridade aparece quando o primeiro pacote de serviço que usa a governança de recursos registra em um nó especificado.
- SourceId: System.Hosting
- Propriedade: ResourceGovernance.
- 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 aplicativos
System.CM, que representa o serviço Gerenciador de Cluster, é a autoridade que gerencia informações sobre um aplicativo.
Estado
System.CM relatórios como OK quando o aplicativo foi criado ou atualizado. Ele informa o armazenamento de saúde quando o aplicativo é excluído para que possa ser removido do armazenamento.
- Fonte: System.CM
- Imóvel: 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 -ApplicationName applicationName.
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 integridade do sistema de serviço
System.FM, que representa o serviço Gerenciador de Failover, é a autoridade que gerencia informações sobre serviços.
Estado
System.FM relatórios como OK quando o serviço tiver sido criado. Ele exclui a entidade do armazenamento de integridade 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: ServiceDescription.
- 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. Ele exclui a entidade do armazenamento de integridade quando a partição é excluída.
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, ela relatará 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
- Imóvel: 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 integridade na réplica primária fornecerá informações adicionais.
Para outros relatórios de integridade System.FM, haveria relatórios sobre as réplicas ou a partição ou serviço de outros componentes do sistema.
Os exemplos a seguir descrevem alguns desses relatórios.
O exemplo a seguir mostra uma partição íntegra:
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 integridade de uma partição que está abaixo da contagem de réplicas de destino. 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 integridade mostra o estado das réplicas da partição que está sendo 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 relata um aviso se detetar uma violação de restrição de réplica e não puder colocar 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 de integridade do sistema de réplica
System.RA, que representa o componente do agente de reconfiguração, é a autoridade para o estado da réplica.
Estado
System.RA relata OK quando a réplica foi criada.
- Fonte: System.RA
- Imóvel: 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 devido a chamadas de API do 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 abrindo em um nó, o Service Fabric gerará um aviso de integridade. Se a réplica continuar a falhar ao abrir, o Service Fabric atuará para a autorreparação. Essa ação pode envolver a tentativa da mesma operação em outro nó. Essa tentativa faz com que o aviso gerado para essa réplica seja limpo.
- Fonte: System.RA
- Propriedade: ReplicaOpenStatus, ReplicaCloseStatus e ReplicaChangeRoleStatus.
- Próximas etapas: investigue o código de serviço ou despejos de memória para identificar por que a operação está falhando.
O exemplo a seguir mostra a integridade de uma réplica que está sendo TargetInvocationException lançada a partir de seu método aberto. A descrição contém o ponto de falha, IStatefulServiceReplica.Open, o tipo de exceção TargetInvocationException e o rastreamento de 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 integridade nessa réplica de outros componentes, System.RAP ou 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 integridade. Uma investigação mais aprofundada deve ser feita em 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: investigue réplicas locais ou remotas dependendo da descrição do relatório de integridade.
O exemplo a seguir mostra um relatório de integridade em que uma reconfiguração está presa 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 integridade em que uma reconfiguração está bloqueada aguardando uma 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 para baixo devem ser trazidas para cima.
- As réplicas incorporadas devem concluir a compilação e fazer a transição para prontas.
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 integridade de System.RAP para 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 ficou presa. As próximas etapas a serem tomadas para APIs presas diferentes são diferentes. 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 substituído,OnCloseAsyncestá preso.IStatefulServiceReplica.ChangeRole(S) e IStatefulServiceReplica.ChangeRole(N): O caso mais comum é um serviço que não respeita o token de cancelamento passado para
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 esse é o caso, examine o status da réplica das réplicas na partição ou o relatório de integridade do System.FM para 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 está por trá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 monitoração de estado e Especificar recursos em um 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 secundário, verifique primeiro o uso e o desempenho do disco no nó. Em seguida, verifique a conexão de saída do nó lento para o principal.
RemoteReplicatorConnectionStatus:System.Replicator na réplica primária relata um aviso quando a conexão com um replicador secundário (remoto) não está íntegra. 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. 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.
Operações de nomenclatura lenta
System.NamingService relata a integridade em sua réplica primária quando uma operação de nomeação leva mais tempo do que o aceitável. 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.
Nota
O serviço de Nomenclatura resolve nomes de serviço para um local no cluster. Os usuários podem usá-lo para gerenciar nomes de serviço e propriedades. É um serviço persistente particionado do Service Fabric. Uma das partições representa o Proprietário da Autoridade, 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, chamadas partições Name Owner , portanto, 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 de 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 integridade 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 create service at name 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 exclusão pode estar preso. O serviço pode estar preso porque o host do aplicativo continua falhando em um nó devido a um bug do usuário no código do serviço.
O exemplo a seguir mostra uma operação create service. 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 relata como OK quando um aplicativo foi ativado com êxito no nó. Caso contrário, ele relata um erro.
- SourceId: System.Hosting
- Propriedade: Ativação, incluindo a versão de distribuição.
- 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
Download
System.Hosting relata um erro se o download do pacote do aplicativo falhar.
- SourceId: System.Hosting
- Propriedade: Download, incluindo a versão de distribuição.
- 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 relata como OK se a ativação do pacote de serviço no nó for bem-sucedida. Caso contrário, ele relata um erro.
- SourceId: System.Hosting
- Imóvel: 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
Download
System.Hosting relata um erro se o download do pacote de serviço falhar.
- SourceId: System.Hosting
- Propriedade: Download, incluindo a versão de distribuição.
- Próximas etapas: investigue por que o download falhou no nó.
Validação de atualização
System.Hosting relata 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 de nó indefinida para métricas de governança de recursos
System.Hosting relata 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 integridade sempre que o pacote de serviço que usa a governança de recursos registra em um nó especificado.
- SourceId: System.Hosting
- Propriedade: ResourceGovernance.
- 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.