核心步骤
- 选择目标 AppKey 和异常发生的时间范围。
- 先查看请求量、错误率、响应耗时及趋势。
- 用相同条件查询日志，定位请求时间与请求 ID。
- 结合脱敏响应判断原因，记录处理后的验证结果。
本文目录
适用场景与准备
适合排查请求失败、响应变慢或流量突然增长。准备目标接口、AppKey 对应产品及异常发生时间，登录 开发者中心。排查记录中注明时间与时区，避免把不同时段的数据混在一起比较。
先看请求分析
打开 请求分析，默认查询范围为最近 24 小时。按需要调整开始时间、结束时间和 AppKey，点击“查询分析”，确认查询成功后再阅读数据。
| 指标 |
如何使用 |
| 总请求数 |
确认所选条件下的流量规模，与应用侧记录对照 |
| 错误率 |
观察失败是否集中出现，再到日志中核对具体响应 |
| 平均响应耗时 |
了解整体响应速度，但不要用它代表最慢请求 |
| P95 |
观察大部分请求的耗时上界；少量更慢的请求仍需单独排查 |
| QPS 趋势 |
找到流量增长时段，进一步检查是否存在短时突发 |
趋势图经过时间分组，不能将某个点当作每一秒的完整峰值。错误率也不能替代对接口业务状态的检查：HTTP 成功并不保证业务结果符合预期。
再查询请求日志
- 打开 请求日志，使用与分析页面相同的时间范围和 AppKey。
- 点击“查询日志”，按请求时间查找异常，必要时缩小时间范围并翻页。
- 核对请求路径、响应码、耗时和请求 ID，确认是否与应用侧的失败记录对应。
- 将请求 ID、发生时间与脱敏响应整理到排查记录，再按 错误与重试 决定下一步。
请求日志中的路径与状态用于定位，不应替代接口详情页的字段说明。向他人提供记录前，移除 AppKey、完整 Cookie、敏感参数和个人信息。
将现象与原因对应起来
| 现象 |
优先检查 |
| QPS 上升后频率受限 |
定时任务是否扎堆，多服务是否共用同一调用预算 |
| 请求量平稳但 P95 上升 |
单次处理耗时、网络、应用排队与超时设置 |
| HTTP 成功但应用报错 |
JSON 解析、业务状态及所需字段是否存在 |
| 只有某个产品异常 |
该产品权限、请求参数及接口状态 |
需要调整请求节奏或扩展容量时，继续阅读 QPS 与升级。
没有数据不一定是没有请求
先区分“尚未查询”“查询失败”和查询成功后的空结果。再核对账号、AppKey、时间范围及请求是否发往预期接口。日志与统计可能存在处理延迟，不承诺每次调用都立即出现在页面中，也不要用请求统计直接推算计费次数。
如果查询持续失败或记录与应用明显不符，保留筛选条件和错误提示，通过 官方支持 反馈。完成修复后使用相同条件复查，并结合应用侧结果确认恢复，不能只凭一张趋势图判断问题已经解决。