本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 AWS PCS 中擴展日誌
擴展日誌可讓您記錄 AWS 平行運算服務如何擴展叢集中的運算節點群組。每個日誌項目都會記錄一個運算節點的一個狀態轉換：例如，執行個體啟動、節點註冊、縮減規模或啟動失敗及其原因。您可以使用擴展日誌來回答問題，例如節點群組未達到目標大小的原因、因容量原因啟動失敗，以及特定節點何時開始或停止。
您可以將擴展日誌傳送至 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)
## 先決條件
管理 AWS PCS 叢集的 IAM 主體必須允許 `pcs:AllowVendedLogDeliveryForResource`動作。
下列範例 IAM 政策會授予必要的許可。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PcsAllowVendedLogsDelivery",
"Effect": "Allow",
"Action": ["pcs:AllowVendedLogDeliveryForResource"],
"Resource": [
"arn:aws:pcs:*::cluster/*"
]
}
]
}
```
## 設定擴展日誌
您可以使用 AWS 管理主控台 或 為您的 AWS PCS 叢集設定擴展日誌 AWS CLI。
------
#### [ AWS 管理主控台 ]
**使用主控台設定擴展日誌**
1. 開啟 [AWS PCS 主控台](https://console.aws.amazon.com/pcs)。
1. 在導覽窗格中，選擇**叢集**。
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 Resource Name (ARN)。
如需詳細資訊，請參閱《Amazon CloudWatch Logs API 參考指南》**中的 [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" | 是 | AWS PCS 叢集 ID |
| resource\_type | "PCS\_CLUSTER" | 是 | 一律 "PCS\_CLUSTER" |
| event\_timestamp | 1789179816460 | 是 | 事件發生時的 Unix epoch 毫秒數 |
| 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 無法為目標子網路中請求的執行個體類型提供容量。`LIMIT_EXCEEDED` 表示 Amazon EC2 配額已封鎖啟動。
**狀態碼和原因碼**
| 狀態碼 | 原因代碼 | 說明 |
| --- | --- | --- |
| 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"
}
}
```