监控与排障
请求失败时，这一页帮你定位到是哪个凭据、哪一步出的问题。
四个标签页§
监控页分四块，各管一件事：
- 健康——现在哪些凭据可用、哪些出了问题
- 用量与成本——花了多少 token、多少钱
- 请求日志——每一条请求的详细记录
- 路由检查——给定条件，看网关会怎么选
健康§
健康页给出当前每个分组、每个凭据的可用状态， 以及需要注意的问题清单。
凭据的状态含义：
- 可用——正常参与轮转
- 冷却中——刚被上游限流或报错，暂时跳过，到点自动恢复
- 已拉黑——连续失败超过阈值，自动摘除，需要人工确认后恢复
- 已停用——你手动关掉的，不参与轮转
冷却和拉黑的触发条件、恢复方式见 调度是怎么做的。
有问题的凭据会集中列出，不用逐个分组翻。
请求日志§
每条请求都有记录，可以按时间、分组、模型、状态等条件筛选。点开单条能看到完整链路：用了哪个凭据、 是否发生过协议转换、重试了几次、上游返回了什么。
排障时最有用的几个字段：
- 路由身份——这条请求实际走了哪个分组、哪个凭据
- 协议转换——客户端用的协议与上游协议不同时， 这里能看到转换过程
- 错误信息——上游返回的原始错误， 比网关自己的报错更能说明问题
日志的保留天数可以配置，见 运行时设置。
路由检查§
这是排障最快的入口。输入一把访问密钥和一个模型名， 它直接告诉你：这个请求是否可以路由、有哪些候选分组、当前有多少可用凭据， 或者为什么走不通。
典型用途：
- 「为什么提示模型不存在」——检查器会告诉你 这把密钥能用的分组里，有没有开放这个模型
- 「为什么没有可用凭据」——按候选分组查看凭据总数和当前可用数
- 「加了新分组但没生效」——确认访问密钥有没有授权到它
不用发真实请求就能看到候选分组与当前可用凭据。
用量与成本§
展示请求量、成败趋势、缓存命中率、token 分类明细和成本估算， 可以按分组、模型、访问密钥等维度看分布。
token 分类需要理解一下，它直接影响成本：
- 非缓存输入——正常计费的输入 token
- 缓存读取——命中缓存的部分，通常远比非缓存便宜
- 缓存写入——建立缓存的开销，部分服务商单独计费
- 输出——模型生成的 token，通常最贵
所以缓存命中率高是好事——同样的请求量， 缓存命中率上去了，成本会明显下降。
成本由上游返回的 token 用量 × 模型价格推算而来， 用于运营分析和容量规划，不等于服务商账单，也不能作为财务对账依据。 几个已知偏差来源：上游未返回用量的请求无法计入； 没有价格数据的模型不计价；价格变更不回算历史数据。
数据完整度§
用量页有一块「质量」指标，它衡量的不是服务质量， 而是统计数据本身有多完整：
| 指标 | 含义 | 影响 |
|---|---|---|
| 用量缺失 | 上游没有返回 token 用量 | 这些请求不计入统计与成本 |
| 用量部分缺失 | 只返回了部分维度 | 成本偏低于实际 |
| 成本未定价 | 有用量，但该模型没有价格数据 | 不计入成本，用量仍然统计 |
| 部分定价 | 只有部分 token 类型有价格 | 成本偏低 |
这些数字大的时候，说明成本估算的可信度在下降。 「未定价」通常是模型价格没同步到，见 模型管理。
排障顺序§
遇到问题时按这个顺序走，通常两三步就能定位：
- 先看健康——凭据是不是都冷却或拉黑了？ 是的话问题在上游或密钥本身
- 再用路由检查——有没有候选分组和可用凭据？ 走不通的话它会直接告诉你原因
- 最后翻请求日志——找到那条失败的， 看上游返回的原始错误
怀疑是某一把凭据本身失效时，还有一个更直接的办法： 去分组的凭据页对它测试连接， 用一次真实请求当场确认，见 分组与渠道。
如果健康正常、路由检查也显示存在候选分组和可用凭据，但请求还是失败， 那多半是上游侧的问题（额度、模型下线、区域限制）， 日志里的原始错误信息会说明。