用量监控

一、先给 Key 建命名规范

org-product-env-purpose-owner

org    = tb
product=docbot
env    =prod
purpose=summary
owner  =li-ning

实际 Key 名称：
tb-docbot-prod-summary-li-ning

命名里至少要有项目、环境和用途。这样看用量时能直接定位到“哪个项目在消耗”，而不是一个模糊的 test key。

二、最小监控面板

三、日报结构

• 昨日消耗最高的前五个项目。
• 与上周同日对比的百分比变化。
• 异常 Key：今天消耗超过过去 7 天平均 3 倍的。
• 新增 Key、停用 Key、即将过期 Key。
• 失败率最高的接口。

四、告警阈值

告警规则：
1. 单 Key 每小时请求数 > 10000
2. 单项目每日消耗 > 昨日 220%
3. 单项目失败率 > 8%
4. P95 时延 > 30s
5. 任何 key 出现在非白名单 IP

所有阈值都要避免单点误报。例如可以先发出低级别通知，连续 10 分钟才升级。

五、出问题时怎么看

• 先看是哪个 key，再看哪个模型，最后看是哪个接口。
• 如果是同步调用，检查是否有代码在重试循环。
• 如果输出长度陡增，检查是否有人改了提示词。
• 如果是新项目，可能是没有设置 max_output。
• 如果是某个模型暴涨，检查模型分流规则是否被改动。

六、把监控接入业务

只看平台日报不够，要在业务代码里加轻量埋点：

{
  "trace_id": "req-20261022-001",
  "project": "docbot",
  "key_name": "tb-docbot-prod-summary-li-ning",
  "model": "gpt-6.1-sol",
  "purpose": "summary",
  "input_tokens": 2310,
  "output_tokens": 572,
  "latency_ms": 1830,
  "status": 200,
  "retry": 0
}

只要记录这 10 个字段，后续定位异常时至少能省一半时间。

七、常见坑

• 没有记录 trace_id，无法和平台账单对齐。
• 只记 tokens，不记模型名，路由变化后无法分析。
• 把重试记成一次，导致低估成本。
• 聚合粒度太粗，问题发生到三天后才发现。

八、日报样例

每日用量日报：2026-10-22
Top 项目：
1. docbot    $146    +12% vs 7d avg
2. etl       $84     +9%
3. crm       $37     -4%

异常：
- tb-etl-prod-embed-wang-qiang: 4.1x 请求量
- tb-docbot-prod-summary-li-ning: 平均输出 tokens +22%

失败率：
- /v1/chat/completions 3.1%
- /v1/embeddings 6.1%
新 Key：
- tb-crm-prod-classify-zhang-wei

九、人员分工

• 项目负责人：确认业务是否有新任务。
• 技术负责人：确认模型、提示词和代码是否变化。
• 平台管理员：确认额度、告警和白名单。
• 财务：确认预算报表和分摊。

这四个人都在日报链路里，异常才不会悬空。

十、看什么指标先报警

优先级从高到低：泄露、刷量、关键队列失败率、预算超速、模型路由失误。日常日报里最关键的不是总消耗，而是变化量——今天是正常波动还是异常爆发。

十一、接入建议

如果刚起步，可以先不建独立监控系统，只用三张 CSV：日用量、项目列表、key 列表。每周合并一次，能解决 80% 异常。等业务量上去后再接自动化告警。

做法为本站整理；平台用量图配合外部日志使用效果更好。