结合业务基线优化流量攻击告警规则

同样是请求量上升，电商促销、在线报名、内容发布和恶意流量的表现并不相同。要降低误报并尽早发现风险，流量攻击告警规则应建立在真实业务基线上，而不是简单套用一个全天通用的请求数阈值。

先定义业务基线，再设置告警条件

业务基线是指定时间、指定接口或指定区域内的正常流量范围。建议至少观察7至14天，并按工作日、周末、节假日、小时段和接口类型分别统计。对于刚上线的系统，可先使用3至7天数据作临时基线，待业务运行稳定后再调整。

采集指标不应只有总请求量，还应包括每分钟请求数、独立客户端数量、状态码比例、响应时间、请求方法、URL分布、地域分布和带宽使用量。以Nginx或Apache访问日志为例，可以将静态资源、登录接口、搜索接口和下单接口分开计算，避免高频图片请求掩盖关键接口异常。

基线应允许合理波动

固定阈值适合变化很少的内部系统，却不适合新闻网站、赛事报名页或零售活动页。实际配置时，可采用历史同时间段的中位数作为中心值，再结合波动范围设置告警线。若数据量较少，通常可先以基线的约1.5至2倍作为观察线，但应根据接口容量、缓存命中率和业务活动安排修正。

把流量特征和资源压力组合起来

单独依赖请求量，容易把正常热点识别为攻击；单独依赖CPU或带宽，又可能在服务已经受损后才发现问题。更稳妥的做法是组合判断：异常流量出现时，同时检查应用响应时间、错误率、连接数、缓存命中率和源站资源使用情况。

例如，一个搜索接口的请求量只比平时高出约30%，但查询耗时和数据库连接等待同时明显增加，也应进入观察状态。反过来，静态文件访问量翻倍，缓存命中率稳定、源站压力没有变化，则不宜直接判定为攻击。

将流量攻击告警规则设计成分级动作

告警的价值不只是发消息，还要让值班人员知道下一步做什么。建议将规则拆为提示、重要和紧急三个层级，并为每一级绑定可执行动作。

1. 提示级：某个接口或区域的流量偏离业务基线，持续约5至10分钟，但服务指标正常。记录事件并观察来源、路径和缓存情况，不立即限流。
2. 重要级：异常流量持续，且错误率、响应时间或连接使用率同步恶化。通知值班人员，检查WAF、CDN、负载均衡和源站日志，必要时对高风险路径启用更严格的频控。
3. 紧急级：出现大面积超时、明显丢包、服务不可用，或源站资源接近承载上限。按照应急预案执行限速、挑战验证、临时封禁异常来源，并评估是否切换清洗或备用容量。

分级时应设置持续时间和恢复条件。例如，短暂超过阈值只产生一次告警；连续多个检测周期仍异常才升级；指标恢复到基线附近并保持一段时间后，才自动关闭事件。这样可以减少重复通知，也便于后续复盘。

降低误报的四项配置方法

按接口风险设置不同权重

登录、支付、搜索和文件上传通常比静态资源更消耗后端资源。可以为高风险接口设置更低的触发门槛，为图片、脚本等缓存资源设置独立规则。

排除已知业务波动

将已审批的营销活动、批量导入、版本发布和定时任务登记到变更日历中。活动开始前临时调整基线，活动结束后恢复原配置，避免长期放宽规则。

区分客户端类型

移动端、搜索引擎爬虫、内部服务和普通浏览器的访问模式不同。应结合认证状态、请求路径、访问频率和来源网络判断，不能仅凭单一IP作结论。

保留规则版本与命中记录

每次修改都记录阈值、适用接口、调整原因和生效时间。每周检查告警命中率、误报事件、平均响应时间和漏报反馈；连续多次误报的规则，应优先拆分维度，而不是简单提高阈值。

上线前的验证步骤

1. 选择一个非核心接口或测试环境，回放脱敏后的历史访问数据。
2. 分别模拟正常高峰、单接口突增、来源分散和源站资源升高等场景。
3. 检查告警是否包含时间、接口、指标、基线、当前值和建议动作。
4. 确认通知渠道、值班责任人和升级路径均有效。
5. 上线后观察至少一个完整业务周期，再决定是否调整阈值。

好的流量攻击告警规则不是“越敏感越好”，而是能在正常业务波动与真实风险之间建立清晰边界，并让处置动作与业务影响相匹配。

常见问题

是否可以只按带宽设置规则？

不建议。带宽适合发现容量风险，但无法说明是哪类请求造成压力，也可能漏掉低带宽、高计算消耗的接口攻击。

没有长期历史数据怎么办？

可先按接口类型和运行时段建立临时基线，同时采用较保守的观察级告警；积累稳定数据后，再改为动态基线。

阈值越低是否越安全？

不是。过低阈值会造成大量误报，值班人员可能忽略真正事件。应结合持续时间、错误率和资源压力共同判断。

规则多久复盘一次？

常规系统可每月复盘，业务变化频繁或发生攻击事件时应在事件结束后立即复盘，并同步更新基线和处置动作。

最终，流量攻击告警规则应持续反映业务变化。以业务基线为基础，结合接口特征、资源状态和分级处置，才能在减少误报的同时提高发现和响应效率。