本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 扩展登录 AWS 个
扩展日志可记录 AWS 并行计算服务如何扩展集群中的计算节点组。每个日志条目记录了一个计算节点的一次状态转换：例如，实例启动、节点注册、缩减或启动失败及其原因。您可以使用扩展日志来回答诸如为什么节点组未达到其目标大小、由于容量原因启动失败以及特定节点何时启动或停止等问题。
您可以向亚马逊 CloudWatch、亚马逊简单存储服务 (Amazon S3) 和亚马逊 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 日志](#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. 在 “**扩展日志” 下**，选择 “**添加**”，从日志、Amazon S3 和 Firehose 中添加最多 3 个 CloudWatch 日志传输目的地。
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 日志组、S3 存储桶或 Firehose 交付流的亚马逊资源名称 (ARN)。
有关更多信息，请参阅[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)《*亚马逊 CloudWatch 日志 API 参考》*。
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
有关更多信息，请参阅[PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)《*亚马逊 CloudWatch 日志 API 参考》*。
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
有关更多信息，请参阅[CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)《*亚马逊 CloudWatch 日志 API 参考》*。
------
## 查找扩展日志
您可以在日志和 Amazon S3 中配置 CloudWatch 日志目的地。 AWS PCS 使用以下结构化路径名和文件名。
### CloudWatch 日志
AWS PCS 对 CloudWatch 日志流使用以下名称格式：
```
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`对象包含过渡细节。
下表描述了每个日志条目中的顶级字段。
**Top-level 字段**
| Name | 示例值 | 必填 | 注意 |
| --- | --- | --- | --- |
| resource\_id | "pcs\_22l8nzr3t9" | 是 | AWS PCS 集群 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`对象内部的密钥。
**`详细信息`对象内的字段**
| Name | 示例值 | 必填 | 注意 |
| --- | --- | --- | --- |
| 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 无法为目标子网中请求的实例类型提供容量。A `LIMIT_EXCEEDED` 表示亚马逊 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"
}
}
```