告警噪声从哪里来
存储的告警天然是层级放大的：一块后端盘异常会同时触发盘、柜、池、控制器、路径、主机多条告警，一台主机上的每个 LUN 又各自报一条。再加上阈值贴边导致的反复告警，值班人员很快就学会忽略告警。噪声治理的目标不是减少告警条数，而是让每条留在通道里的告警都指向一个需要人处理的独立故障。
基本信息
| 噪声类型 | 级联放大、同源重复、阈值抖动、维护期误报 |
|---|---|
| 治理手段 | 去重、抑制、聚合、迟滞、静默窗口、分级路由 |
| 衡量指标 | 每班有效告警数、误报率、首次响应时长 |
| 落地载体 | 监控平台的告警规则与响应手册，而非存储设备本身 |
典型使用场景
- 大规模盘位设备：单盘告警量极大，必须先在存储侧聚合
- 多路径主机：链路抖动会同时报出大量路径与 LUN 告警
- 固件升级与割接窗口：需要临时静默以免淹没真实故障
- 值班交接：用分级路由决定哪些告警电话通知、哪些进工单
- 新设备上线：先用观察期收集基线，再收紧阈值
噪声类型与处理
| 噪声 | 表现 | 处理方式 |
|---|---|---|
| 级联放大 | 一个后端故障引出成百条告警 | 按父因抑制子告警，只保留根因条目 |
| 同源重复 | 同一故障从多通道重复上报 | 按设备与故障码去重，合并为一条 |
| 阈值抖动 | 指标在阈值上下反复穿越 | 加迟滞与持续时间条件，连续多次才告警 |
| 维护期误报 | 变更期间大量预期告警 | 开维护窗口静默，结束后补一次状态核对 |
值班侧的分类处理顺序
值班侧的分类处理顺序
# 1 先判断是否存在父因告警（控制器、链路、供电、池状态）
# 2 再看影响面：受影响的卷、主机与业务数量
# 3 然后核实是否为已知变更引发（比对变更窗口）
# 4 最后才处理单点告警，例如单盘、单风扇、单电源
# 5 处理完回写结论，供告警规则迭代参考阈值调优要有依据：先统计一段时间的指标分布，再按分位数设阈值，同时给足持续时间条件。把阈值调高只是把问题推后，通常还需要配合容量与性能趋势告警。