监控告警的阈值设计
无线告警设计的难点不在能不能报警，而在报了之后有没有人真正去处理。阈值定得过敏感，值班人员很快产生告警疲劳，真问题被淹没在噪声里；定得过迟钝，等用户投诉时已经错过了最佳处置窗口。可行的方法是分三档设计：可用性问题立即告警，容量问题加时间窗抑制抖动，质量问题按趋势判断。
基本信息
| 可用性类 | AP 离线、控制器失联，影响明确，立即告警 |
|---|---|
| 容量类 | 空口利用率、客户端数，需持续一段时间再报 |
| 质量类 | 重传率、噪声底抬升，按趋势而非瞬时值判断 |
| 抑制策略 | 连续多个采集周期超标才触发，避免抖动误报 |
| 设计原则 | 每条告警都必须对应一个明确的处置动作 |
典型使用场景
- 7x24 值守：把可自动判定的问题推给值班人员
- 夜间无人值守：AP 离线告警触发短信或电话通知
- 容量预警：在利用率触及水位前给出提前量
- 质量劣化：噪声抬升或重传上升时提前介入
- 告警治理：清理长期无人处理的历史规则
- 变更期间：临时收紧阈值以捕捉异常
阈值示例
阈值示例
# AP 离线超过一分钟 -> 紧急，短信通知
# 2.4G 空口利用率超过七成持续十五分钟 -> 提醒工单
# 认证失败率超过百分之五持续五分钟 -> 提醒排查
# 每条规则标注：触发条件、通知对象、处置动作三档告警设计
| 档位 | 对象 | 触发方式 |
|---|---|---|
| 可用性 | AP 与控制器在线状态 | 即时触发，不设抑制 |
| 容量 | 利用率、客户端数、地址池 | 持续超标后触发 |
| 质量 | 重传率、噪声底、认证失败 | 按趋势或连续周期判断 |
| 安全 | 仿冒热点、异常接入行为 | 按事件类型分级 |
告警治理的一个实用标准是：每条规则都能写清楚「触发后谁做什么」。写不出来的规则应当合并或关闭，否则只是把噪声转发给值班人员。