AWS PCS新增扩缩容日志：记录计算节点状态变化，日志投递需要主动开启
2026 年 9 月 30 日，AWS 宣布 Parallel Computing Service（PCS）支持扩缩容日志。对于使用该服务运行高性能计算任务的团队，新日志提供了观察计算节点组扩缩过程的直接记录，帮助解释目标规模与实际规模为什么存在差距。
配图为 AI 生成的概念示意图，非真实产品界面、设备照片或性能测试结果。
日志记录的是节点状态变化
按官方说明，每条记录对应一个计算节点的一次状态转换，例如实例启动、节点注册、缩容，或者启动失败及原因。日志投递需要主动开启，可选择 CloudWatch Logs、Amazon S3 或 Amazon Data Firehose；该能力覆盖所有提供 AWS PCS 的区域。
这类记录可以用于检查某次扩容为什么未达到目标规模，以及某个节点何时开始或停止。它不是某个科学计算程序的完整运行输出，也不应替代作业自身的日志、退出状态和结果检查。两类信息回答的问题不同。
排查时先建立一条共同时间线
以下是本文的排查建议。发生等待时，先写下任务进入队列、目标节点数变化、节点注册和任务开始执行这几个时间点。对齐时区和时间范围，再看延迟集中在哪一段。只有“任务很慢”这一条描述，通常不足以判断应该检查扩容还是程序本身。
例如队列已经有需求，但节点启动失败，与节点已经就绪而作业仍未运行，是两种不同现象。前者应沿失败记录继续核对资源条件，后者则需要结合调度约束和作业状态。不要看到有失败事件，就把同一时间段的所有延迟归为同一个原因。
开启投递之后，还要证明能查到
在计划内的小规模测试中触发一次正常扩缩，确认目标位置收到记录，并能按节点、时间和状态定位。记录一条已知事件的实际到达时间，有助于后续判断“查不到”究竟是还没到达、查询条件不对，还是投递没有工作。
再确定谁有读取权限、需要保留多久、如何限制查询与存储支出。不要把所有日志无限期堆在默认位置；按排查需要保留必要字段，并把敏感业务内容与基础设施状态记录分开管理。具体保留要求由团队自己的运行需要决定。
这次更新让扩缩过程更容易被观察。可靠的采用方式，是把新增记录与已有监控放在同一故障时间线上，用真实事件验证投递，再形成可复用的排查步骤，而不是仅以“功能已开启”作为完成标准。
来源与核验
AWS官方更新（2026-09-30）。本文于北京时间 2026 年 10 月 1 日核验，功能状态以官方后续更新为准。
