Prometheus 告警规则一团糟？我用一个脚本把 200 条规则按严重性自动分级

Prometheus 告警规则一团糟我用一个脚本把 200 条规则按严重性自动分级接手一个新项目打开 Prometheus 的告警规则文件我当场就懵了。200 多条告警规则挤在一个文件里有的叫HighCPU有的叫CpuUsageTooHigh还有的叫HostCpuAlert。严重性呢清一色的severity: warning。最离谱的是同一个指标被重复定义了 4 次只是阈值不一样。那天排查一个问题我花了 20 分钟才找到真正触发告警的规则。说实话这种混乱的告警体系比没有监控还糟糕——狼来了太多次运维和开发都麻木了。问题的根源Prometheus 本身不提供规则管理的最佳实践全看团队自觉。随着时间推移必然会出现这些问题命名混乱同一件事有多种叫法搜索困难严重性失效所有告警都是warning导致真正的critical被淹没规则膨胀没有人清理过期规则文件越来越大缺乏上下文收到告警不知道该找谁、该看什么我当时的想法很简单与其一条一条人工整理不如写个脚本先把规则按严重性自动分级再逐步治理。脚本的核心逻辑这个脚本我给它起名叫prometheus-rule-linter做了三件事1. 解析所有规则文件importyamlimportrefrompathlibimportPathdefparse_rule_files(rules_dir):遍历目录解析所有 .yml 规则文件rules[]forfileinPath(rules_dir).glob(*.yml):withopen(file)asf:datayaml.safe_load(f)forgroupindata.get(groups,[]):forruleingroup.get(rules,[]):rules.append({file:file.name,group:group[name],alert:rule.get(alert,),expr:rule.get(expr,),severity:rule.get(labels,{}).get(severity,unknown),summary:rule.get(annotations,{}).get(summary,)})returnrules2. 按严重性自动分级我定义了一套分级规则根据告警指标和表达式自动推断严重性definfer_severity(rule):根据规则内容推断严重性exprrule[expr].lower()alert_namerule[alert].lower()# Critical: 服务不可用、数据丢失、磁盘满critical_patterns[up.*.*0,# 服务宕机disk.*.*0.9,# 磁盘使用率超过90%increase.*error,# 错误数增长pod.*pending.*.*10,# 大量 Pod 无法调度]# Warning: 性能下降、资源紧张warning_patterns[cpu.*.*70,memory.*.*80,latency.*.*100,]forpatternincritical_patterns:ifre.search(pattern,expr):returncriticalforpatterninwarning_patterns:ifre.search(pattern,expr):returnwarningreturninfo3. 生成治理报告脚本最后输出一份详细的报告包括按严重性分布的统计命名不规范的规则列表疑似重复的规则相似度 80%缺少summary或description的规则 Prometheus 规则治理报告 总规则数: 203 Critical: 23 (11.3%) Warning: 89 (43.8%) Info: 91 (44.8%) 命名问题: - HighCPU 和 CpuUsageTooHigh 可能是同义词 - 12 个规则使用下划线命名建议统一为驼峰 重复检测: - MemoryHigh (line 45) 和 HighMemoryUsage (line 112) 表达式相似度 92% - DiskSpaceLow (line 78) 和 DiskFullWarning (line 156) 阈值相同 缺少注释: - 34 个规则缺少 summary - 67 个规则缺少 description实际效果运行这个脚本后我花了两个下午做了一件之前不敢想的事清理了 47 条重复规则给 89 条规则重新标注了正确的严重性。最关键的是我建立了一套简单的规则命名规范组件_指标_条件比如Node_CPU_UsageHigh严重性定义critical需要立即处理电话通知warning工作时间处理钉钉通知info记录即可不需要通知CI 检查每次提交规则变更自动运行脚本检查写在最后好的监控系统不是规则越多越好而是每一条告警都能准确、及时地传达有用信息。那个 200 多条规则的仓库现在缩减到了 89 条。虽然数量少了但每一条都知道它在监控什么、什么情况下触发、触发后该怎么做。如果你也面临类似的告警混乱问题不妨试试这个思路先分级、再清理、最后规范。工具只是手段目的是让告警重新变得可信。完整的脚本我放在 GitHub Gist可自行搜索 prometheus-rule-linter有类似困扰的同学可以参考。文中脚本已脱敏处理实际使用时请根据你的规则结构调整正则表达式。