AI 采集器：Claude Code、OpenAI、LiteLLM 监控

zhanghongbin01

220人浏览 · 2026-04-11 11:33:49

zhanghongbin01 · 2026-04-11 11:33:49 发布

AI 采集器：Claude Code、OpenAI、LiteLLM 监控

深入了解 AI Observability Agent 的 AI 专用采集能力

AI 监控的挑战

在大模型时代，企业和开发者面临着独特的监控挑战：

挑战	传统监控的局限	AI 采集器的解决
多源数据	各 AI 工具指标格式不统一	统一采集接口
成本透明	无法追踪 AI API 调用成本	实时成本计算
Token 监控	不支持 Token 维度分析	细粒度 Token 统计
质量评估	缺少 AI 服务质量指标	响应时间、错误率监控
平台差异	不同 AI 平台接口不同	统一抽象层

内置 AI 采集器

AI Observability Agent 提供了多种 AI 专用采集器，覆盖主流 AI 平台：

1. OpenAI Usage API 采集器

功能：从 OpenAI Usage API 采集使用数据

配置示例：

ai_collectors:
  enabled: true
  
  openai:
    - name: openai_usage
      enabled: true
      api_key: ${OPENAI_API_KEY}      # OpenAI API Key
      org_id: ${OPENAI_ORG_ID}        # 组织 ID（可选）
      scrape_interval_secs: 3600      # 采集间隔（默认 1 小时）
      labels:
        source: openai
        environment: production

采集的指标：

指标名	类型	标签	说明
`ai_requests_total`	Counter	`model`, `provider`, `source`	请求总数
`ai_tokens_input_total`	Counter	`model`, `provider`, `source`	输入 Token 总数
`ai_tokens_output_total`	Counter	`model`, `provider`, `source`	输出 Token 总数
`ai_tokens_cache_read_total`	Counter	`model`, `provider`, `source`	缓存读取 Token 数
`ai_tokens_cache_write_total`	Counter	`model`, `provider`, `source`	缓存写入 Token 数
`ai_cost_usd_total`	Counter	`model`, `provider`, `source`	成本（美元）

工作原理：

定期调用 OpenAI Usage API
解析返回的使用数据
按模型、时间等维度聚合
计算成本并生成指标
推送到远程存储

API 端点：

# 查看所有 AI 采集器
curl http://localhost:9090/api/v1/ai-collectors | jq

# 启用 OpenAI 采集器
curl -X POST http://localhost:9090/api/v1/ai-collectors/openai_usage/enable

# 禁用 OpenAI 采集器
curl -X POST http://localhost:9090/api/v1/ai-collectors/openai_usage/disable

2. LiteLLM Proxy 采集器

功能：从 LiteLLM Proxy 的 /metrics 端点采集指标

配置示例：

ai_collectors:
  enabled: true
  
  litellm:
    - name: litellm_proxy
      enabled: true
      endpoint: http://localhost:4000  # LiteLLM Proxy 地址
      metrics_path: /metrics           # 指标路径
      auth_token: ${LITELLM_TOKEN}     # 认证 Token（可选）
      scrape_interval_secs: 60         # 采集间隔
      labels:
        source: litellm
        environment: production

采集的指标：

指标名	类型	标签	说明
`ai_requests_total`	Counter	`model`, `provider`, `source`	请求总数
`ai_tokens_total`	Counter	`model`, `provider`, `source`	Token 总数
`ai_request_latency_seconds`	Histogram	`model`, `provider`, `source`	请求延迟
`ai_cost_usd_total`	Counter	`model`, `provider`, `source`	成本（美元）
`ai_errors_total`	Counter	`model`, `provider`, `source`	错误总数

工作原理：

定期抓取 LiteLLM /metrics 端点
解析 Prometheus 格式的指标
转换为统一的 AI 指标格式
推送到远程存储

LiteLLM 配置：

# config.yaml
litellm_settings:
  callbacks:
    - prometheus

model_list:
  - model_name: gpt-4
    litellm_params:
      model: gpt-4
      api_key: ${OPENAI_API_KEY}

3. 统一指标格式

所有 AI 采集器输出的指标都使用统一格式，便于统一监控和分析：

核心指标：

指标名	类型	说明
`ai_requests_total`	Counter	请求总数
`ai_tokens_input_total`	Counter	输入 Token 总数
`ai_tokens_output_total`	Counter	输出 Token 总数
`ai_tokens_cache_read_total`	Counter	缓存读取 Token 数
`ai_tokens_cache_write_total`	Counter	缓存写入 Token 数
`ai_cost_usd_total`	Counter	成本（美元）
`ai_request_latency_seconds`	Histogram	请求延迟
`ai_errors_total`	Counter	错误总数

统一标签：

标签	说明
`source`	数据来源（openai, litellm, claude_code 等）
`provider`	AI 提供商（openai, anthropic, azure 等）
`model`	模型名称（gpt-4o, claude-3-opus 等）
`environment`	环境（production, staging, development）

指标命名规范：

使用 ai_ 前缀
采用 snake_case 命名
包含单位（如 _seconds, _total）
保持一致性

集成场景

1. OpenAI API 集成

场景：企业使用 OpenAI API 开发应用

配置：

# config/agent_config.yaml
ai_collectors:
  enabled: true
  
  openai:
    - name: openai_production
      enabled: true
      api_key: ${OPENAI_API_KEY}
      org_id: ${OPENAI_ORG_ID}
      scrape_interval_secs: 3600
      labels:
        source: openai
        environment: production

cost_tracking:
  enabled: true
  budget:
    daily_limit_usd: 500
    monthly_limit_usd: 10000

remote_write:
  endpoint: http://prometheus:9090/api/v1/write

使用示例：

# 查看 OpenAI 成本
curl http://localhost:9090/api/v1/costs | jq

# 查看预算状态
curl http://localhost:9090/api/v1/budget | jq

# PromQL 查询
# 按模型分组的成本
sum by (model) (ai_cost_usd_total{source="openai"})

# 按天的 Token 使用趋势
sum by (model, date) (rate(ai_tokens_input_total{source="openai"}[1d]))

2. LiteLLM Proxy 集成

场景：企业内部部署 LiteLLM Proxy 统一管理 AI API

配置：

# config/agent_config.yaml
ai_collectors:
  enabled: true
  
  litellm:
    - name: litellm_proxy
      enabled: true
      endpoint: http://litellm-proxy:4000
      metrics_path: /metrics
      scrape_interval_secs: 60
      labels:
        source: litellm
        environment: production

remote_write:
  endpoint: http://prometheus:9090/api/v1/write

LiteLLM 配置：

# litellm_config.yaml
litellm_settings:
  callbacks:
    - prometheus
  
model_list:
  - model_name: gpt-4o
    litellm_params:
      model: gpt-4o
      api_key: ${OPENAI_API_KEY}
  
  - model_name: claude-3-opus
    litellm_params:
      model: claude-3-opus-20240229
      api_key: ${ANTHROPIC_API_KEY}
      base_url: https://api.anthropic.com/v1

使用示例：

# 查看 LiteLLM 指标
curl http://localhost:9090/api/v1/ai-collectors | jq

# PromQL 查询
# 各模型的请求延迟
histogram_quantile(0.95, sum by (model, le) (rate(ai_request_latency_seconds_bucket{source="litellm"}[5m])))

# 错误率
sum by (model) (rate(ai_errors_total{source="litellm"}[5m])) / sum by (model) (rate(ai_requests_total{source="litellm"}[5m]))

3. 多源数据聚合

场景：同时使用多个 AI 平台，需要统一监控

配置：

# config/agent_config.yaml
ai_collectors:
  enabled: true
  
  openai:
    - name: openai_usage
      enabled: true
      api_key: ${OPENAI_API_KEY}
      labels:
        source: openai
  
  litellm:
    - name: litellm_proxy
      enabled: true
      endpoint: http://litellm-proxy:4000
      labels:
        source: litellm

otlp:
  enabled: true
  grpc_endpoint: 0.0.0.0:4317
  labels:
    source: claude_code

remote_write:
  endpoint: http://prometheus:9090/api/v1/write

PromQL 查询：

# 所有 AI 平台的总成本
sum(ai_cost_usd_total)

# 按提供商分组的请求数
sum by (provider) (ai_requests_total)

# 按模型分组的 Token 使用量
sum by (model) (ai_tokens_input_total + ai_tokens_output_total)

最佳实践

1. 配置最佳实践

API Key 管理：

使用环境变量存储 API Key
避免硬编码到配置文件
定期轮换 API Key

采集间隔：

OpenAI Usage API：建议 1 小时（API 限制）
LiteLLM：建议 1-5 分钟（实时监控）
Claude Code (OTLP)：由客户端控制

标签使用：

添加有意义的标签（如 environment, team, project）
避免高基数标签
保持标签一致性

2. 监控最佳实践

关键指标监控：

成本：ai_cost_usd_total
Token 使用：ai_tokens_input_total, ai_tokens_output_total
请求量：ai_requests_total
错误率：ai_errors_total
延迟：ai_request_latency_seconds

告警设置：

成本告警：每日/每月成本超过阈值
错误告警：错误率超过 5%
延迟告警：P95 延迟超过 5 秒
Token 异常：Token 使用量突增

Dashboard 设计：

总览面板：总成本、总请求数、错误率
成本分析：按模型、提供商、时间的成本分布
性能面板：延迟分布、错误率趋势
Token 分析：Token 使用趋势、效率分析

3. 性能优化

减少 API 调用：

合理设置 OpenAI 采集间隔
避免频繁调用 Usage API

数据处理优化：

启用批处理
调整缓冲区大小
优化并发发送

存储优化：

合理设置 Prometheus 存储保留期
使用降采样减少存储量
考虑使用 VictoriaMetrics 等长期存储

故障排查

1. OpenAI 采集器问题

症状：

无 OpenAI 指标
日志中出现 API 错误

排查步骤：

检查 API Key 是否正确
验证 API Key 权限
查看 Agent 日志
手动调用 OpenAI Usage API 验证

常见错误：

401 Unauthorized：API Key 错误
429 Too Many Requests：API 调用频率过高
500 Internal Server Error：OpenAI 服务问题

2. LiteLLM 采集器问题

症状：

无 LiteLLM 指标
抓取失败

排查步骤：

检查 LiteLLM 服务是否运行
验证 /metrics 端点可访问
检查认证 Token（如果配置）
查看 Agent 日志

常见错误：

Connection refused：LiteLLM 服务未运行
404 Not Found：metrics 路径错误
401 Unauthorized：认证 Token 错误

3. 指标缺失

症状：

部分指标缺失
指标值为 0

排查步骤：

检查 AI 服务是否有实际使用
验证采集器配置
查看 Agent 日志中的错误
检查远程存储配置

未来扩展

计划支持的 AI 平台

平台	状态	计划时间
OpenAI	✅ 已支持	-
LiteLLM	✅ 已支持	-
Claude Code (OTLP)	✅ 已支持	-
Azure OpenAI	🔄 开发中	Q3 2024
Anthropic	🔄 开发中	Q3 2024
Google Gemini	📋 计划中	Q4 2024
Mistral	📋 计划中	Q4 2024

增强功能

实时成本估算：基于 Token 使用量实时估算成本
使用模式分析：识别异常使用模式
优化建议：基于历史数据提供成本优化建议
多组织支持：支持多个 OpenAI 组织
细粒度权限：基于角色的访问控制

总结

AI Observability Agent 的 AI 采集器为企业和开发者提供了全面的 AI 工具监控能力：

多平台支持：覆盖 OpenAI、LiteLLM、Claude Code 等主流 AI 平台
统一指标：所有 AI 平台使用统一的指标格式
实时成本追踪：实时计算 AI API 成本
细粒度监控：Token 级别的使用分析
易集成：简单的配置即可开始监控

通过 AI 采集器，企业可以更好地管理 AI 服务的成本、性能和质量，实现 AI 资源的优化使用。

下一步

成本追踪 - AI API 成本计算与预算管理
质量监控 - AI 服务质量评估
Grafana 可视化 - 开箱即用的监控面板

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

2026年主流智能体推荐：可信AI时代的智能体选型指南

AtomGit开源社区

机器人工程毕设 stm32与深度学习口罩佩戴检测系统(源码+硬件+论文)

本文介绍了一个基于STM32与深度学习的口罩佩戴检测系统，该系统结合硬件与软件实现实时检测与报警功能。系统框架分为上位机和下位机两部分：上位机通过深度学习模型进行口罩识别，并将结果通过WiFi传输给下位机；下位机以STM32为核心，接收数据并通过OLED显示检测结果，当检测到未佩戴口罩时触发蜂鸣器报警。硬件部分采用STM32F103RCT6开发板、ESP8266 WiFi模块、OLED显示屏等组件

AtomGit开源社区

【原创改进代码】考虑电动汽车移动储能特性的多区域电网功率波动平抑优化调控研究（Python代码实现）

在高比例光伏、风电等间歇性分布式电源大规模接入电网的背景下，多区域配电网功率波动问题日益突出，传统固定储能与单区域 V2G 调控难以满足系统稳定运行需求。电动汽车作为海量分布式移动储能载体，其跨区域出行行为为电网功率波动协同平抑提供了新型调控思路。本文提出一种充分考虑电动汽车移动储能特性的多区域电网功率波动平抑优化调控方法，以居民区、商业区、工业区三区域互联电网为研究对象，将电动汽车视为可跨区域调