As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Métricas de integridade do cluster para solução de problemas
<a name="troubleshooting-v3-cluster-health-metrics"></a>

As métricas de integridade do cluster são adicionadas ao CloudWatch painel AWS ParallelCluster da Amazon a partir da AWS ParallelCluster versão 3.6.0. Nas seções a seguir, você vai aprender sobre as métricas de integridade do painel e sobre ações que você pode realizar para solucionar problemas.

**Topics**
+ [Visualizando o gráfico de **Erros de provisionamento de instâncias**](#troubleshooting-v3-cluster-health-metrics-instance-provisioning)
+ [Visualizando o gráfico de **Erros de instância não saudáveis**](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance)
+ [Visualizando o gráfico de **Tempo de inatividade da frota de computadores**](#troubleshooting-v3-cluster-health-metrics-idle-time-errors)

## Visualizando o gráfico de **Erros de provisionamento de instâncias**
<a name="troubleshooting-v3-cluster-health-metrics-instance-provisioning"></a>

Se você vir um valor diferente de zero no gráfico `Instance Provisioning Errors`, isso significará que a instância do Amazon EC2 para suporte de nós Slurm falhou ao iniciar na API `CreateFleet` ou `RunInstance`.

### Vendo `IAMPolicyErrors`
<a name="troubleshooting-v3-cluster-health-metrics-iam-policy"></a>
+ **O que aconteceu?**

  Várias instâncias falharam na inicialização, o que é causado por permissões insuficientes com código de erro `UnauthorizedOperation`.
+ **Como resolver?**

  Se você configurou um [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole) ou [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile) personalizado, verifique suas políticas do IAM e verifique se está usando as credenciais corretas.

  Verifique o arquivo `clustermgtd` para ver os detalhes do erro do nó estático. Verifique o arquivo `slurm_resume.log` para ver os detalhes do erro do nó dinâmico. Use os detalhes para saber mais sobre as permissões ausentes que devem ser adicionadas.

### Vendo `VcpuLimitErrors`
<a name="troubleshooting-v3-cluster-health-metrics-vcpu-limit"></a>
+ **O que aconteceu?**

  AWS ParallelCluster falhou ao iniciar instâncias porque atingiu o limite de vCPU Conta da AWS para um tipo específico de instância do Amazon EC2 que você configurou para nós de computação de cluster.
+ **Como resolver?**

  Verifique o erro `VcpuLimitExceeded` no arquivo `clustermgtd` para nós estáticos e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes adicionais. Para resolver esse problema, é possível solicitar um aumento nos limites da vCPU. Para ter mais informações sobre como visualizar limites atuais e solicitar novos limites, consulte [Service Quotas do Amazon Elastic Compute Cloud](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html) no *Guia do usuário do Amazon Elastic Compute Cloud para instâncias do Linux*.

### Vendo `VolumeLimitErrors`
<a name="troubleshooting-v3-cluster-health-metrics-volume-limit"></a>
+ **O que aconteceu?**

  Você atingiu o limite de volume do Amazon EBS e AWS ParallelCluster não consegue iniciar instâncias com código de erro `InsufficientVolumeCapacity` ou`VolumeLimitExceeded`. Conta da AWS
+ **Como resolver?**

  Verifique o arquivo `clustermgtd` para ver se há nós estáticos, e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes adicionais sobre limite de volume. Para resolver esse problema, você pode usar um outro Região da AWS, limpar os volumes existentes ou entrar em contato com o AWS Support Center para enviar uma solicitação para aumentar seu limite de volume do Amazon EBS.

### Vendo `InsufficientCapacityErrors`
<a name="troubleshooting-v3-cluster-health-metrics-ice"></a>
+ **O que aconteceu?**

  AWS ParallelCluster não tem capacidade suficiente para iniciar instâncias do Amazon EC2 em nós secundários.
+ **Como resolver?**

  Verifique se há nós estáticos no arquivo `clustermgtd` e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes de erro de capacidade insuficientes. Para solucionar o problema, siga as orientações em [https://aws.amazon.com/premiumsupport/knowledge-center/ec2](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) -/. insufficient-capacity-errors

### `OtherInstanceLaunchFailures`
<a name="troubleshooting-v3-cluster-health-metrics-other-launch-failures"></a>
+ **O que aconteceu?**

  A instância do Amazon EC2 para suportar os nós de computação falhou ao ser iniciada com a API `CreateFleet` ou `RunInstance`.
+ **Como resolver?**

  Verifique se há nós estáticos no arquivo `clustermgtd` e verifique se há nós dinâmicos no arquivo `slurm_resume.log` para obter detalhes do erro.

## Visualizando o gráfico de **Erros de instância não saudáveis**
<a name="troubleshooting-v3-cluster-health-metrics-unhealthy-instance"></a>
+ **O que aconteceu?**

  Várias instâncias de computação foram iniciadas, mas depois encerradas por não serem íntegras.
+ **Como resolver?**

  Para obter mais informações sobre solução de problemas de nós não saudáveis, consulte [**Solução de problemas inesperados de substituições e encerramentos de nós**](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations).

### Vendo `InstanceBootstrapTimeoutError`
<a name="troubleshooting-v3-cluster-health-metrics-bootstrap-timeout"></a>
+ **O que aconteceu?**

  Uma instância não pode se juntar ao cluster em `resume_timeout` (para nós dinâmicos) ou `node_replacement_timeout` (para nós estáticos). Isso pode ocorrer se a rede não estiver configurada corretamente para os nós de computação, ou se os scripts personalizados executados no nó de computação demorarem muito para serem concluídos.
+ **Como resolver?**

  Para nós dinâmicos, verifique no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) o endereço IP do nó de computação e erros como os seguintes:

  ```
  Node bootstrap error: Resume timeout expires for node
  ```

  Para nós estáticos, verifique no log `clustermgtd` (`/var/log/parallelcluster/clustermgtd`) o endereço IP do nó de computação e erros como os seguintes:

  ```
  Node bootstrap error: Replacement timeout expires for node ... in replacement.
  ```

  Para obter detalhes adicionais, verifique se há erros no arquivo `/var/log/cloud-init-output.log`. Você pode recuperar endereços IP de nós de computação problemáticos a partir dos arquivos de log `clustermgtd` e `slurm_resume`.

### Vendo `EC2HealthCheckErrors`
<a name="troubleshooting-v3-cluster-health-metrics-ec2-check"></a>
+ **O que aconteceu?**

  Uma instância falhou em uma verificação de integridade do Amazon EC2.
+ **Como resolver?**

  Para obter informações sobre como solucionar esse problema, consulte [Solução de problemas em instâncias com falha nas verificações de status](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html).

### Vendo `ScheduledEventHealthCheckErrors`
<a name="troubleshooting-v3-cluster-health-metrics-ec2-scheduled-event"></a>
+ **O que aconteceu?**

  Uma instância falhou em uma verificação de integridade de um evento agendado pelo Amazon EC2 e não está íntegra.
+ **Como resolver?**

  Para obter informações sobre como solucionar esse problema, consulte [Eventos programados para instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).

### Vendo `NoCorrespondingInstanceErrors`
<a name="troubleshooting-v3-cluster-health-metrics-missing-instances"></a>
+ **O que aconteceu?**

  AWS ParallelCluster não consigo encontrar instâncias de apoio aos nós. Os nós provavelmente terminaram automaticamente durante as operações de bootstrap. scripts [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions) / [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) ou erros de rede podem produzir`NoCorrespondingInstanceErrors`.
+ **Como resolver?**

  Para obter detalhes adicionais, consulte `/var/log/cloud-init-output.log` para ver o nó de computação.

## Visualizando o gráfico de **Tempo de inatividade da frota de computadores**
<a name="troubleshooting-v3-cluster-health-metrics-idle-time-errors"></a>

### Observando um `MaxDynamicNodeIdleTime` que é significativamente maior do que o limite de **redução do tempo de inatividade**
<a name="troubleshooting-v3-cluster-health-idle-time-threshold"></a>
+ **O que aconteceu?**

  Sua instância não está sendo encerrada corretamente. O `MaxDynamicNodeIdleTime` mostra o tempo máximo em segundos em que um nó dinâmico, apoiado por uma instância do Amazon EC2, fica ocioso. O limite de **redução do tempo de inatividade** é derivado do parâmetro [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) de configuração do cluster. Quando um nó de computação fica ocioso por mais de segundos do **Idle Time Scaledown**, desliga o nó e Slurm AWS ParallelCluster encerra a instância de backup. Nesse caso, algo está impedindo o encerramento da instância.
+ **Como resolver?**

  Para obter mais informações sobre esse problema, consulte [**Substituindo, encerrando ou desligando instâncias e nós problemáticos**](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3) em [Solucionar problemas de escala](troubleshooting-v3-scaling-issues.md).