监控与排障
请求失败时，这一页帮你定位到是哪个凭据、哪一步出的问题。
四个监控入口§
Modern 管理台的监控导航分四块，各管一件事：
- 健康——现在哪些凭据可用、哪些出了问题
- 用量与成本——花了多少 token、多少钱
- 请求日志——每一条请求的详细记录
- 路由检查——给定条件，看网关会怎么选
健康§
健康页给出当前每个分组、每个凭据的可用状态， 以及需要注意的问题清单。
凭据的状态含义：
- 可用——正常参与轮转
- 冷却中——刚被上游限流或报错，暂时跳过，到点自动恢复
- 已拉黑——连续失败超过阈值，自动摘除。API Key 分组会按验证间隔自动探测并恢复；订阅凭据不走这条自动恢复路径
- 已停用——你手动关掉的，不参与轮转
冷却和拉黑的触发条件、恢复方式见 调度是怎么做的。
有问题的凭据会集中列出，不用逐个分组翻。
请求日志§
每条请求都有记录，可以按时间、分组、模型、状态等条件筛选。点开单条能看到完整链路：用了哪个凭据、 是否发生过协议转换、重试了几次、上游返回了什么。
排障时最有用的几个字段：
- 路由身份——这条请求实际走了哪个分组、哪个凭据
- 协议转换——客户端用的协议与上游协议不同时， 这里能看到转换过程
- 错误信息——经过脱敏和长度限制的错误摘要， 配合错误码、来源、范围和命中规则判断
字段和错误码见 错误与恢复参考； 日志保留天数见 运行时设置。
模型一致性比较发往上游的模型与上游响应报告的模型，观测发生在客户端别名改写之前。对话响应未报告模型时为 unknown；同一次尝试出现过不一致时，不会被后续一致值覆盖。它不改变路由、重试或计价，历史日志不会回写。
流式与非流式聊天统一按「输出 token ÷ 请求总耗时」显示平均输出速度，包含等待、重试、凭据轮换与思考耗时，不代表纯生成速度。用量或耗时不可用时不显示速度。
流式首响记录收到上游首条非空 SSE data 行或 WebSocket 消息的时间，可能只有元数据，不等于用户看到首字。首响为 0 或缺失时，界面显示不可用。
客户端 IP 可用于精确筛选；列表中的 IP 列默认隐藏，可在列设置中开启。历史日志不回填 IP，脱敏导出会匿名化地址。
Classic 与 Modern 的请求日志和用量页都可在刷新控件旁选择自动刷新：默认关闭，可选 5、10、30、60 秒。两页与两套界面共用当前浏览器的偏好，导航或重新加载后保留；它不是跨设备设置。
自动刷新保留当前筛选、分页、滚动位置、已打开详情和图表选择；相对时间范围随请求推进。后台标签页暂停，返回前台后恢复；页面忙碌时跳过本轮。失败时保留上次结果及过期提示，并退避重试，最长间隔 5 分钟。
开启访问密钥的「记录请求内容」后，可在单条日志详情中查看和复制客户端原始请求体。记录的是解码后的入站内容，早于参数覆盖、请求脱敏和协议转换；Responses WebSocket 按轮记录请求帧。不记录上游请求、上游响应或请求头。
合法 UTF-8 JSON 不超过 256 KiB 时原样保存；超限时只截断字符串值，并保留 JSON 结构。非 JSON、截断后仍超限或待写队列预算不足时，只保留状态和原始大小，不保存正文。历史记录与未开启记录的请求不会补录。
管理员和发出该请求的访问密钥会话都可读取已记录的原始体。Modern 的脱敏日志导出会排除请求体，但详情中的复制内容不会因此脱敏；分享前需人工检查。记录随请求日志保留期清理，关闭记录不清空历史。
路由检查§
这是排障最快的入口。输入一把访问密钥和一个模型名， 它直接告诉你：这个请求是否可以路由、有哪些候选分组、当前有多少可用凭据， 或者为什么走不通。
典型用途：
- 「为什么提示模型不存在」——检查器会告诉你 这把密钥能用的分组里，有没有开放这个模型
- 「为什么没有可用凭据」——按候选分组查看凭据总数和当前可用数
- 「加了新分组但没生效」——确认访问密钥有没有授权到它
不用发真实请求就能看到候选分组与当前可用凭据。
用量与成本§
展示请求量、成败趋势、缓存命中率、token 分类明细和成本估算， 可以按分组、模型、访问密钥等维度看分布。
token 分类需要理解一下，它直接影响成本：
- 非缓存输入——正常计费的输入 token
- 缓存读取——命中缓存的部分，通常远比非缓存便宜
- 缓存写入——建立缓存的开销，部分服务商单独计费
- 输出——模型生成的 token，通常最贵
所以缓存命中率高是好事——同样的请求量， 缓存命中率上去了，成本会明显下降。
成本由上游 token 用量、模型价格及分组与访问密钥价格倍率推算而来， 用于运营分析和容量规划，不等于服务商账单，也不能作为财务对账依据。 几个已知偏差来源：上游未返回用量的请求无法计入； 没有价格数据的模型不计价；价格变更不回算历史数据。
数据完整度§
用量页有一块「质量」指标，它衡量的不是服务质量， 而是统计数据本身有多完整：
| 指标 | 含义 | 影响 |
|---|---|---|
| 用量缺失 | 上游没有返回 token 用量 | 这些请求不计入统计与成本 |
| 用量部分缺失 | 只返回了部分维度 | 成本偏低于实际 |
| 成本未定价 | 有用量，但该模型没有价格数据 | 不计入成本，用量仍然统计 |
| 部分定价 | 只有部分 token 类型有价格 | 成本偏低 |
这些数字大的时候，说明成本估算的可信度在下降。 「未定价」通常是模型价格没同步到，见 模型管理。
排障顺序§
遇到问题时按这个顺序走，通常两三步就能定位：
- 先看健康——凭据是不是都冷却或拉黑了？ 是的话问题在上游或密钥本身
- 再用路由检查——有没有候选分组和可用凭据？ 走不通的话它会直接告诉你原因
- 最后翻请求日志——找到那条失败的， 看错误码和已脱敏的错误摘要
怀疑是某一把凭据本身失效时，还有一个更直接的办法： 去分组的凭据页对它测试连接， 用一次真实请求当场确认，见 分组与渠道。
如果健康正常、路由检查也显示存在候选分组和可用凭据，但请求还是失败， 那多半是上游侧的问题（额度、模型下线、区域限制）， 日志里的错误码和安全摘要会提供进一步线索。