用 OpenTelemetry 和 CloudWatch 看清 Codex 的采用率、用量与可靠性

2026-08-07 48 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

当 Codex 这类编码代理从个人试用进入团队工作流，管理问题也随之变化：哪些团队正在使用、调用量如何增长、服务是否稳定，以及成本应该归属到哪里。仅靠个人反馈或月底账单，很难回答这些问题。

一种 AWS 原生的实现路径是：让 Codex 输出 OpenTelemetry 指标，将数据发送到本地 OpenTelemetry Collector，再由 Collector 写入 Amazon CloudWatch。这样既能保留开放的遥测协议，也能使用 CloudWatch 仪表盘、告警和权限体系进行统一运营。

遥测链路如何拆分职责

这条链路可以分成三层：

  1. Codex 负责产生信号：输出调用量、延迟、错误等 OpenTelemetry 指标。
  2. 本地 Collector 负责处理数据：接收 OTLP 数据，补充资源属性，执行过滤、批处理或采样。
  3. CloudWatch 负责运营视图：按用户、团队和成本中心聚合指标，并建立仪表盘与告警。

Collector 是其中最重要的边界。应用不需要直接依赖 CloudWatch 的指标格式，团队也可以在 Collector 中集中处理标签规范、敏感字段和发送策略。将来更换或增加后端时，Codex 侧的改动通常更小。

对于组织维度，建议至少定义这些资源属性：

  • service.name：固定标识 Codex 工作负载。
  • user.id：使用稳定的内部标识，避免写入姓名或邮箱。
  • team：用于观察团队采用率。
  • cost_center：用于成本归属。
  • deployment.environment：区分开发、测试和生产环境。

维度并非越多越好。用户、仓库、会话和任务同时作为 CloudWatch 维度，可能迅速增加自定义指标数量和费用。高基数信息更适合日志或追踪，而不是长期保留为指标维度。

可以这样搭建本地 Collector

下面是一个可改造的最小示例。它假设 Codex 能通过标准 OTLP/HTTP 接口导出指标，本机已经配置可写入 CloudWatch 的 AWS 凭证。实际部署前，应根据当前 Codex 版本确认支持的 OpenTelemetry 配置项和指标名称。

创建 otel-collector.yaml：

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 256
  resource:
    attributes:
      - key: telemetry.pipeline
        value: codex-local-collector
        action: upsert
  batch:
    timeout: 10s

exporters:
  awsemf:
    region: us-east-1
    namespace: Engineering/Codex
    log_group_name: /engineering/codex/metrics
    log_stream_name: local-collector
    dimension_rollup_option: NoDimensionRollup
    resource_to_telemetry_conversion:
      enabled: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [awsemf]

将 region、命名空间和日志组改为组织实际使用的值，然后启动 AWS Distro for OpenTelemetry Collector：

docker run --rm \
  --name codex-otel-collector \
  -p 4318:4318 \
  -v "$PWD/otel-collector.yaml:/etc/otelcol/config.yaml:ro" \
  -v "$HOME/.aws:/root/.aws:ro" \
  -e AWS_PROFILE=default \
  public.ecr.aws/aws-observability/aws-otel-collector:latest \
  --config=/etc/otelcol/config.yaml

接着，在启动 Codex 的同一个 shell 中设置标准 OpenTelemetry 环境变量。下面的资源属性只是示例，应该由登录身份、设备管理系统或团队启动脚本注入，而不是依赖开发者手工填写：

export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4318"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_RESOURCE_ATTRIBUTES="service.name=codex,user.id=u-1042,team=payments,cost_center=cc-310,deployment.environment=development"

# 在这里运行组织当前使用的 Codex 启动命令
codex

如果 Collector 运行在容器中，而 Codex 也运行在另一个容器中，127.0.0.1 将指向各自容器，不能直接通信。此时应把两个容器放入同一 Docker 网络，并将端点改为 Collector 的容器名。

从原始指标变成管理视图

数据进入 CloudWatch 后，不要只做一张“总调用量”图。一个真正可运营的仪表盘通常至少回答四类问题：

  • 采用情况：活跃用户数、活跃团队数、每日或每周用量趋势。
  • 消费情况：按团队和成本中心汇总的请求量或其他用量指标。
  • 可靠性：错误数、错误率、延迟分位数，以及 Collector 导出失败情况。
  • 数据质量：缺失 team 或 cost_center 的数据比例，避免报表看似完整但无法归属。

告警也应围绕可行动的问题设置。例如，连续多个周期没有任何指标，可能表示 Collector 停止、凭证失效或网络受阻；错误率突然升高则可能表示服务异常或客户端配置发生变化。

需要注意，CloudWatch 指标适合趋势和聚合，不适合保存提示词、生成代码或完整会话内容。这些内容不仅基数高，还可能包含源代码、凭证或客户数据。Collector 中应只保留治理需要的属性，并对允许上报的字段建立明确白名单。

推广前的检查清单

正式推广时，可以按下面的顺序收敛风险：

  • 先选择一个团队试点，验证指标名称、单位、标签和更新时间。
  • 使用稳定的匿名用户 ID，不把邮箱、姓名、仓库地址或提示词作为指标维度。
  • 为 team 和 cost_center 建立受控枚举，避免同一团队出现多个拼写。
  • 对 CloudWatch 自定义指标数量和日志摄入量设置预算告警。
  • 同时监控 Collector 自身，尤其是队列积压、丢弃数据和导出错误。
  • 使用最小权限 IAM 策略，只授予 Collector 写入目标日志组和指标所需的权限。

这套架构的价值不只是生成一张使用量图表，而是把编码代理纳入现有的工程治理体系。OpenTelemetry 保留了数据管道的可移植性，CloudWatch 则提供 AWS 环境中的查询、告警、权限和成本管理能力。关键是从少量、稳定、低基数的指标开始，再根据真实运营问题扩展，而不是一次收集所有可能的数据。

# AI # AWS # LLM # 云平台 # 全栈 # 机器学习

相关推荐