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á. # Monitoramento AWS ParallelCluster e registros O monitoramento é uma parte importante da manutenção da confiabilidade, disponibilidade e desempenho de AWS ParallelCluster suas outras AWS soluções. AWS fornece as seguintes ferramentas de monitoramento para observar AWS ParallelCluster, relatar quando algo está errado e realizar ações automáticas quando apropriado: + *A Amazon CloudWatch* monitora seus AWS recursos e os aplicativos em que você executa AWS em tempo real. Você pode coletar e rastrear métricas, criar painéis personalizados e definir alarmes que o notificam ou que realizam ações quando uma métrica especificada atinge um limite definido. Por exemplo, você pode CloudWatch rastrear o uso da CPU ou outras métricas de suas EC2 instâncias da Amazon e iniciar automaticamente novas instâncias quando necessário. Para obter mais informações, consulte o [Guia CloudWatch do usuário da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). + *O Amazon CloudWatch Logs* permite que você monitore, armazene e acesse seus arquivos de log de EC2 instâncias da Amazon e de outras fontes. CloudTrail CloudWatch Os registros podem monitorar as informações nos arquivos de log e notificá-lo quando determinados limites forem atingidos. É possível também arquivar seus dados de log em armazenamento resiliente. Para obter mais informações, consulte o [Guia do usuário do Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/). + O *AWS CloudTrail* captura chamadas de API e eventos relacionados feitos por sua conta da Conta da AWS ou em nome dela e entrega os arquivos de log a um bucket do Amazon S3 que você especificar. Você pode identificar quais usuários e contas chamaram AWS, o endereço IP de origem de onde as chamadas foram feitas e quando elas ocorreram. Para mais informações, consulte o [Guia do usuário do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). + EventBridgeA *Amazon* é um serviço de ônibus de eventos sem servidor que facilita a conexão de seus aplicativos com dados de várias fontes. EventBridge fornece um fluxo de dados em tempo real de seus próprios aplicativos, aplicativos Software-as-a-Service (SaaS) e AWS serviços e encaminha esses dados para destinos como o Lambda. Isso permite monitorar eventos que ocorram em serviços e criem arquiteturas orientadas a eventos. Para obter mais informações, consulte o [Guia EventBridge do usuário da Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/). **Topics** + [Integração com Amazon CloudWatch Logs](cloudwatch-logs-v3.md) + [CloudWatch Painel da Amazon](cloudwatch-dashboard-v3.md) + [CloudWatch Alarmes da Amazon para métricas de cluster](cloudwatch-alarms-v3.md) + [AWS ParallelCluster rotação de log configurada](log-rotation-v3.md) + [Logs da CLI `pcluster`](troubleshooting-v3-pc-cli-logs.md) + [Registros de saída EC2 do console Amazon](console-logs-v3.md) + [Recupere registros de PCUI e tempo de execução AWS ParallelCluster](troubleshooting-v3-get-runtime-logs.md) + [Recuperando e preservando logs](troubleshooting-v3-get-logs.md) # Integração com Amazon CloudWatch Logs Para obter mais informações sobre CloudWatch registros, consulte o [Guia do usuário do Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/). Para configurar a integração do CloudWatch Logs, consulte a [`Monitoring`](Monitoring-v3.md)seção. Para saber como acrescentar registros personalizados à CloudWatch configuração usando`append-config`, consulte [Arquivos de configuração de vários CloudWatch agentes no Guia CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) *do usuário da Amazon*. ## CloudWatch Registros de cluster do Amazon Logs Um grupo de logs é criado para cada cluster com um nome, `/aws/parallelcluster/cluster-name-` (por exemplo, `/aws/parallelcluster/testCluster-202202050215`). Cada log (ou conjunto de logs, se o caminho contiver um `*`) em cada nó possui um fluxo de logs denominado `{hostname}.{instance_id}.{logIdentifier}`. (Por exemplo, `ip-172-31-10-46.i-02587cf29cc3048f3.nodewatcher`). Os dados de log são enviados CloudWatch pelo [CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html), que é executado como `root` em todas as instâncias do cluster. Um CloudWatch painel da Amazon é criado quando o cluster é criado. Esse painel permite que você revise os registros armazenados em CloudWatch Registros. Para obter mais informações, consulte [CloudWatch Painel da Amazon](cloudwatch-dashboard-v3.md). Essa lista contém o caminho *logIdentifier* e para os fluxos de log disponíveis para plataformas, agendadores e nós. **Fluxos de log disponíveis para plataformas, programadores e nós** | Plataformas | Programadores | Nós | Fluxos de log | | --- | --- | --- | --- | | amazon redhat ubuntu | awsbatch slurm | HeadNode | dcv-authenticator: `/var/log/parallelcluster/pcluster_dcv_authenticator.log` dcv-ext-authenticator: `/var/log/parallelcluster/pcluster_dcv_connect.log` dcv-agent: `/var/log/dcv/agent.*.log` dcv-xsession: `/var/log/dcv/dcv-xsession.*.log` dcv-server: `/var/log/dcv/server.log` dcv-session-launcher: `/var/log/dcv/sessionlauncher.log` Xdcv: `/var/log/dcv/Xdcv.*.log` cfn-init: `/var/log/cfn-init.log` chef-client: `/var/log/chef-client.log` | | amazon redhat ubuntu | awsbatch slurm | ComputeFleet HeadNode | cloud-init: `/var/log/cloud-init.log` supervisord: `/var/log/supervisord.log` | | amazon redhat ubuntu | slurm | ComputeFleet | cloud-init-output: `/var/log/cloud-init-output.log` computemgtd: `/var/log/parallelcluster/computemgtd` slurmd: `/var/log/slurmd.log` slurm\$1prolog\$1epilog: `/var/log/parallelcluster/slurm_prolog_epilog.log` | | amazon redhat ubuntu | slurm | HeadNode | sssd: `/var/log/sssd/sssd.log` sssd\$1domain\$1default: `/var/log/sssd/sssd_default.log` pam\$1ssh\$1key\$1generator: `/var/log/parallelcluster/pam_ssh_key_generator.log` clusterstatusmgtd: `/var/log/parallelcluster/clusterstatusmgtd` clustermgtd: `/var/log/parallelcluster/clustermgtd` compute\$1console\$1output: `/var/log/parallelcluster/compute_console_output` slurm\$1resume: `/var/log/parallelcluster/slurm_resume.log` slurm\$1suspend: `/var/log/parallelcluster/slurm_suspend.log` slurmctld: `/var/log/slurmctld.log` slurm\$1fleet\$1status\$1manager: `/var/log/parallelcluster/slurm_fleet_status_manager.log` | | amazon redhat | awsbatch slurm | ComputeFleet HeadNode | system-messages: `/var/log/messages` | | ubuntu | awsbatch slurm | ComputeFleet HeadNode | syslog: `/var/log/syslog` | Trabalhos em clusters que usam AWS Batch armazenam a saída de trabalhos que atingiram um estado de `RUNNING``SUCCEEDED`, ou `FAILED` em CloudWatch Logs. O grupo de logs é `/aws/batch/job`, e o formato do nome do fluxo de logs é `jobDefinitionName/default/ecs_task_id`. Por padrão, esses logs são configurados para nunca expirar, mas você pode modificar o período de retenção. Para obter mais informações, consulte [Alterar a retenção de dados de log em CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) no *Guia do usuário do Amazon CloudWatch Logs*. ## Amazon CloudWatch Logs cria registros de imagens Um grupo de logs é criado para cada imagem de compilação personalizada com um nome, `/aws/imagebuilder/ParallelClusterImage-`. Um fluxo de log exclusivo com nome, *\$1pcluster-version\$1* /1 contém a saída do processo de criação da imagem. Você pode acessar os logs usando os comandos de imagem do [`pcluster`](pcluster-v3.md). Para obter mais informações, consulte [AWS ParallelCluster Personalização da AMI](custom-ami-v3.md). # CloudWatch Painel da Amazon Um CloudWatch painel da Amazon é criado quando um cluster é criado. Isso facilita o monitoramento dos nós em seu cluster e a visualização dos registros armazenados no Amazon CloudWatch Logs. O nome do painel é`ClusterName-Region`. *ClusterName*é o nome do seu cluster e *Region* é Região da AWS onde o cluster está. Você pode acessar o painel no console ou abrindo `https://console.aws.amazon.com/cloudwatch/home?region=Region#dashboards:name=ClusterName-Region`. A imagem a seguir mostra um exemplo de CloudWatch painel para um cluster. ![\[Dashboard graphs of the status of cluster resources.\]](http://docs.aws.amazon.com/pt_br/parallelcluster/latest/ug/images/CW-dashboard.png) **Métricas de instância do nó principal** A primeira seção do painel exibe gráficos das EC2 métricas principais da Amazon. Se seu cluster tiver armazenamento compartilhado, a próxima seção mostrará métricas de armazenamento compartilhado. **Métricas de integridade do cluster** Se seu cluster usa Slurm para agendamento, os gráficos das métricas de integridade do cluster mostram erros em tempo real do nó de computação do cluster. Para obter mais informações, consulte [Métricas de integridade do cluster para solução de problemas](troubleshooting-v3-cluster-health-metrics.md). As métricas de integridade do cluster são adicionadas ao painel a partir da AWS ParallelCluster versão 3.6.0. **Logs do nó principal** A seção final lista os registros do nó principal agrupados por registros AWS ParallelCluster do, registros do Scheduler, registros de integração do Amazon DCV e registros do sistema. Para obter mais informações sobre os CloudWatch painéis da Amazon, consulte Como [usar CloudWatch painéis da Amazon no Guia CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) *do usuário da Amazon*. Se você não quiser criar o CloudWatch painel da Amazon, você pode desativá-lo definindo [`Monitoring`](Monitoring-v3.md)//[`Dashboards`](Monitoring-v3.md#yaml-Monitoring-Dashboards)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch)/[`Enabled`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch-Enabled)como`false`. **nota** Se você desativar a criação do CloudWatch painel da Amazon, também desativará a Amazon CloudWatch `disk_used_percent` e `memory_used_percent` os alarmes do seu cluster. Para obter mais informações, consulte [CloudWatch Alarmes da Amazon para métricas de cluster](cloudwatch-alarms-v3.md). Os `memory_used_percent` alarmes `disk_used_percent` e são adicionados a partir da AWS ParallelCluster versão 3.6. # CloudWatch Alarmes da Amazon para métricas de cluster AWS ParallelCluster configura os CloudWatch alarmes da Amazon para monitorar a saúde e a utilização de recursos do nó principal. Os alarmes são nomeados`cluster-name-HeadNode-metric`, onde *cluster-name* está o nome do seu cluster e *metric* identifica a métrica que está sendo monitorada. Acesse os alarmes no CloudWatch console escolhendo **Alarmes** no painel de navegação. Um alarme composto chamado `cluster-name-HeadNode` entra no `ALARM` estado em que qualquer um dos alarmes individuais do nó principal é acionado. ## Alarmes de disco e memória A partir da AWS ParallelCluster versão 3.6.0, os seguintes CloudWatch alarmes são criados: + `cluster-name-HeadNode-Disk`— Monitora a `disk_used_percent` métrica do volume raiz. Entra no `ALARM` estado em que o uso do disco é maior que 90% para 1 ponto de dados em um período de 1 minuto. + `cluster-name-HeadNode-Mem`— Monitora a `mem_used_percent` métrica. Entra no `ALARM` estado em que o uso da memória é maior que 90% para 1 ponto de dados em um período de 1 minuto. Para obter mais informações, consulte [Métricas coletadas pelo CloudWatch agente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html) no *Guia CloudWatch do usuário da Amazon*. ## Verificação de saúde e alarmes de CPU A partir da AWS ParallelCluster versão 3.8.0, os seguintes CloudWatch alarmes são criados: + `cluster-name-HeadNode-Health`— Monitora a métrica do Amazon EC2`StatusCheckFailed`. Insere o `ALARM` estado em que o valor é maior que 0 para 1 ponto de dados em um período de 1 minuto. + `cluster-name-HeadNode-Cpu`— Monitora a métrica do Amazon EC2`CPUUtilization`. Entra no `ALARM` estado em que a utilização da CPU é superior a 90% para 1 ponto de dados em um período de 1 minuto. ## Alarme de pulsação do daemon de gerenciamento de cluster A partir da AWS ParallelCluster versão 3.15.0, quando o Amazon CloudWatch Logging é ativado e o Slurm agendador é usado, o seguinte alarme é criado: + `cluster-name-HeadNode-ClustermgtdHeartbeat`— Monitora a `ClustermgtdHeartbeat` métrica no `ParallelCluster` namespace. O alarme entra no `ALARM` estado em que menos de 1 pulsação é recebida por 10 pontos de dados consecutivos em um período de 1 minuto. Os dados perdidos são tratados como violação. **nota** Todos os alarmes se recuperam simetricamente: os mesmos pontos de dados e período de avaliação que acionam o alarme também governam a recuperação. Por exemplo, alarmes com 1 ponto de dados se recuperam após 1 ponto de dados bom dentro do mesmo período de observação. Da mesma forma, o `ClustermgtdHeartbeat` alarme requer 10 bons pontos de dados consecutivos (10 minutos) para `OK` retornar. **nota** AWS ParallelCluster não configura ações de alarme. Para obter informações sobre como configurar ações de alarme, como enviar notificações, consulte [Ações de alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions). Para obter mais informações sobre CloudWatch os alarmes da Amazon, consulte Como [usar CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) no Guia * CloudWatch do usuário da Amazon*. Para a AWS ParallelCluster versão 3.8.0 e posterior, desative os alarmes definindo [`Monitoring`](Monitoring-v3.md)/[`Alarms`](Monitoring-v3.md#yaml-Monitoring-Alarms)/[`Enabled`](Monitoring-v3.md#yaml-Monitoring-Alarms-Enabled)para `false` na configuração do cluster. Para AWS ParallelCluster versões anteriores à 3.8.0, desative os alarmes definindo [`Monitoring`](Monitoring-v3.md)//[`Dashboards`[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch)](Monitoring-v3.md#yaml-Monitoring-Dashboards)/[`Enabled`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch-Enabled)como `false` na configuração do cluster. Observe que essa configuração também desativa o CloudWatch painel da Amazon. Consulte [CloudWatch Painel da Amazon](cloudwatch-dashboard-v3.md) para obter detalhes adicionais. # AWS ParallelCluster rotação de log configurada As configurações de rotação de AWS ParallelCluster registros estão localizadas em `/etc/logrotate.d/parallelcluster_*_log_rotation` arquivos. Quando um log configurado é rotacionado, o conteúdo do log atual é preservado em um único backup e o log vazio retoma o registro. Somente 1 backup é mantido para cada log configurado. AWS ParallelCluster configura um registro de rápido crescimento para girar quando atingir 50 MB de tamanho. Os registros de rápido crescimento estão relacionados ao dimensionamento e Slurm, `/var/log/parallelcluster/clustermgtd` incluindo`/var/log/parallelcluster/slurm_resume.log`, `/var/log/slurmctld.log` e. AWS ParallelCluster configura um registro de crescimento lento para girar quando atingir 10 MB de tamanho. Você pode ver os registros anteriores que são retidos pelo número de dias definido na configuração [`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)/[`RetentionInDays`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-RetentionInDays)do cluster com o CloudFormation registro ativado. Verifique as configurações `RetentionInDays` para ver se o número de dias precisa ser aumentado para seu caso de uso. AWS ParallelCluster configura e gira os seguintes registros: **Logs do nó principal** ``` /var/log/cloud-init.log /var/log/supervisord.log /var/log/cfn-init.log /var/log/chef-client.log /var/log/dcv/server.log /var/log/dcv/sessionlauncher.log /var/log/dcv/agent.*.log /var/log/dcv/dcv-xsession.*.log /var/log/dcv/Xdcv.*.log /var/log/parallelcluster/pam_ssh_key_generator.log /var/log/parallelcluster/clustermgtd /var/log/parallelcluster/clusterstatusmgtd /var/log/parallelcluster/slurm_fleet_status_manager.log /var/log/parallelcluster/slurm_resume.log /var/log/parallelcluster/slurm_suspend.log /var/log/slurmctld.log /var/log/slurmdbd.log /var/log/parallelcluster/compute_console_output.log ``` **Logs de nós de computação** ``` /var/log/cloud-init.log /var/log/supervisord.log /var/log/cloud-init-output.log /var/log/parallelcluster/computemgtd /var/log/slurmd.log ``` **Logs do nó de login** ``` /var/log/cloud-init.log /var/log/cloud-init.log /var/log/cloud-init-output.log /var/log/supervisord.log /var/log/parallelcluster/pam_ssh_key_generator.log ``` # Logs da CLI `pcluster` A CLI `pcluster` grava logs de seus comandos em arquivos `pcluster.log.#` em `/home/user/.parallelcluster/`. Para cada comando, os logs geralmente incluem o comando com entradas, uma cópia da versão da API CLI usada para criar o comando, a resposta e as informações e mensagens de erro. Para um comando de criação e construção, os registros também incluem o arquivo de configuração, as operações de validação do arquivo de configuração, o CloudFormation modelo e os comandos de pilha. Você pode usar esses logs para verificar erros, entradas, versões e comandos da CLI `pcluster`. Eles também podem servir como um registro de quando os comandos foram feitos. # Registros de saída EC2 do console Amazon Quando AWS ParallelCluster detecta que uma instância de nó computacional estático termina inesperadamente, ela tenta recuperar a saída do EC2 console Amazon da instância do nó encerrado após um período de tempo decorrido. Dessa forma, se o nó de computação não conseguir se comunicar com a Amazon CloudWatch, informações úteis de solução de problemas sobre o motivo pelo qual o nó foi encerrado ainda poderão ser recuperadas da saída do console. Essa saída do console é gravada no log `/var/log/parallelcluster/compute_console_output` no nó principal. Para obter mais informações sobre a saída do EC2 console Amazon, consulte [Saída do console de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-console-output) no *Guia EC2 do usuário da Amazon para instâncias Linux*. Por padrão, AWS ParallelCluster só recupera a saída do console de um subconjunto de amostra de nós terminados. Isso evita que o nó principal do cluster fique sobrecarregado com várias solicitações de saída do console causadas por um grande número de encerramentos. Por padrão, AWS ParallelCluster aguarda 5 minutos entre a detecção da terminação e a recuperação da saída do console para que a Amazon EC2 tenha tempo de recuperar a saída final do console dos nós. Você pode editar o tamanho da amostra e os valores dos parâmetros de tempo de espera no arquivo `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` no nó principal. Esse recurso foi adicionado na AWS ParallelCluster versão 3.5.0. ## Parâmetros de saída EC2 do console Amazon Você pode editar os valores dos seguintes parâmetros de saída EC2 do console Amazon no `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` arquivo no nó principal. ### `compute_console_logging_enabled` Para desativar a coleta de log de saída do console, defina `compute_console_logging_enabled` como`false`. O padrão é `true`. Você pode atualizar esse parâmetro a qualquer momento, sem interromper a frota de computação. ### `compute_console_logging_max_sample_size` `compute_console_logging_max_sample_size`define o número máximo de nós de computação dos quais AWS ParallelCluster coleta as saídas do console sempre que detecta uma terminação inesperada. Se esse valor for menor que`1`, AWS ParallelCluster recupera a saída do console de todos os nós terminados. O valor padrão é `1`. Você pode atualizar esse parâmetro a qualquer momento, sem interromper a frota de computação. ### `compute_console_wait_time` `compute_console_wait_time`define o tempo de AWS ParallelCluster espera, em segundos, entre a detecção de uma falha no nó e a coleta da saída do console desse nó. Você pode aumentar o tempo de espera se determinar que a Amazon EC2 precisa de mais tempo para coletar a saída final do nó encerrado. O valor padrão é de 300 segundos (5 minutos). Você pode atualizar esse parâmetro a qualquer momento, sem interromper a frota de computação. # Recupere registros de PCUI e tempo de execução AWS ParallelCluster Saiba como recuperar os registros da PCUI e do tempo de AWS ParallelCluster execução para solucionar problemas. Para começar, encontre os nomes relevantes da pilha PCUI e AWS ParallelCluster . Use o nome da pilha para localizar os grupos de registros de instalação. Para finalizar, exporte os registros. Esses registros são específicos para o runtime do AWS ParallelCluster . Para clusters de logs, consulte [Recuperando e preservando logs](troubleshooting-v3-get-logs.md). **Pré-requisitos** + O AWS CLI está instalado. + Você tem credenciais para executar AWS CLI comandos no Conta da AWS qual a PCUI está ativada. + Você pode acessar o CloudWatch console da Amazon no local em Conta da AWS que a PCUI está ativada. ## Etapa 1: Localize os nomes das pilhas relevantes No exemplo a seguir, substitua o texto destacado em vermelho com seus valores reais. Liste as pilhas, usando o Região da AWS local onde você instalou a PCUI: ``` $ aws cloudformation list-stacks --region aws-region-id ``` Observe os nomes das pilhas a seguir: + O nome da pilha que implantou a PCUI na sua conta. Você inseriu esse nome ao instalar a interface a PCUI; por exemplo, `pcluster-ui`. + A AWS ParallelCluster pilha que é prefixada com o nome da pilha que você inseriu; por exemplo,. `pcluster-ui-ParallelClusterApi-ABCD1234EFGH` ## Etapa 2: Localizar os grupos de logs. Liste os grupos de logs da pilha da PCUI, conforme mostrado no exemplo a seguir: ``` $ aws cloudformation describe-stack-resources \ --region aws-region-id \ --stack-name pcluster-ui \ --query "StackResources[?ResourceType == 'AWS::Logs::LogGroup' && (LogicalResourceId == 'ApiGatewayAccessLog' || LogicalResourceId == 'ParallelClusterUILambdaLogGroup')].PhysicalResourceId" \ --output text ``` Liste os grupos de registros da pilha de AWS ParallelCluster APIs, conforme mostrado no exemplo a seguir: ``` $ aws cloudformation describe-stack-resources \ --region aws-region-id \ --stack-name pcluster-ui-ParallelCluster-Api-ABCD1234EFGH \ --query "StackResources[?ResourceType == 'AWS::Logs::LogGroup' && LogicalResourceId == 'ParallelClusterFunctionLogGroup'].PhysicalResourceId" \ --output text ``` Anote as listas de grupos de logs para uso na próxima etapa. ## Etapa 3: exportar os logs Siga as etapas a seguir para coletar e exportar os logs: 1. Faça login no e Console de gerenciamento da AWS, em seguida, navegue até o CloudWatch console da [Amazon](https://console.aws.amazon.com/cloudwatch/) no Conta da AWS qual a PCUI está ativada. 1. Escolha **Logs** e selecione **Logs Insights**. 1. Selecione todos os grupos de logs listados na etapa anterior. 1. Escolha um intervalo de tempo, como 12 horas. 1. Execute a seguinte consulta: ``` $ fields @timestamp, @message | sort @timestamp desc | limit 10000 ``` 1. Escolha **Exportar resultados**, **Baixar tabela (JSON)**. # Recuperando e preservando logs AWS ParallelCluster cria EC2 métricas da Amazon para HeadNode instâncias e armazenamento de computação. Você pode ver as métricas nos **painéis personalizados** do CloudWatch console. AWS ParallelCluster também cria fluxos de CloudWatch log de cluster em grupos de registros. Você pode visualizar esses registros no CloudWatch console **Painéis personalizados** ou **grupos de registros**. A seção [Monitoramento](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch) da configuração do cluster descreve como você pode modificar os CloudWatch registros e o painel do cluster. Para obter mais informações, consulte [Integração com Amazon CloudWatch Logs](cloudwatch-logs-v3.md) e [CloudWatch Painel da Amazon](cloudwatch-dashboard-v3.md). Os logs são um recurso útil para solucionar problemas. Por exemplo, se você quiser excluir um cluster com falha, talvez seja útil criar primeiro um arquivo dos logs do cluster. Siga as etapas [Arquivar logs](#troubleshooting-v3-get-logs-archive) para criar um arquivo. **Topics** + [Registros de cluster indisponíveis em CloudWatch](#troubleshooting-v3-get-logs-unavailable) + [Arquivar logs](#troubleshooting-v3-get-logs-archive) + [Logs preservados](#troubleshooting-v3-get-logs-preserve) + [Logs de nós encerrados](#troubleshooting-v3-get-logs-terminated-node) ## Registros de cluster indisponíveis em CloudWatch Se os registros do cluster não estiverem disponíveis em CloudWatch, verifique se você não substituiu a configuração do AWS ParallelCluster CloudWatch registro ao adicionar registros personalizados à configuração. Para adicionar registros personalizados à CloudWatch configuração, certifique-se de anexar à configuração em vez de buscá-la e substituí-la. Para obter mais informações sobre `fetch-config` e`append-config`, consulte [Arquivos de configuração de vários CloudWatch agentes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) no *Guia CloudWatch do usuário*. Para restaurar a configuração do AWS ParallelCluster CloudWatch log, você pode executar os seguintes comandos dentro de um AWS ParallelCluster nó: ``` $ PLATFORM="$(ohai platform | jq -r ".[]")" LOG_GROUP_NAME="$(cat /etc/chef/dna.json | jq -r ".cluster.log_group_name")" SCHEDULER="$(cat /etc/chef/dna.json | jq -r ".cluster.scheduler")" NODE_ROLE="$(cat /etc/chef/dna.json | jq -r ".cluster.node_type")" CONFIG_DATA_PATH="/usr/local/etc/cloudwatch_agent_config.json" /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/python /usr/local/bin/write_cloudwatch_agent_json.py --platform $PLATFORM --config $CONFIG_DATA_PATH --log-group $LOG_GROUP_NAME --scheduler $SCHEDULER --node-role $NODE_ROLE /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s ``` ## Arquivar logs Você pode arquivar os logs no Amazon S3 ou em um arquivo local (dependendo do parâmetro `--output-file`). **nota** A partir da AWS ParallelCluster versão 3.12.0, você pode exportar registros para o bucket padrão AWS ParallelCluster . Nesse caso, você não precisa definir permissões de bucket. **nota** Adicione permissões à política de bucket do Amazon S3 para conceder CloudWatch acesso. Para obter mais informações, consulte [Definir permissões em um bucket do Amazon S3 no Guia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3ExportTasks.html#S3Permissions) do *usuário de CloudWatch registros*. ``` $ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs { "url": "https://bucketname.s3.eu-west-1.amazonaws.com/export-log/mycluster-logs-202109071136.tar.gz?..." } # use the --output-file parameter to save the logs locally $ pcluster export-cluster-logs --cluster-name mycluster --region eu-west-1 \ --bucket bucketname --bucket-prefix logs --output-file /tmp/archive.tar.gz { "path": "/tmp/archive.tar.gz" } ``` O arquivo contém os streams do Amazon CloudWatch Logs e os eventos de CloudFormation pilha do nó principal e dos nós de computação dos últimos 14 dias, a menos que especificado explicitamente na configuração ou nos parâmetros do comando. `export-cluster-logs` O tempo necessário para a conclusão do comando depende do número de nós no cluster e do número de fluxos de log disponíveis nos CloudWatch Logs. Para obter mais informações sobre os fluxos de log disponíveis, consulte [Integração com Amazon CloudWatch Logs](cloudwatch-logs-v3.md). ## Logs preservados A partir da versão 3.0.0, AWS ParallelCluster preserva os CloudWatch registros por padrão quando um cluster é excluído. Se você quiser excluir um cluster e preservar seus logs, certifique-se de que [`Monitoring`](Monitoring-v3.md) / [`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs) / [`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch) / [`DeletionPolicy`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-DeletionPolicy) não esteja definido como `Delete` na configuração do cluster. Caso contrário, altere o valor desse campo para `Retain` e execute o comando `pcluster update-cluster`. Em seguida, execute `pcluster delete-cluster --cluster-name ` para excluir o cluster, mas mantenha o grupo de registros que está armazenado na Amazon CloudWatch. ## Logs de nós encerrados Se um nó de computação estático for encerrado inesperadamente e não CloudWatch tiver registros, verifique se a saída do console desse nó de computação AWS ParallelCluster foi registrada no nó principal do registro. `/var/log/parallelcluster/compute_console_output` Para obter mais informações, consulte [Logs principais para depuração](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs). Se o `/var/log/parallelcluster/compute_console_output` registro não estiver disponível ou não contiver a saída do nó, use o AWS CLI para recuperar a saída do console do nó com falha. Faça login no nó principal do cluster e obtenha o nó com falha `instance-id` do arquivo `/var/log/parallelcluster/slurm_resume.log`. Recupere a saída do console usando o comando a seguir com o `instance-id`: ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` Se um nó de computação dinâmico for encerrado automaticamente após a inicialização e não CloudWatch tiver registros, envie um trabalho que ative uma ação de escalabilidade de cluster. Aguarde até que a instância falhe e recupere o log do console da instância. Faça login no nó principal do cluster e obtenha o nó de computação `instance-id` do arquivo `/var/log/parallelcluster/slurm_resume.log`. Para recuperar o log do console da instância, use o seguinte comando: ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` O log de saída do console pode ajudá-lo a depurar a causa raiz de uma falha no nó de computação quando o log do nó de computação não estiver disponível.