用 OpenTelemetry 和 CloudWatch 为 Amazon Bedrock 上的 Codex 构建可观测性

当 Codex 通过 Amazon Bedrock 作为模型提供方运行，并借助 AWS IAM Identity Center 完成身份认证时，开发者工作站上的本地 OTel 采集器会监听 127.0.0.1 端口，接收 Codex 发出的各类指标，包括 API 请求数、请求时延、端到端对话时延、Token 用量、工具调用次数、会话启动数以及对话轮次数。采集器随后为每条指标附加用户身份和组织属性，批量签名后推送至 CloudWatch 区域 OTLP 端点。整个过程不经过 Amazon Bedrock 推理链路，不引入额外的网络跳转或集中式代理节点。

参考部署内置了一个名为 CodexOnBedrock 的 CloudWatch 仪表板，提供滚动 24 小时的活跃用户数、对话轮次、API 请求量和 Token 用量汇总，并支持按模型、Token 类型、用户、部门、团队、成本中心、组织和会话来源进行多维度切片。技术领导者可以通过这些信号区分广泛采用与局部试验：跨多个团队的活跃用户增长与少数用户的高消耗集中，代表截然不同的启用策略需求；工具调用量则可揭示智能体工作流在哪些场景真正落地。

实施该方案分为五个阶段。首先在目标区域启用 CloudWatch OTel 富化和资源标签遥测能力；其次克隆参考仓库，通过 CloudFormation 部署仪表板并在本地构建采集器二进制文件；第三步为每位开发者生成个性化采集器配置，脚本可通过 --auto-lookup 参数从 IAM Identity Center 身份存储中自动读取组织属性，也支持命令行显式覆盖。需要注意的是，若某个可选属性无法获取，应直接省略对应配置块，而非填入占位字符串，否则会产生低价值的指标序列并降低报表质量。

在成本归因方面，该方案明确区分了两类数据的用途。CloudWatch OTel 指标反映的是使用量和运营行为，Token 计数可用于趋势分析，但不能作为计费账本。由于定价变动、折扣、信用额度和账单调整等因素，基于标价的估算可能与实际费用存在偏差。若需获取真实支出数据，应使用 AWS Cost and Usage Reports 2.0 中的 IAM 主体成本分配报告，或 Amazon Bedrock 专项成本管理报告，两者才能提供账单级别的财务核算与分摊依据。

从治理视角看，这套架构的核心价值在于将遥测数据与业务决策直接挂钩。仪表板中的每类信号都对应一个可操作的管理问题：活跃用户趋势决定是否扩大试点或聚焦入职培训；按部门和成本中心的 Token 消耗决定在哪里实施成本回溯或调整配额；API 状态和请求时延则支撑对模型访问、网络或客户端行为的故障排查。这种将可观测性与决策框架对齐的设计思路，为企业在规模化推广编程智能体时提供了可复用的治理范式。

要点

• 本地 OTel 采集器在不侵入 Amazon Bedrock 推理链路的前提下，将 Codex 指标路由至 CloudWatch，实现零代理开销的可观测性。
• 仪表板支持按用户、团队、部门和成本中心多维切片，帮助领导者区分广泛采用与局部高消耗两种截然不同的场景。
• CloudWatch OTel 指标适用于使用量趋势分析，真实账单级成本归因须依赖 AWS CUR 2.0 的 IAM 主体成本分配报告。
• 组织属性可通过 IAM Identity Center 自动发现并注入指标，缺失属性应省略而非填充占位符，以保证报表维度质量。
• 该参考架构将遥测信号与具体管理决策一一对应，为企业规模化落地编程智能体提供了可复用的治理框架。