告警治理关键在于提升信息密度与处置确定性而非单纯降量：通过动态基线、时间窗口平滑、低风险场景过滤实现精准降噪；智能分组、依赖抑制、分级响应机制确保告警可操作、不爆炸、有优先级。
告警疲劳不是告警太多，而是多数告警不值得看。真正有效的治理，是让每条告警都自带上下文、明确责任、指向动作——不是靠压低数量，而是提升每条告警的信息密度和处置确定性。
精准降噪：别再用“CPU > 80%”刷屏
静态阈值在云原生环境里基本失效。业务有峰谷、应用有抖动、GC或网络重传会瞬间拉高指标，但并不等于故障。
- 改用动态基线：Prometheus 中用 predict_linear(node_memory_MemAvailable_bytes[6h], 24*3600) 预测未来24小时可用内存趋势，只在预测值跌破安全水位时告警
- 加时间窗口平滑：对瞬时毛刺类指标（如 CPU steal time），用 avg_over_time(node_cpu_seconds_total{mode="steal"}[5m]) 替代单点采样
- 跳过已知低风险场景：对突发型 ECS 实例，直接在 alert rule 中加 unless on(instance) node_instance_type == "burstable"
智能分组：把10条重复告警压成1条可操作通知
当 user-api 的3个 Pod 同时触发内存超限，收3条消息只会让人划走；收1条带实例列表、趋势图、一键排障链接的通知，才能推动响应。
- Alertmanager 中设置 group_by: ['alertname', 'service', 'environment']，确保同服务、同环境、同类型自动聚合
- 控制节奏：group_wait: 30s（等新告警进来）、group_interval: 5m（同组再次发送间隔），避免漏报也不刷屏
- Grafana 告警模板里嵌入关键上下文：{{ $labels.instance }} 内存使用率 {{ $value | humanizePercentage }}，近1小时上涨 {{ $annotations.delta_pct }}%
依赖抑制：拦住告警链式爆炸
网络分区一发生，所有节点失联、Exporter不可达、HTTP健康检查失败……几十条告警同时弹出，但根因只有一个。
- 在 alertmanager.yml 中配置抑制规则：NetworkPartition 触发时，自动抑制 InstanceDown、NodeExporterDown、HTTPProbeFailed 等下游告警
- 示例规则：inhibit_rules:
- source_match:
alertname: NetworkPartition
severity: critical
target_match_re:
alertname: InstanceDown|NodeExporterDown|HTTPProbeFailed - 上线前务必开启 --log.level=debug 观察匹配行为，避免误压关键告警
分级响应：P0故障秒达，P2预警静默归档
所有告警一个铃声，等于没有铃声。必须按影响范围、业务后果、恢复时效定义响应等级，并绑定通道、超时、SOP。
- P0（灾难）：全站不可用、支付中断、核心 DB 宕机 → 电话+短信+钉钉强提醒，1分钟内响应，自动触发 curl -I http://localhost:8080/health 预检
- P1（严重）：单服务降级、磁盘95%、连接池耗尽 → 钉钉+企微，15分钟内确认，告警 annotations 自动注入 last_24h_growth_gb: 2.3
- P2（提示）：日志轮转未启用、Docker 镜像积压、inode 使用率82% → 静默写入内部看板，不推通知，每日汇总邮件
