Amazon ECS 托管守护进程实战：平台工程师如何独立更新监控 Agent 不再依赖应用团队重新部署

Amazon ECS 托管守护进程实战平台工程师如何独立更新监控 Agent 不再依赖应用团队重新部署上周又因为更新 Amazon CloudWatch Agent 被应用团队投诉了。事情很简单我要把 Agent 从 1.247 升到 1.300结果需要改 task definition、走 CR、等应用团队排期重新部署。一来一回三天过去了。这种痛做平台的都懂。老模式有多窝火先说说之前的做法。我们团队管着 200 多个 Amazon ECS 服务监控用的 Amazon CloudWatch Agent 是以 sidecar 的形式塞在每个 task definition 里的。这意味着什么我要更新 Agent 版本得改 200 多个 task definition每个 task definition 属于不同的应用团队改完还得走各团队的发布流程应用团队根本不关心你的监控 Agent 版本号说白了我一个平台工程师想更新自己负责的监控组件得跪求 200 个应用团队配合。有的团队排期紧一拖就是两周。有的团队直接说我们下个版本再带上吧。最离谱的一次某个团队重新部署后日志格式变了监控告警误报。锅甩到我头上说是我让他们更新 Agent 导致的。冤不冤太冤了。亚马逊云科技给出了新方案2025 年 4 月 1 日亚马逊云科技宣布 Amazon ECS 托管实例支持托管守护进程Managed Daemons功能。一句话概括平台工程师可以独立管控监控、日志、跟踪代理不再需要和应用团队协调。这个功能建立在 2025 年 9 月推出的 Amazon ECS 托管实例之上。核心思路是把守护进程的生命周期和应用任务彻底解耦。你管你的 Agent我管我的业务代码。互不干扰各自安好。技术架构怎么做到解耦的专用的 daemon task definition和普通的 task definition 不同daemon task definition 是独立的资源类型。它有自己的参数和验证方案。这很关键。以前 Agent 和应用容器混在一个 task definition 里改一个就牵动另一个。现在完全分开了。daemon_bridge 网络模式新引入的daemon_bridge网络模式让守护进程能和应用任务通信但网络配置彼此隔离。说白了守护进程能采集应用的指标和日志但不会影响应用的网络配置。该收的数据一个不落该隔离的边界一个不破。主机级访问能力平台工程师可以把守护进程配置为特权容器添加 Linux capabilities挂载主机文件系统路径。这对监控和安全代理来说太重要了。要采集主机级指标、进程信息、系统调用没有这些权限根本干不了。启动顺序保证Amazon ECS 确保守护进程先于应用任务启动。也就是说你的应用开始处理请求之前监控和日志采集已经就绪了。不会再出现应用跑了 5 分钟才有监控数据的尴尬。动手实操从零部署一个托管守护进程第一步创建 daemon task definition打开 Amazon ECS 控制台左侧导航栏会看到新的进程守护程序定义选项。选择创建新的 daemon task definition。以 Amazon CloudWatch Agent 为例{family:cloudwatch-agent-daemon,containerDefinitions:[{name:cloudwatch-agent,image:public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest,cpu:1024,memory:512,essential:true,privileged:true,mountPoints:[{sourceVolume:proc,containerPath:/host/proc,readOnly:true},{sourceVolume:sys,containerPath:/host/sys,readOnly:true}]}],volumes:[{name:proc,host:{sourcePath:/proc}},{name:sys,host:{sourcePath:/sys}}],taskRoleArn:arn:aws:iam::123456789012:role/ecsCloudWatchAgentRole,executionRoleArn:arn:aws:iam::123456789012:role/ecsTaskExecutionRole}几个注意点privileged: true让 Agent 能访问主机级资源挂载了/proc和/sys采集系统指标必备CPU 给了 1 vCPU内存 512 MB根据你的 Agent 负载调整任务执行角色别忘了不然拉镜像就报错第二步关联到集群容量提供商进入集群页面找到新的Daemons选项卡。点击创建。用 AWS CLI 的话先准备配置文件{clusterArn:arn:aws:ecs:us-east-1:123456789012:cluster/my-production-cluster,daemonName:cloudwatch-agent-daemon,daemonTaskDefinitionArn:arn:aws:ecs:us-east-1:123456789012:daemon-task-definition/cloudwatch-agent-daemon:1,capacityProviderArns:[arn:aws:ecs:us-east-1:123456789012:capacity-provider/my-managed-cp]}然后一条命令搞定aws ecs create-daemon --cli-input-json file://create-daemon.json执行完之后Amazon ECS 会自动在对应容量提供商的每台托管实例上启动一个守护进程任务。第三步验证部署控制台里看 Daemons 选项卡状态变成Active就说明成功了。CLI 验证# 列出集群下所有 daemonaws ecs list-daemons\--cluster-arn arn:aws:ecs:us-east-1:123456789012:cluster/my-production-cluster# 查看 daemon 详情aws ecs describe-daemons\--daemon-arn arn:aws:ecs:us-east-1:123456789012:daemon/my-production-cluster/cloudwatch-agent-daemon部署完成后新启动的应用任务会自动享有监控覆盖。不需要应用团队做任何改动。更新守护进程滚动部署 自动回滚这才是我觉得这个功能真正香的地方。假设 Amazon CloudWatch Agent 出了新版本我要全集群更新。以前需要协调 200 个团队现在呢aws ecs update-daemon\--daemon-arn arn:aws:ecs:us-east-1:123456789012:daemon/my-production-cluster/cloudwatch-agent-daemon\--daemon-task-definition-arn arn:aws:ecs:us-east-1:123456789012:daemon-task-definition/cloudwatch-agent-daemon:2一条命令全集群滚动更新。更新策略是这样的按配置的 drain 百分比分批操作默认 25%先在新实例上启动新版本守护进程把应用任务迁移到新实例关停旧实例这种「先启动后停止」的策略保证了更新过程中监控不中断。如果新版本有问题呢内置了断路器保护。你还可以配置 bake time 和 Amazon CloudWatch 告警Bake time更新完所有实例后等待 N 分钟等待期间 Amazon CloudWatch 告警触发就自动回滚不用你盯着不用你手动操作之前踩过一个坑Agent 新版本内存泄漏跑了两小时后 OOM。以前发现问题要挨个通知团队回滚现在有了自动回滚心里踏实多了。资源管理不再挤占应用资源以前 sidecar 模式下Agent 的 CPU 和内存是在应用的 task definition 里分配的。应用团队经常抱怨“你的 Agent 吃了我 512 MB 内存”现在守护进程的资源定义完全独立。一台实例只跑一个守护进程副本多个应用任务共享这一个 Agent。对比一下场景以前sidecar现在Managed Daemon一台实例跑 10 个任务10 个 Agent 副本1 个 Agent 副本内存开销Agent 512MB5120 MB512 MB更新方式改 10 个 task definition1 条命令协调成本协调 N 个团队平台团队自己搞定资源利用率的提升是实打实的。自动修复守护进程挂了怎么办如果守护进程任务停止了Amazon ECS 会自动排空并替换那台容器实例。说白了就是守护进程是实例健康的判断标准之一。Agent 挂了 实例不健康 自动替换。这个行为保证了集群中所有实例都稳定运行着守护进程不用人工巡检。我的踩坑记录折腾了两天几个坑记录下来坑 1任务执行角色权限不足daemon task definition 里的executionRoleArn需要有 Amazon ECR 拉镜像的权限。如果你用的是公共镜像比如public.ecr.aws记得角色策略里加上ecr-public:GetAuthorizationToken。坑 2忘了配置容量提供商创建 daemon 时必须指定capacityProviderArns而且必须是 Amazon ECS 托管实例类型的容量提供商。Fargate 类型的不行。坑 3UpdateDaemon 不会保留上次配置这个坑比较隐蔽。每次调用UpdateDaemon时你必须传入完整的配置。没传的字段会恢复默认值。比如你上次启用了 ECS Exec更新时没带上这个参数就会被关掉。官方文档里有 Important 提示但说实话一开始没注意到。适用场景和迁移建议这个功能适合什么场景监控代理Amazon CloudWatch Agent、自建 Prometheus exporter日志采集Fluent Bit、Fluentd链路追踪AWS X-Ray daemon、OpenTelemetry Collector安全代理主机入侵检测、合规扫描工具网络代理Service Mesh sidecar proxy 等需要实例级别运行的组件核心特征需要在每台实例上运行一份、需要主机级访问权限、更新频率和应用不同步。如果你现在还在用 sidecar 模式跑这些 Agent建议按以下步骤评估迁移盘点现有 sidecar Agent 清单梳理每个 Agent 的更新频率确认集群已使用 Amazon ECS 托管实例容量提供商先拿一个非关键 Agent 在测试环境试跑验证 daemon_bridge 网络模式下数据采集正常配置好 Amazon CloudWatch 告警和 bake time 再上生产迁移过程中有个小技巧可以先保留 sidecar同时部署 Managed Daemon。等确认 Daemon 采集数据正常后再从 task definition 里移除 sidecar。双保险不丢数据。费用用托管守护进程不收额外费用。你只需要为守护进程任务消耗的标准计算资源付费。说白了就是 Agent 跑在 EC2 上本来就要吃资源现在只是换了个管理方式不多收钱。总结Amazon ECS Managed Daemons 解决了一个困扰平台工程师很久的问题更新基础设施组件不应该依赖应用团队的发布周期。该功能目前已在所有亚马逊云科技区域可用。如果你也受够了协调 N 个团队更新 Agent 的日子赶紧试试。参考资料亚马逊云科技官博https://aws.amazon.com/cn/blogs/china/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/Amazon ECS 托管守护进程文档https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons.html创建和管理守护进程https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons-create-manage.html