判断 API 请求是否异常，不能只看某一时刻的总量。面向API接口的请求速率基线建立方法，应先从历史流量中区分正常波动、周期变化和突发事件，再为不同接口设定可解释的参考范围。基线用于观察和决策，不等于直接把某个历史峰值设成限流阈值。
先确定统计对象和时间尺度
先明确要回答的问题：是保护单个接口，还是评估整个服务的请求压力？建议按接口路径和 HTTP 方法分组；若调用方身份、区域或请求类型会显著影响流量，也应分别统计。避免只看全站汇总，否则高流量接口可能掩盖低流量接口的异常。
将请求记录汇总成固定时间窗内的请求数，再换算为每秒请求数（RPS）。常见起点是 1 分钟窗口，用于容量观察；对突发变化敏感的限流场景，可额外计算 1 秒或 5 秒窗口。窗口越短，越能发现尖峰，但随机抖动也越明显。所有数据应使用同一时区和统计口径，并区分成功请求、客户端错误、服务端错误及重试请求。
清洗历史流量，避免把异常写进基线
可先取连续 4 至 8 周的记录作为初始样本；这只是常用的分析起点，业务周期更长时应覆盖完整周期。为每个接口标记维护时段、发布变更、压测、批量任务和已确认的故障。已知异常时段不宜直接参与正常基线计算，但应保留单独记录，以便制定故障应对策略。
- 核对数据完整性：检查日志是否缺时段、重复计数，网关与应用侧的统计口径是否一致。
- 按周期拆分：分别比较工作日与周末、白天与夜间；存在周月周期时，应按对应周期对齐，而不是简单混合平均。
- 计算分位数：对每个时间窗统计中位数、P95 和 P99。中位数反映典型水平，P95 描述较繁忙时段，P99 用于观察更少见的高负载；它们都是描述统计，不能单独证明服务能承受相同请求量。
- 人工复核尖峰：回看高分位时段是否对应真实用户增长、计划任务或重试放大，再决定保留、单独分组或剔除。
从统计结果转成可执行阈值
按用途分别设定参考线
监控基线与限流上限应分开。监控可将同一时段的 P95 作为常态参考、P99 作为高负载观察线；连续越线时再结合错误率、延迟和资源使用判断。限流阈值则还需通过容量测试或逐步放量验证，并预留余量。若尚未验证承载能力，不应把历史最高 RPS 当作安全上限。
例如，一个接口在过去多周的工作日午间流量明显高于夜间，就应使用对应时段的历史分布作比较，而不是用全天平均值。若接口流量不足以稳定计算分位数，可扩大观察窗口，或合并行为相近的接口；不要用少量请求得出看似精确的阈值。
上线后持续校准
- 将基线、统计窗口、样本区间和排除规则一并记录，确保团队能复算。
- 以告警方式先运行一段时间，观察误报、漏报及真实峰值，再调整阈值。
- 在版本发布、流量结构变化或业务周期切换后重新评估；平稳场景可按月复核，变化较快时应缩短周期。
面向API接口的请求速率基线建立方法，核心是让比较对象一致、异常样本有据可查，并把统计参考线与容量上限分开。这样得到的基线才适合用于告警、容量规划和后续限流评估。
常见问题
历史数据不足一个月怎么办？
先用已有数据建立临时参考线，标注样本不足，并避免把它直接作为严格限流依据；随着数据积累再复核。
应使用平均值还是 P95？
平均值容易受尖峰影响，适合概览；P95更适合描述较繁忙时段。实际监控可同时观察中位数、P95和错误率。
不同接口能共用一个基线吗？
只有请求特征和资源成本相近时才适合合并。查询、写入或批量操作差异明显时，应分别统计和验证。