翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS ParallelCluster と ログのモニタリング モニタリングは、 およびその他の AWS ParallelCluster AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。 AWS には、監視 AWS ParallelCluster、問題発生時の報告、必要に応じて自動アクションを実行するための以下のモニタリングツールが用意されています。 + *Amazon CloudWatch* は、 AWS リソースと で実行しているアプリケーションを AWS リアルタイムでモニタリングします。メトリクスの収集と追跡、カスタマイズしたダッシュボードの作成、および指定したメトリクスが指定したしきい値に達したときに通知またはアクションを実行するアラームの設定を行うことができます。例えば、CloudWatch で Amazon EC2 インスタンスの CPU 使用率などのメトリクスを追跡し、必要に応じて新しいインスタンスを自動的に起動できます。詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。 + *Amazon CloudWatch Logs* では、Amazon EC2 インスタンス、CloudTrail、その他ソースから得たログファイルのモニタリング、保存、およびアクセスが可能です。CloudWatch Logs は、ログファイル内の情報をモニタリングし、特定のしきい値が満たされたときに通知します。高い耐久性を備えたストレージにログデータをアーカイブすることも可能です。詳細については、『[Amazon CloudWatch Logs ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)』を参照してください。 + AWS CloudTrailは、 AWS アカウント により、またはそのアカウントに代わって行われた API コールや関連イベントを取得し、指定した Amazon S3 バケットにログファイルを配信します。 AWSを呼び出したユーザーとアカウント、呼び出し元の IP アドレス、および呼び出しの発生日時を特定できます。詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。 + *Amazon EventBridge* は、アプリケーションをさまざまなイベントソースのデータに簡単に接続できるようにするサーバーレスイベントバスサービスです。EventBridge は、独自のアプリケーション、Software-as-a-Service (SaaS) アプリケーション、および AWS のサービスからリアルタイムデータのストリームを配信し、そのデータを Lambda などのターゲットにルーティングします。これにより、サービスで発生したイベントをモニタリングし、イベント駆動型アーキテクチャを構築できます。詳細については、「[Amazon EventBridge ユーザーガイド](https://docs.aws.amazon.com/eventbridge/latest/userguide/)」を参照してください。 **Topics** + [Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md) + [Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md) + [クラスターメトリクス用の Amazon CloudWatch アラーム](cloudwatch-alarms-v3.md) + [AWS ParallelCluster ログローテーションの設定](log-rotation-v3.md) + [`pcluster` CLI ログ](troubleshooting-v3-pc-cli-logs.md) + [Amazon EC2 コンソール出力ログ](console-logs-v3.md) + [PCUI と AWS ParallelCluster ランタイムログを取得する](troubleshooting-v3-get-runtime-logs.md) + [ログの取得と保存](troubleshooting-v3-get-logs.md) # Amazon CloudWatch Logs との統合 CloudWatch Logs の詳細については、[「Amazon CloudWatch Logs User Guide」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)(Amazon CloudWatch Logs ユーザーガイド) を参照してください。CloudWatch Logs の統合を設定するには、「[`Monitoring`](Monitoring-v3.md)」セクションを参照してください。`append-config` を使用して CloudWatch 設定にカスタムログを追加する方法については、「Amazon CloudWatch ユーザーガイド**」の「[ CloudWatch エージェント設定ファイル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)」を参照してください。 ## Amazon CloudWatch Logs のクラスターログ ロググループは、クラスターごとに `/aws/parallelcluster/cluster-name-` という名前 (例: `/aws/parallelcluster/testCluster-202202050215`) で作成されます。ノード別の各ログ (またはパスに `*` が含まれている場合はログのセット) には、`{hostname}.{instance_id}.{logIdentifier}` という名前のログストリームが存在します。(例: `ip-172-31-10-46.i-02587cf29cc3048f3.nodewatcher`) ログデータは、すべてのクラスターインスタンス上で `root` として実行される [CloudWatch エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)によって CloudWatch に送信されます。 Amazon CloudWatch ダッシュボードは、クラスター作成時に作成されます。このダッシュボードでは、CloudWatch Logs に保存されているログを確認することができます。詳細については、「[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)」を参照してください。 このリストには、プラットフォーム、スケジューラー、ノードで使用できるログストリームの *logIdentifier* とパスが含まれています。 **プラットフォーム、スケジューラー、ノードで使用できるログストリーム** | [Platforms] (プラットフォーム) | スケジューラ | ノード | ログストリーム | | --- | --- | --- | --- | | 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` | を使用するクラスター内のジョブは、`RUNNING`、、`SUCCEEDED`または の状態に達したジョブの出力を CloudWatch Logs `FAILED`に AWS Batch 保存します。ロググループは `/aws/batch/job`、ログストリーム名形式は `jobDefinitionName/default/ecs_task_id` です。デフォルトでは、このログは失効しませんが、保持期間を変更することもできます。詳細については、*「Amazon CloudWatch Logs User Guide」*(Amazon CloudWatch Logs ユーザーガイド) の[「Change log data retention in CloudWatch Logs」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)(CloudWatch ログでのログデータ保管期間の変更) を参照してください。 ## Amazon CloudWatch Logs のビルドイメージログ カスタムビルドイメージごとに `/aws/imagebuilder/ParallelClusterImage-` という名前が付けられたロググループが作成されます。*\$1pcluster-version\$1*/1 という名前のユニークなログストリームには、ビルドイメージプロセスの出力が含まれます。 ログには、[`pcluster`](pcluster-v3.md) イメージコマンドを使用してアクセスできます。詳細については、「[AWS ParallelCluster AMI のカスタマイズ](custom-ami-v3.md)」を参照してください。 # Amazon CloudWatch ダッシュボード Amazon CloudWatch ダッシュボードは、クラスター作成時に作成されます。これにより、クラスター内のノードのモニタリングや、Amazon CloudWatch Logs に保存されたログの確認が容易になります。ダッシュボードの名前は `ClusterName-Region` です。*ClusterName* はクラスターの名前、*Region* はクラスターが存在する AWS リージョン です。ダッシュボードはコンソールから、または `https://console.aws.amazon.com/cloudwatch/home?region=Region#dashboards:name=ClusterName-Region` を開くことでアクセスできます。 次の図は、クラスターの CloudWatch ダッシュボード例を示しています。 ![\[Dashboard graphs of the status of cluster resources.\]](http://docs.aws.amazon.com/ja_jp/parallelcluster/latest/ug/images/CW-dashboard.png) **ヘッドノードインスタンスメトリクス** ダッシュボードの最初のセクションには、ヘッドノードの Amazon EC2 メトリクスのグラフが表示されます。 クラスターに共有ストレージがある場合、次のセクションには共有ストレージメトリクスが表示されます。 **クラスターヘルスメトリクス** クラスターが Slurm をスケジューリングに使用している場合、クラスターヘルスメトリクスグラフにはクラスターコンピュートノードエラーがリアルタイムで表示されます。詳細については、「[クラスターヘルスメトリクスのトラブルシューティング](troubleshooting-v3-cluster-health-metrics.md)」を参照してください。クラスターのヘルスメトリクスは、 AWS ParallelCluster バージョン 3.6.0 からダッシュボードに追加されます。 **ヘッドノードログ** 最後のセクションでは、ヘッドノードログを AWS ParallelCluster、 のログ、スケジューラのログ、Amazon DCV 統合ログ、およびシステムのログ別にグループ化して一覧表示します。 CloudWatch メトリクスの操作方法の詳細については、*「Amazon CloudWatch User Guide」*(Amazon CloudWatch ユーザーガイド) の[「Using Amazon CloudWatch dashboards」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)(Amazon CloudWatch ダッシュボードの使用) を参照してください。 Amazon CloudWatch ダッシュボードを作成したくない場合は、[`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) を `false` に設定することでダッシュボードをオフにできます。 **注記** Amazon CloudWatch ダッシュボードの作成を無効にすると、クラスターの Amazon CloudWatch `disk_used_percent` および `memory_used_percent` アラームも無効になります。詳細については、「[クラスターメトリクス用の Amazon CloudWatch アラーム](cloudwatch-alarms-v3.md)」を参照してください。 `disk_used_percent` および `memory_used_percent`アラームは、 AWS ParallelCluster バージョン 3.6 から追加されます。 # クラスターメトリクス用の Amazon CloudWatch アラーム AWS ParallelCluster は、ヘッドノードのヘルスとリソース使用率をモニタリングするように Amazon CloudWatch アラームを設定します。アラームの名前は です。ここで`cluster-name-HeadNode-metric`、*cluster-name* はクラスターの名前であり、*メトリクス*はモニタリング対象のメトリクスを識別します。 ナビゲーションペインで **[アラーム]** を選択して、CloudWatch コンソールのアラームにアクセスします。 という名前の複合アラームは、個々のヘッドノードアラームのいずれかがトリガーされると `ALARM`状態`cluster-name-HeadNode`になります。 ## ディスクとメモリのアラーム AWS ParallelCluster バージョン 3.6.0 以降では、次の CloudWatch アラームが作成されます。 + `cluster-name-HeadNode-Disk` — ルートボリューム`disk_used_percent`メトリクスをモニタリングします。1 分間に 1 つのデータポイントでディスク使用量が 90% を超える場合`ALARM`の状態を入力します。 + `cluster-name-HeadNode-Mem` — `mem_used_percent`メトリクスをモニタリングします。1 分間に 1 つのデータポイントでメモリ使用量が 90% を超える場合`ALARM`の状態を入力します。 詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch エージェントにより収集されるメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html)」を参照してください。 ## ヘルスチェックと CPU アラーム AWS ParallelCluster バージョン 3.8.0 以降では、次の CloudWatch アラームが作成されます。 + `cluster-name-HeadNode-Health` — Amazon EC2 `StatusCheckFailed`メトリクスをモニタリングします。1 分間に 1 つのデータポイントで値が 0 より大きい場合`ALARM`の状態を入力します。 + `cluster-name-HeadNode-Cpu` — Amazon EC2 `CPUUtilization`メトリクスをモニタリングします。1 分間に 1 つのデータポイントで CPU 使用率が 90% を超える場合`ALARM`の状態を入力します。 ## クラスター管理デーモンハートビートアラーム AWS ParallelCluster バージョン 3.15.0 以降では、Amazon CloudWatch ログ記録が有効で、スSlurmケジューラが使用されている場合、次のアラームが作成されます。 + `cluster-name-HeadNode-ClustermgtdHeartbeat` — `ParallelCluster`名前空間の `ClustermgtdHeartbeat`メトリクスをモニタリングします。アラームは、1 分間に 10 個の連続したデータポイントに対して 1 ハートビート未満を受信すると、 `ALARM`状態になります。欠落データは違反として扱われます。 **注記** すべてのアラームは対称的に復旧します。アラームをトリガーするのと同じデータポイントと評価期間も復旧を管理します。たとえば、1 つのデータポイントを持つアラームは、同じ観測期間内に 1 つの正常なデータポイントの後に回復します。同様に、`ClustermgtdHeartbeat`アラームは に戻るために 10 個の正常なデータポイント (10 分) が連続して必要です`OK`。 **注記** AWS ParallelCluster はアラームアクションを設定しません。通知の送信など、アラームアクションの設定方法については、「[アラームアクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)」を参照してください。Amazon CloudWatch アラームの使用の詳細については、「Amazon CloudWatch ユーザーガイド**」の「[Amazon CloudWatch アラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。 AWS ParallelCluster バージョン 3.8.0 以降では、クラスター設定`false`で [`Monitoring`](Monitoring-v3.md) // [`Alarms`](Monitoring-v3.md#yaml-Monitoring-Alarms) [`Enabled`](Monitoring-v3.md#yaml-Monitoring-Alarms-Enabled)を に設定してアラームを無効にします。 3.8.0 より前の AWS ParallelCluster バージョンでは、クラスター設定`false`で [`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)を に設定してアラームを無効にします。この設定により、Amazon CloudWatch ダッシュボードも無効になることに注意してください。詳細については[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)、「」を参照してください。 # AWS ParallelCluster ログローテーションの設定 AWS ParallelCluster ログローテーション設定は `/etc/logrotate.d/parallelcluster_*_log_rotation` ファイルにあります。設定したログがローテーションされると、現在のログコンテンツは単一のバックアップに保存され、空になったログはログ記録を再開します。 設定したログごとに 1 つのバックアップだけが保持されます。 AWS ParallelCluster は、50 MB のサイズに達したときにローテーションするように、急成長するログを設定します。急速に増大するログはスケーリングおよび Slurm と関連し、`/var/log/parallelcluster/clustermgtd`、`/var/log/parallelcluster/slurm_resume.log`、`/var/log/slurmctld.log` が含まれます。 AWS ParallelCluster は、サイズが 10 MB に達したときにローテーションするように、成長の遅いログを設定します。 CloudFormation ログ記録を有効にした状態で、クラスター設定の [`Logs`](Monitoring-v3.md#yaml-Monitoring-Logs)/[`CloudWatch`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)/[`RetentionInDays`](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch-RetentionInDays) 設定で定義された日数だけ保持されている以前のログを表示できます。`RetentionInDays` 設定を確認して、ユースケースに合わせて日数を増やす必要があるかどうかを確認してください。 AWS ParallelCluster は、次のログを設定およびローテーションします。 **ヘッドノードログ** ``` /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 ``` **コンピューティングノードログ** ``` /var/log/cloud-init.log /var/log/supervisord.log /var/log/cloud-init-output.log /var/log/parallelcluster/computemgtd /var/log/slurmd.log ``` **ログインノードログ** ``` /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` CLI ログ `pcluster` CLI はコマンドのログを `/home/user/.parallelcluster/` 内の `pcluster.log.#` ファイルに書き込みます。 各コマンドのログには、通常、入力されたコマンド、コマンドの作成に使用された CLI API バージョンのコピー、応答、および情報とエラーメッセージがそれぞれ含まれます。create および build コマンドの場合、ログには設定ファイル、設定ファイルの検証操作、CloudFormation テンプレート、スタックコマンドも含まれます。 これらのログを使用して、エラー、入力、バージョン、および `pcluster` CLI コマンドを確認できます。また、コマンドが実行されたときの記録としても役立ちます。 # Amazon EC2 コンソール出力ログ は、静的コンピューティングノードインスタンスが予期せず終了したこと AWS ParallelCluster を検出すると、一定期間が経過した後に、終了したノードインスタンスから Amazon EC2 コンソール出力を取得しようとします。これにより、コンピューティングノードが Amazon CloudWatch と通信できなかった場合でも、ノードが終了した理由に関する有用なトラブルシューティング情報をコンソール出力から取得できます。このコンソール出力はヘッドノードの `/var/log/parallelcluster/compute_console_output` ログに記録されます。Amazon EC2 コンソール出力の詳細については、「*Linux インスタンス用 Amazon EC2 ユーザーガイド*」の「[インスタンスコンソール出力](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html#instance-console-console-output)」を参照してください。 デフォルトでは、 は終了したノードのサンプルサブセットから AWS ParallelCluster のみコンソール出力を取得します。これにより、多数の終了による複数のコンソール出力要求でクラスターヘッドノードが圧倒されるのを防ぐことができます。デフォルトでは、 は終了検出からコンソール出力の取得まで 5 分 AWS ParallelCluster 待機し、Amazon EC2 にノードから最終的なコンソール出力を取得する時間を与えます。 ヘッドノード上の `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` ファイルで、サンプルサイズと待機時間のパラメータ値を編集できます。 この機能は AWS ParallelCluster バージョン 3.5.0 で追加されています。 ## Amazon EC2 コンソール出力パラメータ ヘッドノードの `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` ファイルで、以下の EC2 コンソール出力パラメータの値を編集できます。 ### `compute_console_logging_enabled` コンソール出力ログの収集を無効にするには、`compute_console_logging_enabled` を `false` に設定します。デフォルトは `true` です。 このパラメータは、コンピューティングフリートを停止せずにいつでも更新することができます。 ### `compute_console_logging_max_sample_size` `compute_console_logging_max_sample_size` は、予期しない終了を検出するたびに がコンソール出力を AWS ParallelCluster 収集するコンピューティングノードの最大数を設定します。この値が より小さい場合`1`、 は終了したすべてのノードからコンソール出力 AWS ParallelCluster を取得します。デフォルト値は `1` です。 このパラメータは、コンピューティングフリートを停止せずにいつでも更新することができます。 ### `compute_console_wait_time` `compute_console_wait_time` は、ノード障害を検出してからそのノードからコンソール出力を収集するまで AWS ParallelCluster 待機する時間を秒単位で設定します。終了したノードから最終出力を収集するためにより多くの時間が Amazon EC2 に必要だと判断した場合は、待機時間を増やすことができます。デフォルト値は 300 秒 (5 分) です。 このパラメータは、コンピューティングフリートを停止せずにいつでも更新することができます。 # PCUI と AWS ParallelCluster ランタイムログを取得する トラブルシューティングのために PCUI と AWS ParallelCluster ランタイムログを取得する方法について説明します。まず、関連する PCUI および AWS ParallelCluster スタックの名前を見つけます。スタック名を使用してインストールロググループを探します。終了するには、ログをエクスポートします。これらのログは AWS ParallelCluster ランタイムに固有のものです。クラスターログの場合には、「[ログの取得と保存](troubleshooting-v3-get-logs.md)」を参照してください。 **前提条件** + AWS CLI がインストールされます。 + PCUI AWS アカウント がオンになっている で AWS CLI コマンドを実行するための認証情報があります。 + PCUI がオン AWS アカウント になっている で Amazon CloudWatch コンソールにアクセスできます。 ## ステップ 1: 関連するスタックのスタック名を見つける 以下の例では、赤く強調表示されたテキストを実際の値に置き換えます。 PCUI をインストール AWS リージョン した を使用して、スタックを一覧表示します。 ``` $ aws cloudformation list-stacks --region aws-region-id ``` 以下のスタックのスタック名を書き留めておきます。 + アカウントに PCUI をデプロイしたスタックの名前。PCUI をインストールしたときに入力した名前です (`pcluster-ui` など)。 + 入力した AWS ParallelCluster スタック名のプレフィックスが付いたスタック。例: `pcluster-ui-ParallelClusterApi-ABCD1234EFGH`。 ## ステップ 2: ロググループを検索する 次の例に示すように、PCUI スタックのロググループを一覧表示します。 ``` $ 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 ``` 次の例に示すように、 AWS ParallelCluster API スタックのロググループを一覧表示します。 ``` $ 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 ``` 後のステップで使用するために、ロググループのリストを書き留めます。 ## ステップ 3: ログをエクスポートする ログを収集してエクスポートするには、次の手順に従います。 1. にログインし AWS マネジメントコンソール、PCUI がオンになっている の [Amazon CloudWatch](https://console.aws.amazon.com/cloudwatch/) AWS アカウント コンソールに移動します。 1. ナビゲーションペインで、**[ログ]**、**[ログインサイト]** を選択します。 1. 前のステップでリストされたすべてのロググループを選択します。 1. 12 時間などの時間範囲を選択します。 1. 次のクエリを実行します。 ``` $ fields @timestamp, @message | sort @timestamp desc | limit 10000 ``` 1. **[結果のエクスポート]**、**[テーブルをダウンロード (JSON)]** を選択します。 # ログの取得と保存 AWS ParallelCluster は、HeadNode および Compute インスタンスとストレージの Amazon EC2 メトリクスを作成します。CloudWatch コンソールの**カスタムダッシュボード**でメトリクスを表示できます。 AWS ParallelCluster また、 はロググループにクラスター CloudWatch ログストリームを作成します。これらのログは、CloudWatch コンソールの**カスタムダッシュボード**または**ロググループ**で表示できます。[モニタリング](Monitoring-v3.md#yaml-Monitoring-Logs-CloudWatch)クラスター設定セクションでは、クラスターの CloudWatch ログとダッシュボードを変更する方法について説明されています。詳細については、「[Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md)」および「[Amazon CloudWatch ダッシュボード](cloudwatch-dashboard-v3.md)」を参照してください。 ログは問題を解決するための有用なリソースです。障害が発生したクラスターを削除する場合は、まずクラスターログのアーカイブを作成すると役立つことがあります。[ログのアーカイブ](#troubleshooting-v3-get-logs-archive) の手順に従ってアーカイブを作成します。 **Topics** + [CloudWatch ではクラスターログを使用できません](#troubleshooting-v3-get-logs-unavailable) + [ログのアーカイブ](#troubleshooting-v3-get-logs-archive) + [保存されたログ](#troubleshooting-v3-get-logs-preserve) + [終了したノードログ](#troubleshooting-v3-get-logs-terminated-node) ## CloudWatch ではクラスターログを使用できません CloudWatch でクラスターログを使用できない場合は、設定にカスタムログを追加するときに AWS ParallelCluster CloudWatch ログ設定が上書きされていないことを確認してください。 CloudWatch 設定にカスタムログを追加するには、取得して上書きするのではなく、必ず設定に追加してください。`fetch-config` および `append-config` の詳細については、「CloudWatch ユーザーガイド**」の「[CloudWatch エージェント設定ファイル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files)」を参照してください。 AWS ParallelCluster CloudWatch ログ設定を復元するには、 AWS ParallelCluster ノード内で次のコマンドを実行します。 ``` $ 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 ``` ## ログのアーカイブ ログは S3 またはローカルファイルにアーカイブできます (`--output-file` パラメータに依存します)。 **注記** AWS ParallelCluster 3.12.0 以降では、ログをデフォルトの AWS ParallelCluster バケットにエクスポートできます。この場合、バケットのアクセス許可を設定する必要はありません。 **注記** CloudWatch へのアクセスを許可するため、Amazon S3 バケットポリシーにアクセス許可を追加しします。詳細については、「CloudWatch Logs ユーザーガイド**」の「[Amazon S3 バケットのアクセス許可を設定する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3ExportTasks.html#S3Permissions)」を参照してください。 ``` $ 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" } ``` アーカイブには、設定または `export-cluster-logs` コマンドのパラメータで明示的に指定されていない限り、過去 14 日間のヘッドノードとコンピューティングノードからの Amazon CloudWatch Logs ストリームと CloudFormation スタックイベントが含まれます。クラスター内のノード数や CloudWatch Logs で利用できるログストリームの数によっては、コマンドの実行に時間がかかる場合があります。利用できるすべてのログストリームについての詳細は、「[Amazon CloudWatch Logs との統合](cloudwatch-logs-v3.md)」を参照してください。 ## 保存されたログ バージョン 3.0.0 以降、クラスターが削除されると、 はデフォルトで CloudWatch Logs AWS ParallelCluster を保持します。クラスターを削除してそのログを保存したい場合は、クラスター設定で [`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) が `Delete` に設定されていないことを確認してください。そうでない場合は、このフィールドの値を `Retain` に変更して `pcluster update-cluster` コマンドを実行します。その後、`pcluster delete-cluster --cluster-name ` を実行してクラスターを削除しますが、Amazon CloudWatch に保存されているロググループを保持します。 ## 終了したノードログ 静的コンピューティングノードが予期せず終了し、CloudWatch にログがない場合、 AWS ParallelCluster がそのコンピューティングノードのコンソール出力をヘッドノードに`/var/log/parallelcluster/compute_console_output`ログに記録しているかどうかを確認します。詳細については、「[デバッグ用のキーログ](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs)」を参照してください。 `/var/log/parallelcluster/compute_console_output` ログが利用できない場合、またはノードの出力が含まれていない場合は、 を使用して AWS CLI 、障害が発生したノードからコンソール出力を取得します。クラスターヘッドノードにログインし、障害が発生したノード `instance-id` を `/var/log/parallelcluster/slurm_resume.log` ファイルから取得します。 コンソール出力を取得するには、次のコマンドを `instance-id` と共に使用します。 ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` 動的コンピューティングノードが起動後に自動的に終了し、CloudWatch にそのログがない場合は、クラスタースケーリングアクションを有効にするジョブを送信します。インスタンスに障害が発生するのを待ち、インスタンスコンソールログを取得します。 クラスターヘッドノードにログインし、`/var/log/parallelcluster/slurm_resume.log` ファイルからコンピューティングノード `instance-id` を取得します。 インスタンスコンソールログを取得するには、次のコマンドを使用します。 ``` $ aws ec2 get-console-output --instance-id i-abcdef01234567890 ``` コンソール出力ログは、コンピューティングノードログが利用できない場合にコンピューティングノード障害の根本原因をデバッグするのに役立ちます。