同一条流量告警规则，不适合所有规模的业务。小型站点可能只需关注出口带宽和请求量；多应用、多地域的业务则需要按服务拆分视图。做好攻击流量监控与告警阈值设置，关键不是把阈值设得越低越好，而是让告警能区分正常波动与需要处置的异常。
先按业务规模选监控方式
| 业务规模 | 可选监控方式 | 优势与限制 |
|---|---|---|
| 单一服务、流量较稳定 | 云平台自带监控，如 AWS CloudWatch、Azure Monitor 或 Google Cloud Monitoring | 接入快、维护负担低；跨平台或复杂关联分析能力有限。 |
| 多个服务，需统一查看 | 集中采集云监控指标与防火墙、负载设备的流量日志 | 便于按服务、地域对照；需要统一时间、名称和标签，否则排查易混乱。 |
| 多地域或流量波动显著 | 集中监控平台叠加流量基线与异常检测 | 能识别偏离自身常态的变化；初期需积累数据、持续校准，不能完全依赖自动判断。 |
规模不只看员工或服务器数量，还要看服务数量、流量波动和轮值处置能力。团队较小时，优先选择少量关键指标、能明确通知负责人的方案；服务多时，再增加分组和关联分析。
阈值设置的5项选择
1. 选能代表风险的指标
至少区分带宽利用率、单位时间请求量，以及单个服务承受的流量。带宽利用率反映链路是否接近容量上限，请求量便于观察某项服务是否突增；两者应结合业务容量判断。不要把所有来源的总流量当成唯一指标，否则正常的大型文件分发也可能触发告警。
2. 在固定阈值和流量基线之间取舍
固定阈值直观，适合容量已知、波动较小的业务，例如将持续达到可用带宽的约70%—85%设为预警观察区间；具体比例要结合链路余量、业务峰值和运营商限制调整，不能直接套用。流量基线适合明显存在日夜或工作日差异的业务，可比较当前值与相同时段历史水平。新业务数据不足时，先用固定阈值，积累数周稳定数据后再评估基线。
3. 给突增留出确认时间
单个采样点越线不一定代表攻击。可先用1分钟左右的短窗口发现快速变化，再要求连续2—5个采样窗口越线后发出一般告警；对于接近容量上限、可能影响服务的情况，可缩短确认时间并设置更高优先级。监控采样频率、业务峰值和处置速度都会影响这个范围。
4. 分级而不是只设一个门槛
可设置“观察、紧急”两级：观察级用于流量明显偏离流量基线、但服务尚可用的情况；紧急级对应接近资源上限或用户请求失败同步增加。前者通知值班人员复核，后者按照既定应急流程处理。阈值要对应清晰动作，避免同一条通知既不说明风险，也没有负责人。
5. 按服务拆分并定期校准
不同服务容量不同，不能用全站平均值掩盖局部异常。为关键业务单独设规则，低风险服务则可以采用较宽松阈值。每次明显的业务发布、促销活动或容量调整后，都应复核规则；查看误报与漏报记录，分别调整阈值、持续时间或通知级别。
落地时按这四步操作
列出关键服务、可用带宽、正常高峰时段和负责处理告警的人员。
选取带宽利用率、请求量等少数核心指标，确定采样周期及数据来源。
先设观察级和紧急级阈值，注明触发时长、接收人及建议核查动作。
在业务高峰和低峰分别观察告警结果，记录误报，再按实际容量逐步修订。
攻击流量监控与告警阈值设置应随业务规模变化：小规模先求简单可靠，多服务业务重视分类与关联，波动复杂时再引入基线检测。阈值最终要能回答三个问题：哪里异常、是否影响服务、谁来处理。
常见问题
流量刚超过阈值就要告警吗？
不一定。可设置持续时间或连续采样条件；若已接近容量上限，则应缩短确认时间。
没有历史数据，怎么设置流量基线？
先依据已知容量和业务预期设置固定阈值，同时收集不同时间段的数据，待规律稳定后再建立基线。
多久复核一次告警规则？
没有适用于所有业务的固定周期。业务变更、容量调整或误报增多时应及时复核；稳定运行期间也可纳入常规运维检查。
小团队需要单独部署监控平台吗？
未必。若云平台内置指标和通知已满足需求，可先用现有功能；服务数量增加或需要跨来源分析时，再评估集中监控。