值班记录：十分钟接上人工智能调用延迟与错误率监控

交班目标：先看见慢请求和失败请求

本班先完成一件事：给人工智能调用接上最小监控，让下一次“回答变慢了”有数据可查。十分钟内不追求完整观测平台，只建立请求记录、延迟分布、错误率和一条经过验证的告警。已有监控系统就直接复用，没有则先输出结构化日志。

前两分钟：把计时放在统一调用入口

在应用访问模型的公共封装层埋点，不要分散到每个业务页面。请求开始时使用单调时钟计时，在正常结束、异常和取消路径统一记录结果，避免只统计成功请求。

• 每次调用记录时间、应用名、环境、请求标识、模型、是否流式、耗时、状态码、错误类型和重试次数。
• 请求标识留在日志中用于追踪，不作为指标标签；用户标识和完整提示词也不要作为标签，避免高基数和敏感信息泄露。
• 模型可以先选 Gemini 2.5 Flash 或 DeepSeek V4 Pro，但请求中应使用控制台实际提供的模型标识，不要直接猜测展示名称对应的接口参数。

第二到四分钟：给流式响应补上两个终点

普通请求记录从发起到响应读取完毕的耗时。流式请求则至少记录两个指标：从发起到第一个有效内容片段的时间，以及从发起到整个响应结束的总耗时。收到响应头或保活事件，不代表用户已经看到回答。

如果工具调用也是业务结果，应单独约定首个有效工具调用片段的判定规则。流在中途断开时，仍需记录失败；不能因为最初返回了成功状态码，就把整次调用算作成功。

同时保留单次网络尝试和整个业务调用的耗时。后者包含重试与等待，才接近用户实际体验。两种口径分开命名，避免一次业务请求因三次尝试被误认为三个用户请求。

第四到六分钟：让错误率有明确分母

先用最近五分钟内结束的业务调用计算失败率：最终失败次数除以结束次数。再单独统计各次尝试的失败率，用来发现被重试掩盖的问题。尚未结束的请求不进入这个分母，但应观察进行中数量和超时情况。

• 错误至少区分鉴权失败、限流、上游服务错误、连接异常、超时和流中断，便于决定下一步查哪里。
• 用户主动取消应单列；应用截止时间触发的取消通常需要纳入超时，不要把两者混在一起。
• 接口返回成功但业务校验不通过的结果，例如结构化输出无法解析，应另记为业务失败，不能仅凭状态码判断可用性。

第六到八分钟：摆出值班真正会看的四块数据

第一块看调用量和进行中请求，确认当前有没有流量积压。第二块看业务失败率与错误类型。第三块看总耗时的中位数和第九十五百分位。第四块看流式首片段耗时，并按模型和应用筛选。

低流量时同时展示样本数，不要根据少量请求的百分位立即下结论。计算跨实例延迟分位数时，应使用可聚合的延迟分布数据，不要直接平均各实例的第九十五百分位。成功与失败的耗时也应能拆开查看，防止快速失败把总体延迟“拉好看”。

第八到十分钟：验证告警，而不是只保存规则

告警阈值先参考业务可接受等待时间和现有基线，设置持续窗口与最低请求量，避免一次抖动就叫醒值班人员。错误率告警附带主要错误类型，延迟告警附带受影响模型、样本数和日志查询入口。

在测试环境主动制造一次可识别的失败，例如使用无效测试凭证，并确认指标增加、告警送达、请求日志可以定位。再恢复配置。超时、重试和流中断可随后补测，不必为了十分钟目标在生产环境制造故障。

交班备注：统一接入方便埋点，不替代应用侧监控

如果需要按量使用多个模型，Relay365 适合作为统一接入入口，并可配合 Claude Code、Codex、Gemini CLI 和 OpenAI SDK 使用。接口基础地址为 https://api.api365relay.com，OpenAI 客户端配置时追加 /v1。统一入口便于复用调用封装，但应用仍需记录完整业务耗时，不能只依赖中转侧记录。

准备验证这套流程时，可以创建一个 Relay365 账户，先用少量测试请求跑通监控。交班前留下计时口径、错误分类、告警接收人和查询位置；下一班接手后，应能从一条告警找到具体失败请求。