TG咨询一条可用的流量攻击告警规则，重点不在于把阈值设得尽可能低，而在于让告警与真实风险相匹配。以在线考试、直播预约、电子商务结算等系统为例，活动开始前后访问变化本来就可能很大。如果只按总带宽或请求数量报警，容易把正常高峰当成攻击，也可能漏掉针对登录、搜索或支付接口的低速消耗。配置流量攻击告警规则时，可重点检查以下5个操作要点。
一、先建立可解释的业务基线
阈值应来自业务自身的正常状态，而不是直接套用某个固定数值。建议先按工作日、周末、活动日和夜间分别观察至少一到两周，记录入口流量、连接数、CPU使用率、内存、队列长度以及核心接口的成功率。对于访问波动较大的系统，可以使用同一时间段的历史中位数，并设置上下浮动范围。
例如，在线报名系统在开放报名后的前十分钟可能出现集中访问，此时可以单独建立“报名开放”时段的基线。基线还应区分静态资源、接口请求和长连接，避免把图片下载或正常推送连接与动态接口混在一起。这样设置出来的流量攻击告警规则更容易解释，也便于值班人员判断是否需要介入。
二、不要只用单一指标触发
单看带宽无法识别所有攻击。大流量攻击可能迅速占满链路，而应用层攻击的总流量并不突出，却会持续消耗线程、连接池或数据库资源。因此，规则最好采用“主指标加辅助条件”的组合方式。
- 先选择一个主指标，例如入口字节速率、并发连接数或单位时间内的请求数。
- 再加入至少一个影响指标，例如5xx比例、接口平均响应时间、连接建立失败率或主机负载。
- 明确组合关系：主指标超过警戒线且影响指标连续异常时升级；只有单项变化时先进入观察状态。
这种设计比“任一指标超过阈值就报警”更能降低误报。对于UDP业务、WebSocket服务和普通HTTP接口，还应分别设定规则，因为它们的连接特征和资源消耗方式并不相同。
三、把阈值、持续时间和等级分开设置
阈值解决“异常达到什么程度”，持续时间解决“异常是否稳定存在”，等级则决定“谁来处理”。三者不要写成一个不可调整的条件。
建议采用三级告警
- 观察级：指标超过正常范围约20%至50%，持续3至5分钟，仅记录事件并通知监控人员。
- 告警级：多个相关指标同时异常，或单项指标持续约10分钟，通知值班人员检查入口、应用和主机资源。
- 紧急级：出现明显服务不可用、连接大量失败或关键业务连续失败时，立即升级并执行预案。
具体比例需要结合容量测试、业务峰值和基础设施余量调整。突发但很短的流量尖峰不一定需要升级；持续异常即使幅度不大，也可能造成资源慢性耗尽。流量攻击告警规则应同时覆盖这两种情况。
四、为不同对象配置不同规则
入口网关、应用接口、主机和数据库面对的风险不同，不能使用完全相同的告警条件。网关侧适合关注连接建立速率、异常协议占比和出口带宽；应用侧更应关注线程池、队列和接口失败；主机侧则查看文件描述符、网络连接状态及系统负载。
配置时可按域名、路径、端口、协议和业务角色拆分规则。例如，图片服务允许较高吞吐，管理后台则更适合关注短时间内的登录失败和连接增长。对可信的内部监控节点、固定办公出口或经过认证的合作方，可使用白名单降低干扰，但白名单必须设置有效期和复核责任，不能永久放行。
五、让告警直接连接处置动作
没有后续动作的告警，只会增加通知噪声。每条流量攻击告警规则都应写清负责人、通知渠道、确认时限和可执行措施。处置动作可按风险逐步增加：
- 先确认监控数据、访问日志和业务反馈是否一致，排除采集异常。
- 检查异常是否集中在某个入口、协议或接口，并核对近期发布、活动和配置变更。
- 在风险可控时启用限流、连接数限制或临时访问策略，优先保护登录、下单、支付等关键链路。
- 若本地资源持续下降，再联系网络运营方或专业清洗服务，并保留事件时间线、规则命中记录和处置结果。
规则上线后至少应通过历史回放、压测或演练验证一次。每次真实事件结束后，复盘触发时间、通知延迟、误报原因和动作效果，调整阈值与例外条件。只有经过验证和复盘，流量攻击告警规则才会从监控配置变成可靠的防护流程。
常见问题
1. 阈值应该固定还是动态调整？
稳定业务可使用固定阈值；波动明显的业务宜采用分时段基线，并保留人工确认机制。动态阈值也要设置上下限，避免基线被异常流量抬高。
2. 为什么总流量正常仍然需要告警？
少量高成本请求可能持续占用应用线程、数据库连接或缓存资源，因此应结合响应时间、失败率和资源使用情况判断。
3. 告警太多时先调低灵敏度吗？
不建议直接放宽全部阈值。应先合并重复通知、增加持续时间条件，并区分观察级与紧急级，保留真正影响业务的事件。
4. 多久复核一次规则？
业务有重大版本、架构或容量变化时应立即复核；没有明显变化时，也建议每季度检查一次，并在演练后更新。
归根结底，流量攻击告警规则要同时回答“哪里异常、是否持续、影响多大、谁来处理”四个问题，才能在减少误报的同时提高发现和处置效率。
