翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# PCS AWS でのログのスケーリング
スケーリングログは、 AWS Parallel Computing Service がクラスター内のコンピューティングノードグループをスケーリングする方法の記録を提供します。各ログエントリは、インスタンスの起動、ノード登録、スケールダウン、起動失敗など、1 つのコンピューティングノードに対して 1 つの状態遷移を記録します。スケーリングログを使用して、ノードグループがターゲットサイズに達しなかった理由、容量の理由で起動に失敗した理由、特定のノードがいつ起動または停止したかなどの質問に回答できます。
スケーリングログは、Amazon CloudWatch、Amazon Simple Storage Service (Amazon S3)、および Amazon Data Firehose に送信できます。移行ごとに、 AWS PCS は次のデータを記録します。
+ クラスターおよびコンピューティングノードグループ識別子
+ ノード名
+ 新しいステータス
+ 理由コードと人間が読める説明
+ インスタンスが移行に関連付けられているときの EC2 インスタンス ID
+ 必要に応じて、インスタンスタイプやサブネットなどの起動コンテキスト
AWS PCS は、 ログタイプを通じてスケーリング`PCS_SCALING_LOGS`ログを配信します。スケーリングログ配信はオプトインです。 AWS PCS は、配信を設定するまで、クラスターのスケーリングログを配信しません。
**Contents**
+ [前提条件](#monitoring_scaling-logs_prereqs)
+ [スケーリングログの設定](#monitoring_scaling-logs_setup)
+ [スケーリングログの検索](#monitoring_scaling-logs_access)
+ [CloudWatch Logs](#monitoring_scaling-logs_access_cloudwatch)
+ [Amazon S3](#monitoring_scaling-logs_access_s3)
+ [ログフィールドのスケーリング](#monitoring_scaling-logs_fields)
+ [ステータスコードと理由コード](#monitoring_scaling_logs-status-codes-and-reason-codes)
+ [スケーリングログの例](#monitoring_scaling-logs_example)
## 前提条件
PCS クラスターを管理する IAM AWS プリンシパルは、 `pcs:AllowVendedLogDeliveryForResource`アクションを許可する必要があります。
次の IAM ポリシーの例では、必要なアクセス許可を付与します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PcsAllowVendedLogsDelivery",
"Effect": "Allow",
"Action": ["pcs:AllowVendedLogDeliveryForResource"],
"Resource": [
"arn:aws:pcs:*::cluster/*"
]
}
]
}
```
## スケーリングログの設定
AWS マネジメントコンソール または を使用して、PCS AWS クラスターのスケーリングログを設定できます AWS CLI。
------
#### [ AWS マネジメントコンソール ]
**コンソールでスケーリングログを設定するには**
1. [AWS PCS コンソール](https://console.aws.amazon.com/pcs)を開きます。
1. ナビゲーションペインで **[Clusters]** (クラスター) を選択します。
1. スケーリングログを追加するクラスターを選択します。
1. クラスターの詳細ページで、**ログ**タブを選択します。
1. **スケーリングログ で**、**追加** を選択して、CloudWatch Logs、Amazon S3、Firehose の中から最大 3 つのログ配信先を追加します。
1. **ログ配信の更新**を選択します。
------
#### [ AWS CLI ]
**を使用してスケーリングログを設定するには AWS CLI**
1. ログ配信先を作成します。
```
aws logs put-delivery-destination --region {{region}} \
--name {{pcs-logs-destination}} \
--delivery-destination-configuration \
destinationResourceArn={{resource-arn}}
```
置き換え前:
+ region — など、送信先を作成する AWS リージョン {{。}} `us-east-1`
+ {{pcs-logs-destination}} — 送信先の名前
+ {{resource-arn}} — CloudWatch Logs ロググループ、S3 バケット、または Firehose 配信ストリームの Amazon リソースネーム (ARN)。
詳細については、「*Amazon CloudWatch Logs API Reference*」の「[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)」を参照してください。
1. PCS クラスターをログ配信ソースとして設定します。
```
aws logs put-delivery-source --region {{region}} \
--name {{cluster-logs-source-name}} \
--resource-arn {{cluster-arn}} \
--log-type PCS_SCALING_LOGS
```
置き換え前:
+ {{region}} — クラスター AWS リージョン の など。 `us-east-1`
+ {{cluster-logs-source-name}} — ソースの名前
+ {{cluster-arn}} — AWS PCS クラスターの ARN
詳細については、*Amazon CloudWatch Logs API リファレンス*」の「[PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)」を参照してください。
1. 配信ソースを配信先に接続します。
```
aws logs create-delivery --region {{region}} \
--delivery-source-name {{cluster-logs-source}} \
--delivery-destination-arn {{destination-arn}}
```
置き換え前:
+ {{region}} — AWS リージョンなど `us-east-1`
+ {{cluster-logs-source}} — 配信ソースの名前
+ {{destination-arn}} — 配信先の ARN
詳細については、*Amazon CloudWatch Logs API リファレンス*」の[CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)」を参照してください。
------
## スケーリングログの検索
CloudWatch Logs と Amazon S3 でログの送信先を設定できます。 AWS PCS は次の構造化パス名とファイル名を使用します。
### CloudWatch Logs
AWS PCS は CloudWatch Logs ストリームに次の名前形式を使用します。
```
AWSLogs/PCS/{{cluster-id}}/node_lifecycle.log
```
例: `AWSLogs/PCS/pcs_abc123de45/node_lifecycle.log`
### Amazon S3
AWS PCS は S3 パスに次の名前形式を使用します。
```
AWSLogs/{{account-id}}/PCS/{{region}}/{{cluster-id}}/node_lifecycle/{{year}}/{{month}}/{{day}}/{{hour}}/
```
例: `AWSLogs/111122223333/PCS/us-east-1/pcs_abc123de45/node_lifecycle/2026/09/03/11/`
AWS PCS はログファイルに次の名前形式を使用します。
```
PCS_{{cluster-id}}_node_lifecycle_{{year}}-{{month}}-{{day}}-{{hour}}_{{random-id}}.log.gz
```
例: `PCS_pcs_abc123de45_node_lifecycle_2026-09-03-11_04be080b.log.gz`
## ログフィールドのスケーリング
AWS PCS はスケーリングログデータを JSON オブジェクトとして書き込みます。各ログエントリには、最上位のメタデータフィールドと`details`オブジェクトが含まれます。最上位フィールドは、クラスター、イベント時間、コンピューティングノードグループ、スケジューラノード ID を識別します。`details` オブジェクトは移行の詳細を保持します。
次の表は、各ログエントリの最上位フィールドを示しています。
**最上位フィールド**
| 名前 | 値の例 | 必須 | コメント |
| --- | --- | --- | --- |
| resource\_id | "pcs\_22l8nzr3t9" | はい | PCS AWS クラスター ID |
| resource\_type | "PCS\_CLUSTER" | はい | 常に "PCS\_CLUSTER" |
| event\_timestamp | 1789179816460 | はい | イベント発生時の Unix エポックミリ秒 |
| compute\_node\_group\_id | "pcs\_56zr33g8" | はい | ノードが属するコンピューティングノードグループ |
| scheduler\_node\_id | "compute-1" | はい | スケジューラノード ID |
| status\_code | "LAUNCH\_FAILED" | はい | ノードの新しいステータス。「[ステータスコードと理由コード](#monitoring_scaling_logs-status-codes-and-reason-codes)」を参照してください。 |
| reason\_code | "INSUFFICIENT\_CAPACITY" | はい | 移行が発生した理由 |
| description | "The launch failed because EC2 did not have enough capacity" | はい | ステータスと理由コードから派生した人間が読める概要 |
| details | {...} | いいえ | 移行の追加コンテキスト。キーは移行タイプによって異なります |
次の表は、 `details` オブジェクト内に表示されるキーを示しています。
**`details` オブジェクト内のフィールド**
| 名前 | 値の例 | 必須 | 注意事項 |
| --- | --- | --- | --- |
| instance\_id | "i-0abcdef01234567a" | いいえ | ノードに関連付けられた EC2 インスタンス。起動失敗後など、インスタンスが関連付けられていない場合は存在しない |
| ec2\_error\_code | "InsufficientInstanceCapacity" | いいえ | 起動に失敗した EC2 エラーコード。アカウントの CreateFleet 呼び出しの CloudTrail レコードに同じコードが表示されます。 |
| instance\_type | "t4g.micro" | いいえ | 起動されたインスタンスタイプ |
| subnet\_id | "subnet-0abc123" | いいえ | 起動の対象となるサブネット |
## ステータスコードと理由コード
`status_code` フィールドには、ノードが入力した状態が表示されます。`reason_code` フィールドにはその理由が表示されます。例えば、`INSUFFICIENT_CAPACITY`理由のある`LAUNCH_FAILED`ステータスは、Amazon EC2 がターゲットサブネットでリクエストされたインスタンスタイプの容量を提供できなかったことを意味します。は、Amazon EC2 クォータが起動をブロックした`LIMIT_EXCEEDED`ことを意味します。
**ステータスコードと理由コード**
| ステータスコード | 理由コード | 説明 |
| --- | --- | --- |
| LAUNCHED | SCHEDULER\_REQUESTED | スケジューラのスケールアップリクエストを満たすために起動されたインスタンス |
| LAUNCHED | MAINTAIN\_MIN\_CAPACITY | ノードグループの最小容量を維持するために起動されたインスタンス |
| REGISTERED | REGISTER\_SUCCESS | PCS エージェントを介して正常に登録されたノード |
| ACTIVE | BOOTSTRAP\_SUCCESS | ノードブートストラップが完了しました。slurmd が実行中でジョブを受け入れています |
| PENDING\_REPLACEMENT | NODE\_GROUP\_UPDATE | ノードグループの更新で電源が切断される前にノードがドレインしている |
| PENDING\_REPLACEMENT | EC2\_HEALTH\_CHECK\_FAILED | ノードまたはそのインスタンスのヘルスチェックが失敗したため、ノードがドレインしています |
| PENDING\_REPLACEMENT | EC2\_SCHEDULED\_EVENT | インスタンスに EC2 メンテナンスイベントがスケジュールされているため、ノードはドレインしています |
| LAUNCH\_FAILED | INSUFFICIENT\_CAPACITY | 使用可能な容量が不足しているため、ノードがインスタンスを取得できませんでした |
| LAUNCH\_FAILED | LIMIT\_EXCEEDED | アカウントクォータを超えたため、インスタンスの起動に失敗しました |
| LAUNCH\_FAILED | LAUNCH\_ERROR | ノードがインスタンスの起動に失敗しました |
| TERMINATED | SCHEDULER\_REQUESTED | スケジューラがノードを解放した後に終了したインスタンス (アイドルタイムアウトまたはパワーダウン) |
| TERMINATED | UNHEALTHY\_NODE | スケジューラがノードを異常と報告したため、インスタンスが終了しました |
| TERMINATED | BOOTSTRAP\_FAILED | ノードがブートストラップに失敗したためインスタンスが終了しました |
| TERMINATED | EXTERNALLY\_TERMINATED | インスタンスは PCS の外部で終了しました。ノードは解放され、置き換えることができます。 |
| TERMINATED | REPLACEMENT\_REQUESTED | ノードが置き換えのためにドレインされたため、インスタンスが終了しました |
| TERMINATED | NODE\_GROUP\_DELETION | コンピューティングノードグループの削除の一環として終了したインスタンス |
| TERMINATE\_FAILED | EC2\_OPERATION\_NOT\_PERMITTED | インスタンスの終了に失敗しました。インスタンスで終了保護が有効になっていないことを確認する |
| TERMINATE\_FAILED | EC2\_ERROR | インスタンスの終了に失敗しました |
## スケーリングログの例
次の例は、インスタンスの正常な起動を示しています。
```
{
"resource_id": "pcs_abc123de45",
"resource_type": "PCS_CLUSTER",
"event_timestamp": 1789179816460,
"compute_node_group_id": "pcs_abcdef01",
"scheduler_node_id": "compute-1",
"status_code": "LAUNCHED",
"reason_code": "SCHEDULER_REQUESTED",
"description": "Instance launched to satisfy a scheduler scale-up request.",
"details": {
"instance_id": "i-0abc12345def67890",
"instance_type": "c6i.xlarge",
"subnet_id": "subnet-0123456789abcdef0"
}
}
```
次の例は、EC2 容量不足による起動失敗を示しています。インスタンス`instance_id`が起動されなかったため、 は存在しません。
```
{
"resource_id": "pcs_abc123de45",
"resource_type": "PCS_CLUSTER",
"event_timestamp": 1789179816460,
"compute_node_group_id": "pcs_abcdef01",
"scheduler_node_id": "compute-2",
"status_code": "LAUNCH_FAILED",
"reason_code": "INSUFFICIENT_CAPACITY",
"description": "Node did not get an instance because there was not enough capacity available.",
"details": {
"ec2_error_code": "InsufficientInstanceCapacity"
}
}
```