Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Surveillance AWS ParallelCluster et journaux
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité AWS ParallelCluster et des performances de vos autres AWS solutions. AWS fournit les outils de surveillance suivants pour surveiller AWS ParallelCluster, signaler tout problème et prendre des mesures automatiques le cas échéant :
+ *Amazon CloudWatch* surveille vos AWS ressources et les applications que vous utilisez AWS en temps réel. Vous pouvez collecter et suivre les métriques, créer des tableaux de bord personnalisés, et définir des alarmes qui vous informent ou prennent des mesures lorsqu’une métrique spécifique atteint un seuil que vous spécifiez. Par exemple, vous pouvez CloudWatch suivre l'utilisation du processeur ou d'autres indicateurs de vos EC2 instances Amazon et lancer automatiquement de nouvelles instances en cas de besoin. Pour plus d'informations, consultez le [guide de CloudWatch l'utilisateur Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* vous permet de surveiller, de stocker et d'accéder à vos fichiers journaux à partir d' EC2 instances Amazon et d'autres sources. CloudTrail CloudWatch Les journaux peuvent surveiller les informations contenues dans les fichiers journaux et vous avertir lorsque certains seuils sont atteints. Vous pouvez également archiver vos données de journaux dans une solution de stockage hautement durable. Pour plus d'informations, consultez le [guide de l'utilisateur d'Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail* capture les appels d’API et les événements associés créés par votre Compte AWS ou au nom de celui-ci et livre les fichiers journaux dans un compartiment Amazon S3 que vous spécifiez. Vous pouvez identifier les utilisateurs et les comptes qui ont appelé AWS, l’adresse IP source à partir de laquelle les appels ont été émis, ainsi que le moment où les appels ont eu lieu. Pour de plus amples informations, veuillez consulter le [Guide de l’utilisateur AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
+ *Amazon EventBridge* est un service de bus d'événements sans serveur qui permet de connecter facilement vos applications à des données provenant de diverses sources. EventBridge fournit un flux de données en temps réel à partir de vos propres applications, applications Software-as-a-Service (SaaS) et AWS services et achemine ces données vers des cibles telles que Lambda. Cela vous permet de surveiller les événements qui se produisent dans les services et de créer des architectures basées sur les événements. Pour plus d'informations, consultez le [guide de EventBridge l'utilisateur Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
**Topics**
+ [Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md)
+ [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md)
+ [CloudWatch Alarmes Amazon pour les métriques du cluster](cloudwatch-alarms-v3.md)
+ [AWS ParallelCluster rotation des journaux configurée](log-rotation-v3.md)
+ [`pcluster`Journaux de la CLI](troubleshooting-v3-pc-cli-logs.md)
+ [Journaux de sortie de la EC2 console Amazon](console-logs-v3.md)
+ [Récupérez le PCUI et AWS ParallelCluster les journaux d'exécution](troubleshooting-v3-get-runtime-logs.md)
+ [Récupération et conservation des journaux](troubleshooting-v3-get-logs.md)
# Intégration à Amazon CloudWatch Logs
Pour plus d'informations sur les CloudWatch journaux, consultez le [guide de l'utilisateur d'Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/). Pour configurer l'intégration CloudWatch des journaux, consultez la [`Monitoring`](Monitoring-v3.md)section. Pour savoir comment ajouter des journaux personnalisés à la CloudWatch configuration en utilisant`append-config`, consultez les [fichiers de configuration de plusieurs CloudWatch agents](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) dans le *guide de l' CloudWatch utilisateur Amazon*.
## CloudWatch Journaux du cluster Amazon Logs
Un groupe de journaux est créé pour chaque cluster avec un nom `/aws/parallelcluster/cluster-name-` (par exemple,`/aws/parallelcluster/testCluster-202202050215`). Chaque journal (ou ensemble de journaux si le chemin contient un`*`) sur chaque nœud possède un flux de journal nommé`{hostname}.{instance_id}.{logIdentifier}`. (Par exemple`ip-172-31-10-46.i-02587cf29cc3048f3.nodewatcher`.) Les données du journal sont envoyées CloudWatch par l'[CloudWatch agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html), qui s'exécute comme `root` sur toutes les instances de cluster.
Un CloudWatch tableau de bord Amazon est créé lors de la création du cluster. Ce tableau de bord vous permet de consulter les journaux stockés dans CloudWatch Logs. Pour de plus amples informations, veuillez consulter [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md).
Cette liste contient le chemin *logIdentifier* et le chemin des flux de journaux disponibles pour les plateformes, les planificateurs et les nœuds.
**Flux de journaux disponibles pour les plateformes, les planificateurs et les nœuds**
| Plateformes | Schedulers | Nœuds | Flux de journaux |
| --- | --- | --- | --- |
| amazon chapeau rouge ubuntu | awsbatch boue | HeadNode | authentificateur DCV : `/var/log/parallelcluster/pcluster_dcv_authenticator.log` dcv-ext-authenticator: `/var/log/parallelcluster/pcluster_dcv_connect.log` agent DCV : `/var/log/dcv/agent.*.log` Séance DCV : `/var/log/dcv/dcv-xsession.*.log` serveur DCV : `/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 chapeau rouge ubuntu | awsbatch boue | ComputeFleet HeadNode | init dans le cloud : `/var/log/cloud-init.log` supervisé : `/var/log/supervisord.log` |
| amazon chapeau rouge ubuntu | boue | ComputeFleet | cloud-init-output: `/var/log/cloud-init-output.log` computemgtd : `/var/log/parallelcluster/computemgtd` bouffé : `/var/log/slurmd.log` slurm\$1prolog\$1epilog : `/var/log/parallelcluster/slurm_prolog_epilog.log` |
| amazon chapeau rouge ubuntu | boue | HeadNode | sssd : `/var/log/sssd/sssd.log` sssd\$1domain\$1default : `/var/log/sssd/sssd_default.log` générateur de clés pam\$1ssh\$1: `/var/log/parallelcluster/pam_ssh_key_generator.log` clusterstatusmgtd : `/var/log/parallelcluster/clusterstatusmgtd` clustermgtd : `/var/log/parallelcluster/clustermgtd` sortie de la console de calcul : `/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 chapeau rouge | awsbatch boue | ComputeFleet HeadNode | messages du système : `/var/log/messages` |
| ubuntu | awsbatch boue | ComputeFleet HeadNode | journal système : `/var/log/syslog` |
Les tâches des clusters qui l'utilisent AWS Batch stockent le résultat des tâches ayant atteint un état de `RUNNING``SUCCEEDED`, ou `FAILED` dans CloudWatch des journaux. Le groupe de journaux est`/aws/batch/job`, et le format du nom du flux de journaux est`jobDefinitionName/default/ecs_task_id`. Par défaut, ces journaux sont configurés pour ne pas expirer, mais vous pouvez modifier la période de conservation. Pour plus d'informations, consultez la section [Conservation des données du journal des modifications dans CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) du *guide de l'utilisateur Amazon CloudWatch Logs*.
## Amazon CloudWatch Logs crée des journaux d'images
Un groupe de journaux est créé pour chaque image de construction personnalisée avec un nom,`/aws/imagebuilder/ParallelClusterImage-`. Un flux de journal unique dont le nom est *\$1pcluster-version\$1* /1 contient le résultat du processus de génération de l'image.
Vous pouvez accéder aux journaux à l'aide des commandes [`pcluster`](pcluster-v3.md)d'image. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster Personnalisation de l'AMI](custom-ami-v3.md).
# Tableau de CloudWatch bord Amazon
Un CloudWatch tableau de bord Amazon est créé lors de la création d'un cluster. Cela facilite la surveillance des nœuds de votre cluster et l'affichage des journaux stockés dans Amazon CloudWatch Logs. Le nom du tableau de bord est`ClusterName-Region`. *ClusterName*est le nom de votre cluster et celui dans lequel se *Region* trouve Région AWS le cluster. Vous pouvez accéder au tableau de bord dans la console ou en l'ouvrant`https://console.aws.amazon.com/cloudwatch/home?region=Region#dashboards:name=ClusterName-Region`.
L'image suivante montre un exemple de CloudWatch tableau de bord pour un cluster.
![\[Dashboard graphs of the status of cluster resources.\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/CW-dashboard.png)
**Métriques relatives aux instances Head Node**
La première section du tableau de bord affiche des graphiques des EC2 métriques Amazon du nœud principal.
Si votre cluster dispose d'un stockage partagé, la section suivante présente les métriques de stockage partagé.
**Indicateurs de santé du cluster**
Si votre cluster utilise Slurm pour la planification, les graphiques des métriques de santé du cluster montrent les erreurs des nœuds de calcul du cluster en temps réel. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés aux indicateurs de santé du](troubleshooting-v3-cluster-health-metrics.md). Les métriques de santé du cluster sont ajoutées au tableau de bord à partir de AWS ParallelCluster la version 3.6.0.
**Journaux du nœud principal**
La dernière section répertorie les journaux des nœuds principaux regroupés par journaux, journaux AWS ParallelCluster du planificateur, journaux d'intégration Amazon DCV et journaux du système.
Pour plus d'informations sur les CloudWatch tableaux de bord Amazon, consultez la section [Utilisation des CloudWatch tableaux de bord Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) dans le guide de * CloudWatch l'utilisateur Amazon*.
Si vous ne souhaitez pas créer le tableau de CloudWatch bord Amazon, vous pouvez le désactiver en réglant [`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)sur`false`.
**Note**
Si vous désactivez la création du tableau de CloudWatch bord Amazon, vous désactivez également Amazon CloudWatch `disk_used_percent` et les `memory_used_percent` alarmes pour votre cluster. Pour de plus amples informations, veuillez consulter [CloudWatch Alarmes Amazon pour les métriques du cluster](cloudwatch-alarms-v3.md).
Les `memory_used_percent` alarmes `disk_used_percent` et sont ajoutées à partir de AWS ParallelCluster la version 3.6.
# CloudWatch Alarmes Amazon pour les métriques du cluster
AWS ParallelCluster configure les CloudWatch alarmes Amazon pour surveiller l'état et l'utilisation des ressources du nœud principal. Les alarmes sont nommées`cluster-name-HeadNode-metric`, où se *cluster-name* trouve le nom de votre cluster et *metric* identifie la métrique surveillée.
Accédez aux alarmes de la CloudWatch console en choisissant **Alarmes** dans le volet de navigation.
Une alarme composite nommée `cluster-name-HeadNode` entre dans l'`ALARM`état lorsque l'une des alarmes individuelles du nœud principal se déclenche.
## Alarmes de disque et de mémoire
À partir de AWS ParallelCluster la version 3.6.0, les CloudWatch alarmes suivantes sont créées :
+ `cluster-name-HeadNode-Disk`— Surveille la `disk_used_percent` métrique du volume racine. Entre dans l'`ALARM`état où l'utilisation du disque est supérieure à 90 % pour 1 point de données sur une période d'une minute.
+ `cluster-name-HeadNode-Mem`— Surveille la `mem_used_percent` métrique. Entre dans l'`ALARM`état où l'utilisation de la mémoire est supérieure à 90 % pour 1 point de données sur une période d'une minute.
Pour plus d'informations, consultez la section [Mesures collectées par l' CloudWatchagent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
## Health check et alarmes du processeur
À partir de AWS ParallelCluster la version 3.8.0, les CloudWatch alarmes suivantes sont créées :
+ `cluster-name-HeadNode-Health`— Surveille la métrique Amazon EC2. `StatusCheckFailed` Entre dans l'`ALARM`état où la valeur est supérieure à 0 pour 1 point de données sur une période d'une minute.
+ `cluster-name-HeadNode-Cpu`— Surveille la métrique Amazon EC2. `CPUUtilization` Entre dans l'`ALARM`état où l'utilisation du processeur est supérieure à 90 % pour 1 point de données sur une période d'une minute.
## Alarme de rythme cardiaque du démon de gestion du cluster
À partir de AWS ParallelCluster la version 3.15.0, lorsque la CloudWatch journalisation Amazon est activée et que le Slurm planificateur est utilisé, l'alarme suivante est créée :
+ `cluster-name-HeadNode-ClustermgtdHeartbeat`— Surveille la `ClustermgtdHeartbeat` métrique dans l'espace de `ParallelCluster` noms. L'alarme entre dans l'`ALARM`état lorsque moins d'un battement de cœur est reçu pour 10 points de données consécutifs sur une période d'une minute. Les données manquantes sont considérées comme des violations.
**Note**
Toutes les alarmes se rétablissent de manière symétrique : les mêmes points de données et la même période d'évaluation qui déclenchent l'alarme régissent également la restauration. Par exemple, les alarmes comportant 1 point de données se rétablissent après 1 point de données valide au cours de la même période d'observation. De même, l'`ClustermgtdHeartbeat`alarme a besoin de 10 bons points de données consécutifs (10 minutes) pour revenir à`OK`.
**Note**
AWS ParallelCluster ne configure pas les actions d'alarme. Pour plus d'informations sur la configuration des actions d'alarme, telles que l'envoi de notifications, voir [Actions d'alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions). Pour plus d'informations sur les CloudWatch alarmes Amazon, consultez la section [Utilisation des CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) dans le *guide de CloudWatch l'utilisateur Amazon*.
Pour les AWS ParallelCluster versions 3.8.0 et ultérieures, désactivez les alarmes en définissant [`Monitoring`](Monitoring-v3.md)/[`Alarms`](Monitoring-v3.md#yaml-Monitoring-Alarms)/[`Enabled`](Monitoring-v3.md#yaml-Monitoring-Alarms-Enabled)sur `false` dans la configuration de votre cluster.
Pour AWS ParallelCluster les versions antérieures à 3.8.0, désactivez les alarmes en attribuant [`Enabled`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch-Enabled)à [`Monitoring`](Monitoring-v3.md)/[`Dashboards`](Monitoring-v3.md#yaml-Monitoring-Dashboards)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Dashboard-CloudWatch)/la valeur `false` dans la configuration de votre cluster. Notez que ce paramètre désactive également le tableau de CloudWatch bord Amazon. Voir [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md) pour plus de détails.
# AWS ParallelCluster rotation des journaux configurée
Les configurations de rotation des AWS ParallelCluster journaux se trouvent dans `/etc/logrotate.d/parallelcluster_*_log_rotation` des fichiers. Lorsqu'un journal configuré change, le contenu actuel du journal est conservé dans une seule sauvegarde et le journal vidé reprend la journalisation.
Une seule sauvegarde est conservée pour chaque journal configuré.
AWS ParallelCluster configure un journal en croissance rapide pour qu'il effectue une rotation lorsqu'il atteint 50 Mo. Les grumes à croissance rapide sont liées à la mise à l'échelle et Slurm, y compris `/var/log/parallelcluster/clustermgtd``/var/log/parallelcluster/slurm_resume.log`, et`/var/log/slurmctld.log`.
AWS ParallelCluster configure un journal à croissance lente pour qu'il effectue une rotation lorsqu'il atteint 10 Mo.
Vous pouvez consulter les journaux antérieurs qui sont conservés pendant le nombre de jours défini dans le [`RetentionInDays`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-RetentionInDays)paramètre [`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)/de configuration du cluster lorsque la CloudFormation journalisation est activée. Vérifiez les `RetentionInDays` paramètres pour voir si le nombre de jours doit être augmenté pour votre cas d'utilisation.
AWS ParallelCluster configure et fait pivoter les journaux suivants :
**Journaux du nœud 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
```
**Journaux des nœuds de calcul**
```
/var/log/cloud-init.log
/var/log/supervisord.log
/var/log/cloud-init-output.log
/var/log/parallelcluster/computemgtd
/var/log/slurmd.log
```
**Journaux du nœud de connexion**
```
/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
```
# `pcluster`Journaux de la CLI
La `pcluster` CLI enregistre les journaux de vos commandes dans `pcluster.log.#` des fichiers`/home/user/.parallelcluster/`.
Pour chaque commande, les journaux incluent généralement la commande avec les entrées, une copie de la version de l'API CLI utilisée pour créer la commande, la réponse, ainsi que les messages d'information et d'erreur. Pour une commande de création et de génération, les journaux incluent également le fichier de configuration, les opérations de validation du fichier de configuration, le CloudFormation modèle et les commandes de pile.
Vous pouvez utiliser ces journaux pour vérifier les erreurs, les entrées, les versions et les commandes `pcluster` CLI. Ils peuvent également servir à enregistrer le moment où les commandes ont été effectuées.
# Journaux de sortie de la EC2 console Amazon
Lorsqu'elle AWS ParallelCluster détecte qu'une instance de nœud de calcul statique se termine de manière inattendue, elle tente de récupérer la sortie de la EC2 console Amazon à partir de l'instance de nœud terminée après un certain temps. Ainsi, si le nœud de calcul n'a pas pu communiquer avec Amazon CloudWatch, des informations de dépannage utiles expliquant pourquoi le nœud s'est arrêté peuvent toujours être extraites de la sortie de la console. Cette sortie de console est enregistrée dans le `/var/log/parallelcluster/compute_console_output` journal du nœud principal. Pour plus d'informations sur la sortie de la EC2 console Amazon, consultez la section [Sortie de la console d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-console-output) dans le *Guide de EC2 l'utilisateur Amazon pour les instances Linux*.
Par défaut, extrait AWS ParallelCluster uniquement la sortie de la console à partir d'un sous-ensemble d'échantillons de nœuds terminés. Cela évite que le nœud principal du cluster ne soit submergé par plusieurs demandes de sortie de console causées par un grand nombre de résiliations. Par défaut, AWS ParallelCluster attend 5 minutes entre la détection de la terminaison et la récupération de la sortie de la console pour donner à Amazon le EC2 temps de récupérer la sortie finale de la console depuis les nœuds.
Vous pouvez modifier la taille de l'échantillon et les valeurs des paramètres de temps d'attente dans le `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` fichier situé sur le nœud principal.
Cette fonctionnalité a été ajoutée dans la AWS ParallelCluster version 3.5.0.
## Paramètres de sortie de la EC2 console Amazon
Vous pouvez modifier les valeurs des paramètres de sortie de la EC2 console Amazon suivants dans le `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` fichier situé sur le nœud principal.
### `compute_console_logging_enabled`
Pour désactiver la collecte des journaux de sortie de la console, définissez `compute_console_logging_enabled` sur`false`. L’argument par défaut est `true`.
Vous pouvez mettre à jour ce paramètre à tout moment, sans arrêter le parc informatique.
### `compute_console_logging_max_sample_size`
`compute_console_logging_max_sample_size`définit le nombre maximum de nœuds de calcul à partir desquels sont AWS ParallelCluster collectées les sorties de console chaque fois qu'il détecte une interruption inattendue. Si cette valeur est inférieure à`1`, AWS ParallelCluster extrait la sortie de la console de tous les nœuds terminés. La valeur par défaut est `1`.
Vous pouvez mettre à jour ce paramètre à tout moment, sans arrêter le parc informatique.
### `compute_console_wait_time`
`compute_console_wait_time`définit le temps, en secondes, qui s'écoule entre AWS ParallelCluster la détection d'une défaillance d'un nœud et la collecte de la sortie de console à partir de ce nœud. Vous pouvez augmenter le temps d'attente si vous déterminez qu'Amazon EC2 a besoin de plus de temps pour collecter le résultat final du nœud résilié. La valeur par défaut est de 300 secondes (5 minutes).
Vous pouvez mettre à jour ce paramètre à tout moment, sans arrêter le parc informatique.
# Récupérez le PCUI et AWS ParallelCluster les journaux d'exécution
Découvrez comment récupérer le PCUI et les journaux AWS ParallelCluster d'exécution à des fins de résolution des problèmes. Pour commencer, recherchez le PCUI et les noms de AWS ParallelCluster pile appropriés. Utilisez le nom de la pile pour localiser les groupes de journaux d'installation. Pour terminer, exportez les journaux. Ces journaux sont spécifiques à l' AWS ParallelCluster environnement d'exécution. Pour les journaux du cluster, voir[Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
**Prérequis**
+ Le AWS CLI est installé.
+ Vous disposez des informations d'identification pour exécuter des AWS CLI commandes sur le Compte AWS PCUI activé.
+ Vous pouvez accéder à la CloudWatch console Amazon sur Compte AWS le PCUI activé.
## Étape 1 : Localisez les noms des piles concernées
Dans l'exemple suivant, remplacez le texte surligné en rouge par vos valeurs réelles.
Répertoriez les piles, en utilisant l' Région AWS endroit où vous avez installé le PCUI :
```
$ aws cloudformation list-stacks --region aws-region-id
```
Notez les noms des piles suivantes :
+ Nom de la pile qui a déployé le PCUI sur votre compte. Vous avez saisi ce nom lorsque vous avez installé le PCUI ; par exemple,. `pcluster-ui`
+ La AWS ParallelCluster pile préfixée par le nom de pile que vous avez saisi ; par exemple,`pcluster-ui-ParallelClusterApi-ABCD1234EFGH`.
## Étape 2 : localiser les groupes de journaux
Répertoriez les groupes de journaux de la pile PCUI, comme illustré dans l'exemple suivant :
```
$ 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
```
Répertoriez les groupes de journaux de la pile d' AWS ParallelCluster API, comme illustré dans l'exemple suivant :
```
$ 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
```
Notez les listes des groupes de journaux à utiliser à l'étape suivante.
## Étape 3 : Exporter les journaux
Procédez comme suit pour collecter et exporter les journaux :
1. Connectez-vous au AWS Management Console, puis accédez à la CloudWatch console [Amazon](https://console.aws.amazon.com/cloudwatch/) sur Compte AWS laquelle le PCUI est activé.
1. Choisissez **Logs**, **Logs Insights** dans le volet de navigation.
1. Sélectionnez tous les groupes de journaux répertoriés à l'étape précédente.
1. Choisissez un intervalle de temps, tel que 12 heures.
1. Exécutez la requête suivante :
```
$ fields @timestamp, @message
| sort @timestamp desc
| limit 10000
```
1. Choisissez **Exporter les résultats**, **Télécharger le tableau (JSON)**.
# Récupération et conservation des journaux
AWS ParallelCluster crée des EC2 métriques Amazon pour HeadNode et calcule les instances et le stockage. Vous pouvez consulter les statistiques dans les **tableaux de bord personnalisés** de la CloudWatch console. AWS ParallelCluster crée également des flux de CloudWatch journaux de cluster dans des groupes de journaux. Vous pouvez consulter ces journaux dans les **tableaux de bord personnalisés** ou les **groupes de journaux** de la CloudWatch console. La section Configuration du cluster de [surveillance](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch) décrit comment modifier les CloudWatch journaux et le tableau de bord du cluster. Pour plus d’informations, consultez [Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md) et [Tableau de CloudWatch bord Amazon](cloudwatch-dashboard-v3.md).
Les journaux constituent une ressource utile pour résoudre les problèmes. Par exemple, si vous souhaitez supprimer un cluster défaillant, il peut être utile de créer d'abord une archive des journaux du cluster. Suivez les étapes décrites [Journaux d'archivage](#troubleshooting-v3-get-logs-archive) pour créer une archive.
**Topics**
+ [Les journaux du cluster ne sont pas disponibles dans CloudWatch](#troubleshooting-v3-get-logs-unavailable)
+ [Journaux d'archivage](#troubleshooting-v3-get-logs-archive)
+ [Bûches préservées](#troubleshooting-v3-get-logs-preserve)
+ [Journaux des nœuds interrompus](#troubleshooting-v3-get-logs-terminated-node)
## Les journaux du cluster ne sont pas disponibles dans CloudWatch
Si les journaux de cluster ne sont pas disponibles dans CloudWatch, assurez-vous de ne pas avoir remplacé la configuration des AWS ParallelCluster CloudWatch journaux lorsque vous ajoutez des journaux personnalisés à la configuration.
Pour ajouter des journaux personnalisés à la CloudWatch configuration, veillez à les ajouter à la configuration plutôt que de les récupérer et de les remplacer. Pour plus d'informations sur `fetch-config` et`append-config`, consultez la section [Fichiers de configuration de plusieurs CloudWatch agents](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) dans le *Guide de CloudWatch l'utilisateur*.
Pour restaurer la configuration du AWS ParallelCluster CloudWatch journal, vous pouvez exécuter les commandes suivantes dans un AWS ParallelCluster nœud :
```
$ 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
```
## Journaux d'archivage
Vous pouvez archiver les journaux dans Amazon S3 ou dans un fichier local (selon le `--output-file` paramètre).
**Note**
À partir de la AWS ParallelCluster version 3.12.0, vous pouvez exporter les journaux vers le bucket par défaut AWS ParallelCluster . Dans ce cas, il n'est pas nécessaire de définir les autorisations du bucket.
**Note**
Ajoutez des autorisations à la politique du compartiment Amazon S3 pour accorder CloudWatch l'accès. Pour plus d'informations, consultez la section [Définir des autorisations sur un compartiment Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3ExportTasks.html#S3Permissions) dans le *Guide de l'utilisateur CloudWatch des journaux*.
```
$ 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"
}
```
L'archive contient les flux Amazon CloudWatch Logs et les événements de CloudFormation pile provenant du nœud principal et des nœuds de calcul au cours des 14 derniers jours, sauf indication explicite dans la configuration ou dans les paramètres de la `export-cluster-logs` commande. Le temps nécessaire à la fin de la commande dépend du nombre de nœuds du cluster et du nombre de flux de CloudWatch journaux disponibles dans Logs. Pour plus d'informations sur les flux de journaux disponibles, consultez[Intégration à Amazon CloudWatch Logs](cloudwatch-logs-v3.md).
## Bûches préservées
À partir de la version 3.0.0, AWS ParallelCluster préserve CloudWatch les journaux par défaut lorsqu'un cluster est supprimé. Si vous souhaitez supprimer un cluster et conserver ses journaux, assurez-vous que [`Monitoring`](Monitoring-v3.md)//[`Logs`[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)](Monitoring-v3.md#yaml-Monitoring-Logs)/[`DeletionPolicy`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-DeletionPolicy)n'est pas défini sur `Delete` dans la configuration du cluster. Sinon, remplacez la valeur de ce champ par et exécutez la `pcluster update-cluster` commande. `Retain` Exécutez ensuite `pcluster delete-cluster --cluster-name ` pour supprimer le cluster, mais conservez le groupe de journaux stocké sur Amazon CloudWatch.
## Journaux des nœuds interrompus
Si un nœud de calcul statique se termine de manière inattendue et ne CloudWatch possède aucun journal, vérifiez s'il AWS ParallelCluster a enregistré la sortie de console pour ce nœud de calcul sur le nœud principal du `/var/log/parallelcluster/compute_console_output` journal. Pour de plus amples informations, veuillez consulter [Journaux clés pour le débogage](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs).
Si le `/var/log/parallelcluster/compute_console_output` journal n'est pas disponible ou ne contient pas la sortie du nœud, utilisez le AWS CLI pour récupérer la sortie de console du nœud défaillant. Connectez-vous au nœud principal du cluster et récupérez le nœud `instance-id` défaillant dans le `/var/log/parallelcluster/slurm_resume.log` fichier.
Récupérez la sortie de la console à l'aide de la commande suivante avec `instance-id` :
```
$ aws ec2 get-console-output --instance-id i-abcdef01234567890
```
Si un nœud de calcul dynamique s'arrête automatiquement après son lancement et ne CloudWatch possède aucun journal, soumettez une tâche qui active une action de dimensionnement du cluster. Attendez que l'instance échoue et récupérez le journal de la console de l'instance.
Connectez-vous au nœud principal du cluster et récupérez le nœud `instance-id` de calcul depuis le `/var/log/parallelcluster/slurm_resume.log` fichier.
Pour récupérer le journal de la console de l'instance, utilisez la commande suivante :
```
$ aws ec2 get-console-output --instance-id i-abcdef01234567890
```
Le journal de sortie de la console peut vous aider à résoudre la cause première d'une défaillance d'un nœud de calcul lorsque le journal du nœud de calcul n'est pas disponible.