# 请求分析与日志排查

结合请求分析与明细日志定位异常，理解错误率、响应耗时和 QPS 趋势的使用边界。

## 核心步骤

- 选择目标 AppKey 和异常发生的时间范围。
- 先查看请求量、错误率、响应耗时及趋势。
- 用相同条件查询日志，定位请求时间与请求 ID。
- 结合脱敏响应判断原因，记录处理后的验证结果。

## 适用场景与准备

适合排查请求失败、响应变慢或流量突然增长。准备目标接口、AppKey 对应产品及异常发生时间，登录 [开发者中心](https://www.gugudata.com/portal/)。排查记录中注明时间与时区，避免把不同时段的数据混在一起比较。

## 先看请求分析

打开 [请求分析](https://www.gugudata.com/portal/analytics)，默认查询范围为最近 24 小时。按需要调整开始时间、结束时间和 AppKey，点击“查询分析”，确认查询成功后再阅读数据。

| 指标 | 如何使用 |
| --- | --- |
| 总请求数 | 确认所选条件下的流量规模，与应用侧记录对照 |
| 错误率 | 观察失败是否集中出现，再到日志中核对具体响应 |
| 平均响应耗时 | 了解整体响应速度，但不要用它代表最慢请求 |
| P95 | 观察大部分请求的耗时上界；少量更慢的请求仍需单独排查 |
| QPS 趋势 | 找到流量增长时段，进一步检查是否存在短时突发 |

趋势图经过时间分组，不能将某个点当作每一秒的完整峰值。错误率也不能替代对接口业务状态的检查：HTTP 成功并不保证业务结果符合预期。

## 再查询请求日志

1. 打开 [请求日志](https://www.gugudata.com/portal/logs)，使用与分析页面相同的时间范围和 AppKey。
2. 点击“查询日志”，按请求时间查找异常，必要时缩小时间范围并翻页。
3. 核对请求路径、响应码、耗时和请求 ID，确认是否与应用侧的失败记录对应。
4. 将请求 ID、发生时间与脱敏响应整理到排查记录，再按 [错误与重试](https://www.gugudata.com/developers/errors-and-retries) 决定下一步。

请求日志中的路径与状态用于定位，不应替代接口详情页的字段说明。向他人提供记录前，移除 AppKey、完整 Cookie、敏感参数和个人信息。

## 将现象与原因对应起来

| 现象 | 优先检查 |
| --- | --- |
| QPS 上升后频率受限 | 定时任务是否扎堆，多服务是否共用同一调用预算 |
| 请求量平稳但 P95 上升 | 单次处理耗时、网络、应用排队与超时设置 |
| HTTP 成功但应用报错 | JSON 解析、业务状态及所需字段是否存在 |
| 只有某个产品异常 | 该产品权限、请求参数及接口状态 |

需要调整请求节奏或扩展容量时，继续阅读 [QPS 与升级](https://www.gugudata.com/developers/qps-and-upgrades)。

## 没有数据不一定是没有请求

先区分“尚未查询”“查询失败”和查询成功后的空结果。再核对账号、AppKey、时间范围及请求是否发往预期接口。日志与统计可能存在处理延迟，不承诺每次调用都立即出现在页面中，也不要用请求统计直接推算计费次数。

如果查询持续失败或记录与应用明显不符，保留筛选条件和错误提示，通过 [官方支持](https://www.gugudata.com/contact) 反馈。完成修复后使用相同条件复查，并结合应用侧结果确认恢复，不能只凭一张趋势图判断问题已经解决。