API 请求结果桑基图：从端点到错误
跟踪 API 请求：从端点到状态类别，再到每种错误的原因。看哪些端点出错、为什么，再换成你自己的日志计数。
API 结果桑基图跟踪请求：从接收它的端点，到成功或某个错误类别，再按原因拆分每类错误。它能指出最值得先修的端点和原因。
示例有 100 万次请求，分布在四个端点。其中 92 万次成功，6 万次是客户端错误（4xx），2 万次是服务器错误（5xx）。最后一列给出每种错误的原因：客户端一侧是输入无效、令牌过期、未找到和限流；服务器一侧是超时、依赖故障和缺陷。
每个端点的错误率只是一个数字，桑基图则保留了路径：示例中结账的服务器错误率最高（150 中的 7），登录的客户端错误率最高（200 中的 22）。数字是虚构的。请使用某个时间窗口内的计数，并说明重试按一次算还是每次都算。针对告警而不是请求的同类思路，请看 /zh/sankey/incident-response。
如何阅读此图表
- 1,000 千次请求中有 920 千次（92%）成功；6% 是客户端错误，2% 是服务器错误。
- 结账的服务器错误率最高：150 中的 7（约 5%）。
- 登录的客户端错误率最高：200 次请求中的 22（11%）。60 个客户端错误中有 20 个由令牌过期造成。
- 服务器错误的一半（20 个中的 10 个）是超时。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为千次请求，仅一个时间窗口。
| 来源 | 目标 | 数量（千次请求） |
|---|---|---|
| 搜索 | 成功（2xx） | 370 |
| 搜索 | 客户端错误（4xx） | 22 |
| 搜索 | 服务器错误（5xx） | 8 |
| 结账 | 成功（2xx） | 135 |
| 结账 | 客户端错误（4xx） | 8 |
| 结账 | 服务器错误（5xx） | 7 |
| 登录 | 成功（2xx） | 175 |
| 登录 | 客户端错误（4xx） | 22 |
| 登录 | 服务器错误（5xx） | 3 |
| 商品目录 | 成功（2xx） | 240 |
| 商品目录 | 客户端错误（4xx） | 8 |
| 商品目录 | 服务器错误（5xx） | 2 |
| 客户端错误（4xx） | 输入无效 | 25 |
| 客户端错误（4xx） | 令牌过期 | 20 |
| 客户端错误（4xx） | 未找到 | 10 |
| 客户端错误（4xx） | 被限流 | 5 |
| 服务器错误（5xx） | 超时 | 10 |
| 服务器错误（5xx） | 依赖故障 | 6 |
| 服务器错误（5xx） | 缺陷 | 4 |
同样的数据（CSV）
source,target,value
搜索,成功（2xx）,370
搜索,客户端错误（4xx）,22
搜索,服务器错误（5xx）,8
结账,成功（2xx）,135
结账,客户端错误（4xx）,8
结账,服务器错误（5xx）,7
登录,成功（2xx）,175
登录,客户端错误（4xx）,22
登录,服务器错误（5xx）,3
商品目录,成功（2xx）,240
商品目录,客户端错误（4xx）,8
商品目录,服务器错误（5xx）,2
客户端错误（4xx）,输入无效,25
客户端错误（4xx）,令牌过期,20
客户端错误（4xx）,未找到,10
客户端错误（4xx）,被限流,5
服务器错误（5xx）,超时,10
服务器错误（5xx）,依赖故障,6
服务器错误（5xx）,缺陷,4运作方式
导出一个时间窗口的请求日志
取一小时、一天或一周，每条请求带上端点和状态码。
对端点和状态码分组
保留最繁忙的四到六个端点，其余归为“其他”。把状态码按类别分组。
补上每个错误的原因
使用服务返回的错误码或消息，把原因归为五到七个标签。
检查平衡
每个错误类别流出的请求数必须等于流入的。成功在第二列结束。
常见问题
要显示重定向（3xx）吗？
只有它与你的问题有关时才显示。否则把它们算作成功，或者省略并在数据说明里写明。
可以用来做实时监控吗？
不可以。它是一个固定时间窗口的图。实时速率最好用监控工具；这张图用来解释故障从哪里来。
编辑这张 API 桑基图
把示例作为你自己的图表打开，填入你的请求计数。