Codex 在 Amazon Bedrock 上的可观测性：借助 OpenTelemetry 与 CloudWatch 实现

一句话看懂

AWS 发布新方案，让企业通过 OpenTelemetry 和 CloudWatch 监控 Codex 在 Amazon Bedrock 上的使用情况，实现按用户、团队和成本中心的可视化。

详细发生了什么

AWS 机器学习博客发布了一篇新文章，介绍如何为 Codex（OpenAI 的编码代理）在 Amazon Bedrock 上构建可观测性。随着工程团队从尝试编码代理转向全面采用，领导者需要了解采用率、消费情况和可靠性。文章提出了一种解决方案：通过本地 OpenTelemetry (OTel) collector 将 Codex 的遥测数据路由到 Amazon CloudWatch，实现 AWS 原生的使用视图。

该方案不引入集中式代理，开发者仍可在本地使用 Codex。每个开发者工作站上的 collector 接收本地主机上的指标，并添加组织上下文（如用户、团队、成本中心），然后通过 SigV4 认证发送到 CloudWatch 的 OTLP 端点。参考部署创建了一个 CloudWatch 仪表盘，无需 ECS 服务、负载均衡器或 VPC。

文章详细说明了如何将遥测转化为业务决策，例如通过活跃用户数判断采用是否扩大，通过 token 使用量定位消费集中点，通过工具调用量了解代理工作流的使用情况。还强调了 CloudWatch 指标不是计费账本，实际成本应使用 AWS Cost and Usage Reports (CUR) 2.0 的 IAM principal 数据。

实现分为五个阶段：启用 CloudWatch OTel 功能、部署仪表盘和构建 collector、生成开发者配置、配置 Codex 并授予最小权限、验证完整流程。配置示例中，Codex 的 metrics exporter 指向本地 collector，并明确要求保留 log_user_prompt = false，以避免收集源代码或提示内容。

中文圈视角

对于中文用户，这个方案有几点值得关注。首先，Codex 本身是 OpenAI 的产品，国内用户需要梯子才能访问，但通过 Amazon Bedrock 接入后，企业用户可以通过 AWS 中国区或全球区合规使用，不过仍需注意数据出境问题。其次，国内也有类似的编码代理，如阿里云的通义灵码、百度的 Comate，它们可能提供类似的可观测性功能，但基于国产模型。如果团队已经在使用 Codex 和 AWS，这个方案可以直接借鉴；否则，可以考虑国内云厂商的监控方案，如阿里云 ARMS 或腾讯云监控。另外，文章强调的“遥测数据用于决策而非单纯仪表盘”理念，对国内企业同样适用，尤其是在成本控制和团队效率评估方面。

几条值得记住的细节

Codex 通过 OTel 发出指标，如 codex.api_request、codex.turn.token_usage 等，但 OTel 是 opt-in 的。
本地 collector 监听 127.0.0.1:4318，避免暴露到网络。
配置中必须包含完整的 /v1/metrics 路径，因为 Codex 不会自动添加。
发布身份只需 cloudwatch:PutMetricData 权限，无需日志组或 ECS 权限。
仪表盘提供 24 小时滚动视图，包括活跃用户、对话轮次、API 请求和 token 使用量。

一句话总结

这个方案让企业能像监控其他服务一样监控 Codex 的使用，对成本控制和团队管理很有价值。