在 Amazon Bedrock 上通过 OpenTelemetry 与 CloudWatch 实现 Codex 使用可视化
随着工程团队从尝试编码代理（如 Codex）转向全面采用，领导者关注的焦点从“这个工具能否帮助开发者？”转变为“我们如何理解采用情况、管理消耗、维护可靠性并负责任地扩展访问？”。Codex 能够输出关于其活动的 OpenTelemetry（OTel）指标。当本地 Codex 客户端通过 Amazon Bedrock 使用 OpenAI 模型，并使用 AWS IAM Identity Center 进行身份验证时，你可以通过本地 OTel 收集器将这些指标路由到 Amazon CloudWatch，从而获得按用户、团队、部门、组织或成本中心组织的 AWS 原生视图。这种方法不会在模型请求路径中引入集中式代理。开发者继续在本地使用 Codex，每个开发者工作站上运行的收集器接收本地主机上的指标，并为其补充组织上下文，然后使用 AWS 签名版本 4（SigV4）将其发送到区域 CloudWatch OpenTelemetry 协议（OTLP）端点。参考部署创建了 CloudWatch 仪表板，而不是 Amazon ECS 服务、负载均衡器、VPC 或公共摄取端点。本文解释了这种模式如何支持受治理的采用，审查其架构，并总结了 Codex on AWS 指南仓库中的实现。
将遥测转化为业务决策
遥测只有在回答决策问题时才最有用，而不仅仅是生成另一个仪表板。捆绑的 CodexOnBedrock 仪表板包含活跃用户数、对话轮次、API 请求数和令牌使用量的滚动 24 小时总计。它还提供按模型、令牌类型、用户、部门、团队、成本中心、组织和会话来源的视图。这些信号可以帮助技术领导者区分广泛采用与孤立实验。例如，活跃用户数在多个团队中的增加表明需要不同的赋能支持，而消耗集中在少数用户则提示不同的关注点。工具调用活动可以帮助团队了解代理工作流在哪些地方扎根。请求和持续时间指标可以支持对体验降级的调查。
| 高管问题 | 可用信号 | 可辅助的决策 |
|---|---|---|
| Codex 采用是否在扩大？ | 活跃用户、线程、轮次和 API 请求 | 是否扩大试点或专注于入职培训 |
架构概览
该架构的关键在于本地收集器。每个开发者的工作站上运行一个 OTel 收集器，它从本地 Codex 客户端接收指标，并添加组织属性（如用户、团队、成本中心），然后通过 SigV4 认证发送到 CloudWatch。这种设计避免了集中式代理，保持开发者的本地体验不变，同时提供集中的可见性。
实施要点
参考实现位于 Codex on AWS 指南仓库中。它提供了 CloudFormation 模板和配置，用于设置仪表板、IAM 角色和本地收集器配置。实施步骤包括：
- 配置 Codex 以使用 Bedrock 作为模型提供方，并设置 IAM Identity Center 认证。
- 在开发者工作站上安装并配置 OTel 收集器，指定 CloudWatch OTLP 端点。
- 部署 CloudFormation 模板以创建仪表板和必要的 IAM 权限。
- 验证指标是否正确到达 CloudWatch。
这种模式使组织能够以 AWS 原生的方式监控编码代理的使用，同时保持开发者的工作流程不变。对于希望负责任地扩展 AI 编码工具的企业，这是一个实用的解决方案。
