请求日志

请求日志用于回答“谁在什么时间调用了哪个接口，结果怎样”。它与保存 Token 和点数的用量账本分开。

记录的内容

类别	字段
请求	时间、方法、路径、请求 ID
结果	HTTP 状态码、耗时、响应字节数
来源	账号、网页或 API 渠道、IP、User-Agent
模型	已关联的模型 ID 与展示名称
错误	可获得的错误码

请求日志不保存完整请求正文、上游响应正文或全部 HTTP Headers。不要期望在这个页面直接查看原始提示词或上游完整 JSON。

Token、点数等消费信息到用量页面查看。进程日志可提供网络、数据库与探测相关的补充信息。

定位失败请求

先按发生时间与模型过滤，再根据状态或错误码缩小范围。也可以从模型页面的错误入口跳转到请求日志。

• 401：核对调用方认证；如果错误来自上游，再检查服务商凭据。
• 429：区分本实例的额度或并发限制与上游限流。
• 5xx：结合进程日志检查连接、超时或上游响应问题。

HTTP 流式响应开始后，状态码可能已经发出。不能只凭 200 判断整次生成一定成功，应结合错误码和用量记录中的结果。

写入时间与保留

请求结束后才进入日志队列，正在生成的长请求不会马上出现在列表里。后台批量写入，可能有短暂延迟。

当前实现最多保留约 200,000 条请求记录，并分批修剪更早的数据。队列拥塞或写入失败时可能丢失条目，后台提供丢弃数量供排查。

health.retain_days 控制模型探测数据，不是请求日志的保留天数。请求日志也不是不可删除、保证无遗漏的审计存储。

需要长期保留时

将进程日志与数据库备份纳入自己的保留计划。发生问题后及时保存有关时间范围的信息，避免历史记录被正常修剪。