Prometheus告警规则配置实战：从PromQL到Alertmanager完整指南

凌晨2点17分手机连着震了十几下。打开一看同一个系统里三台机器的磁盘使用率告警、两个服务的错误率告警还有一条节点离线告警全部在同一分钟刷出来。这种场面搞过Prometheus告警规则配置的人应该都懂指标监控是搭起来了Grafana面板也跑得挺漂亮偏偏告警规则这层像随手写在便签上的草稿想起来就加一条忘了就靠运气抗。今天这篇就从Prometheus告警规则配置讲起把规则文件的结构、PromQL表达式的正确姿势、告警文案怎么模板化、以及Alertmanager那边如何配合全部过一遍目标是让刚接手监控轮值的工程师也能照着写出可以直接上生产的规则。1. 先搞明白告警规则到底在哪一层生效1.1 别把Prometheus和Alertmanager的分工搞混很多新人第一次写告警规则容易默认“Prometheus配了规则之后系统自然就会发邮件/打电话”。这个预期是错的而且错得让人走很多弯路。Prometheus本身只做两件事持续抓取指标、按照规则文件周期性地评估表达式。至于告警发给谁、按什么频率发、重复告警怎么办这些全部是Alertmanager的工作。规则文件里写的expr、for、labels、annotations本质上是“定义什么状态算故障”而Alertmanager配置里的route、group_by、inhibit_rules、repeat_interval才是决定“故障信息怎么送达”。两者分工不同排查问题的时候如果混在一起很容易出现“规则明明触发了但没人收到消息”的怪现象。判断问题出在哪一边有一个很简单的方法打开Prometheus的Alerts页面看状态如果规则状态是Firing说明Prometheus这边已经完成判断剩下的路由、通知、抑制都属于Alertmanager的事如果状态一直是Pending甚至Inactive那就回到规则表达式和for时长上排查。这个思路能少浪费很多时间我在实际排障中每次都会先用这一条来快速划分责任边界。1.2 配置文件加载机制与热更新规则文件不是写在主配置文件里的而是在prometheus.yml中通过rule_files字段声明rule_files: - /etc/prometheus/rules/*.yml这里有个细节容易被忽略被rule_files匹配到的文件修改之后不会自动生效。Prometheus需要收到SIGHUP信号或者发送POST /-/reload请求才会重新加载。启动Prometheus的时候如果加了--web.enable-lifecycle参数就可以通过API触发热更新否则只能用进程信号。我见过不止一次这样的情况规则文件改了等半天没反应一查才知道忘了reload。更麻烦的是规则文件里如果有语法错误reload之后Prometheus并不会回滚而是保留旧规则继续运行只在日志里打一行Error loading config。所以稳妥的做法是先用promtool check rules校验再reload再观察日志。这个习惯应该像吃饭前洗手一样固定下来。1.3 一条告警从产生到通知的完整链路把整条链路拉直有助于理解每个参数在哪个环节起作用。一次完整的告警流程是这样的Prometheus按evaluation_interval通常是15秒到1分钟周期性地评估所有规则。某一瞬expr条件为真这条告警进入Pending状态同时开始计时。for时间到告警转为FiringPrometheus把这条告警推送给Alertmanager。Alertmanager根据route匹配到接收人再根据分组参数决定要不要合并、延迟发送。抑制规则会过滤掉一部分“没必要发”的告警静默则会在维护窗口期间强制拦截。最终通过邮件、钉钉、飞书、Webhook等渠道发出通知。这条链路里第2、3步由Prometheus规则文件控制第4、5、6步由Alertmanager配置控制。实际配置中很多“告警轰炸”问题根子就在第4步到第5步没做好。2. 手写第一个规则从YAML骨架到NodeDown告警2.1 规则文件的基本骨架一个标准规则文件是这样的结构groups: - name: node_alerts rules: - alert: NodeDown expr: up{jobnode-exporter} 0 for: 2m labels: severity: critical team: platform annotations: summary: 节点 {{ $labels.instance }} 离线 description: 节点 {{ $labels.instance }} 的 exporter 断连超过 2 分钟groups是顶层容器一个文件可以有多个group每个group有自己的名字里面装一批规则。group名只要不重复即可但建议用能表达用途的命名比如node_alerts、app_http_alerts、db_alerts否则规则一多管理成本会直线上升。规则里面的四个核心字段是alert、expr、for、labels和annotations。其中alert是规则名会出现在告警内容里expr是PromQL表达式决定“什么时候报警”for是持续时间防止抖动误报labels和annotations则是用来给告警打标签、写说明的。刚开始接触的人会低估后面两个字段的价值后面专门展开讲。2.2 逐字段拆解一条最小可用规则用NodeDown这条规则来拆。expr: up{jobnode-exporter} 0里up是Prometheus内置的指标每个抓取目标都会生成一条up样本1表示抓取正常0表示抓取失败。所以up 0的含义就是“某个exporter失联了”。加上{jobnode-exporter}这个标签选择器是为了过滤出我们真正关心的目标。如果没有这个选择器那么Prometheus自身、Pushgateway、甚至Blackbox探针的目标全都算进来告警范围就失控了。for: 2m表示条件持续2分钟才触发。这个值是防抖的关键。网络瞬断、exporter重启、Prometheus在滚动重启过程中的抓取间隙都可能导致up短暂变成0但往往几秒后又恢复。如果for设成0这些抖动全都会变成真实告警值班群会直接被刷屏。我在多数生产集群里用的是2分钟既能过滤瞬时抖动又不会让故障发现太迟。labels和annotations不是必填项但建议形成习惯。labels里我一般至少放severity和team两个字段前者表达严重级别后者表达归属团队这两个字段可以直接被Alertmanager的路由规则拿来匹配用途非常广。annotations里的summary和description则用来写给人看的信息支持模板语法下一章详细说。2.3 在UI、API、日志三个层面验证告警状态写完规则不是结束必须验证。Prometheus的Web UI上有两个页面最直接Alerts页面展示每条规则的当前状态和标签信息Rules页面展示所有规则的表达式和最近一次评估耗时。状态从Inactive变为Pending再变为Firing说明这条链路已经走通。如果想用脚本或API做自动化检查可以请求/api/v1/rules返回的JSON里会有每个rule的state字段和当前值。我自己比较依赖Prometheus自身的日志配合promtool check rules在reload前做语法校验基本不会让坏规则进入生产环境。有一点要提醒规则里的表达式即使语法正确也不代表业务语义正确。例如up 0确实能检测exporter失联但如果exporter所在机器确实宕机了这个告警当然会触发可如果exporter进程卡死但端口还在up仍然是1这条规则就发现不了问题。所以每条规则都要想清楚“我到底在检测什么”而不是只要有表达式就完事。3. 模板化与告警文案别让值班人看天书3.1 annotations把“谁、什么、多久、多严重”写清楚一条合格的告警通知至少要回答四个问题谁出了问题、什么指标异常、持续了多久、现在有多严重。这就是annotations模板要干的事。Prometheus的模板语法里$labels代表当前告警的所有标签$value代表触发时表达式的数值。例如annotations: summary: 节点 {{ $labels.instance }} 离线 description: 节点 {{ $labels.instance }} 已失联超过 2 分钟当前 up 值为 {{ $value }}模板里还能用一些内置函数比如humanize、humanizePercentage、humanize1024等。humanize能把数值变得易读比如把1048576显示成1.049MhumanizePercentage适合百分数场景。我在CPU使用率告警里习惯这样写description: {{ $labels.instance }} CPU使用率已达 {{ $value | humanize }}%如果告警文案只写“CPU使用率过高”值班人还要自己登服务器看具体是哪台、高到多少这等于把排查成本转嫁给了人。模板功能就是用来消除这种模糊性的。3.2 labels不只是装饰它是路由和静默的钥匙很多人把labels当成备注随便写这是个大坑。labels在告警链路里扮演着重要角色Alertmanager的route会根据labels匹配不同的接收人inhibit_rules抑制规则需要通过labels判断谁是源、谁是目标静默silence也要靠labels来匹配需要屏蔽的告警Grafana、通知模板里展示的维度也大多来自labels。所以labels的命名和取值必须稳定、可预期。比如severity的值就固定用critical、warning、info这一套不要这次写critical下次写high否则Alertmanager的匹配规则会失控。team字段也一样固定用团队名。凡是准备作为路由匹配依据的字段都要像数据库的外键一样严格规范。3.3 多环境复用的模板写法生产、测试、预发环境各有一套集群规则内容基本相同只是实例数量、阈值可能不一样。Prometheus本身不支持类似Helm那种变量渲染通常的做法是借助配置管理工具如Ansible、SaltStack或CI/CD流水线动态生成规则文件。这里我建议做一个统一约定所有环境里相同语义的规则名保持不变labels里的severity、team保持一致只在annotations中通过$labels动态注入实例信息。这样不同环境复用一个模板Alertmanager的路由规则不用为每个环境单独写一份后续维护成本会低很多。我实际做过一个模拟项目X里面有几十条规则通过一套模板渲染成三套环境的规则文件改动一个阈值就能在流水线里批量更新避免了直接在服务器上手改YAML再reload的操作。这个模式值得推广。4. 四类高频指标告警PromQL写法与语义陷阱4.1 CPU使用率别用瞬时采样值骗自己CPU使用率的常见错误写法是直接拿当前采样值算百分比比如(1 - rate(node_cpu_seconds_total{modeidle}[1m])) * 100这条表达式算的是“所有CPU核合计的使用率”数值可能超过100%在多核机器上会严重失真。我建议的生产级写法是求平均100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)rate(node_cpu_seconds_total{modeidle}[5m])先计算过去5分钟每核的空闲比例avg by (instance)再对单台机器上的所有CPU核做平均得出的才是这台机器整体的CPU使用率。用5分钟窗口而不是1分钟是因为短窗口对一次性任务的尖峰过于敏感。定时备份、任务调度瞬间产生的CPU飙升往往几秒就回落设成告警反而扰人。阈值怎么定也得看业务。在线交易类系统对CPU非常敏感我一般分两档warning在80%持续10分钟critical在90%持续5分钟。如果是离线计算任务型节点这个阈值可以整体上调因为跑任务时CPU高是常态。4.2 内存MemAvailable和MemFree完全是两回事Linux内存有个经典陷阱free命令看到的Free值很小但系统并没有内存压力因为Page Cache、Buffer都可以在需要时回收。如果用node_memory_MemFree_bytes去算内存使用率大概率会误报。正确做法是用node_memory_MemAvailable_bytes(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100MemAvailable是内核估算的“在不触发交换的情况下还能给新程序用多少内存”已经考虑了可回收缓存。这个值比MemFree真实得多。写内存告警时建议先弄清楚自己用的是哪个指标别一看内存占满了就急着加机器。4.3 磁盘与容量预测predict_linear的正确用法磁盘使用率告警相对直接但要注意过滤掉伪文件系统否则会被tmpfs、procfs这些虚拟文件系统打扰(1 - node_filesystem_free_bytes{fstype!~tmpfs|ramfs|overlay,mountpoint/} / node_filesystem_size_bytes{fstype!~tmpfs|ramfs|overlay,mountpoint/}) * 100 85只盯使用率还不够因为磁盘增长往往是有趋势的。Prometheus内置了predict_linear函数基于历史时间序列做线性回归预测未来某时刻的值。比如predict_linear(node_filesystem_free_bytes{mountpoint/,fstype!~tmpfs|ramfs|overlay}[1h], 4 * 3600) 0这条规则的意思是根据过去1小时磁盘剩余空间的下降趋势预测4小时后会不会变成0。如果会就触发告警。这比“使用率超过85%”更早发现问题适合磁盘增长平稳但是持续的场景。不过predict_linear假设趋势线性对突发性写盘不太灵所以我会把它和固定阈值告警搭配使用而不是二选一。4.4 业务接口健康错误率、延迟、探针系统监控之外业务层面的告警才最让业务团队关心。常见有三类第一个是探针类比如用Blackbox监控HTTP接口是否可达直接判断probe_success 0。这类告警最大价值是及时适合核心入口。第二个是错误率。以HTTP请求为例sum(rate(http_requests_total{code~5[0-9]{2}}[5m])) by (instance) / sum(rate(http_requests_total[5m])) by (instance)当这个比值超过0.055%时触发告警。写的时候要注意分母不能为0否则PromQL会返回空规则不会触发。实际业务中我会要求客户端至少把HTTP状态码打进code标签否则错误率没法算。第三个是延迟用histogram_quantile从直方图里取P99histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) 0.5这个表达式的意思是“过去5分钟内99%的请求耗时是否超过500毫秒”。延迟告警比错误率告警更敏感因为错误率可能很低但体验已经变差了。P99比平均值更能反映真实体验单用平均值做延迟告警会被少数慢请求拉高也会被大多数快请求拉低都不适合。5. 防止告警风暴从规则侧到Alertmanager侧的一次配置拉练5.1 for是防抖的第一道闸很多时候“告警风暴”不是故障太多而是同一时间段里各种不稳定因素叠加。for是第一道闸它要求条件持续一段时间才触发能从源头挡掉大量瞬态误报。我维护的集群里for时间大致有这几套组合告警类型for建议值理由节点离线2m抓取间隔加网络抖动太短会误报CPU高5m~10mCPU尖峰常见且易恢复内存高10m内存不会瞬间爆掉短时长纯属制造恐慌磁盘预测0m预测函数已经做了趋势平滑不需要再等业务错误率1m业务故障影响直接太长会错过黄金处理期这里没有统一标准要结合自己的抓取周期和业务容忍度去调。抓取周期是15秒还是60秒直接影响for该给多少。for: 30s在60秒抓取周期里可能连两个采样点都凑不齐触发判定就被拉长这种配置很容易让人产生“规则没生效”的错觉。5.2 路由分组、抑制与静默怎么配合Alertmanager的route配置决定了告警如何合并、发送给谁。当前最简单的生产配置长这样route: receiver: ops group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: oncall - match: team: backend receiver: backend-channelgroup_by: [alertname, cluster]表示同一告警名、同一集群的告警合并成一条消息这是对付风暴最有效的手段。group_wait: 30s让Alertmanager等待30秒再发第一条目的是把短时间内同时触发的同类告警打包。repeat_interval: 4h控制同类告警重复发送的间隔避免每隔几分钟就轰炸一遍。severity: critical的告警走oncall接收器其他团队相关走各自的聊天频道这是最基本的职责分流。如果所有告警都发给同一个人再好的规则也扛不住疲劳。5.3 抑制与静默主机挂了别让它的服务再刷屏最典型的告警风暴场景是一台物理机宕机上面挂了二三个服务黑盒探针、错误率、进程监控全都同时报警。问题是值班人已经收到NodeDown了他需要的不是再收到同一台机器上所有service的“连环套告警”。Alertmanager的抑制规则就是为这个场景设计的inhibit_rules: - source_matchers: [alertnameNodeDown] target_matchers: [severitywarning] equal: [instance]含义是当同一instance上存在NodeDown且为critical级的告警时抑制这台机器上所有severity为warning的告警。这样通知数量瞬间减少大半。静默则是主动维护场景。比如计划内维护窗口可以提前通过Alertmanager的Silences页面创建静默或调用API批量创建。静默匹配也是基于labels所以我反复强调labels的规范性——静默创建出错很多时候就是labels写得乱。5.4 promtool检错、单测、格式化一条龙日常维护规则文件我最依赖的工具是promtool。两个最常用的命令promtool check rules /etc/prometheus/rules/*.yml promtool test rules rules_test.ymlcheck rules做语法和配置结构校验这个在reload前必须跑。test rules更进一步可以写单元测试文件模拟指标数据验证规则触发逻辑。一个最小单测长这样rule_files: - rules.yml evaluation_interval: 1m tests: - interval: 1m input_series: - series: up{instancesim-1,jobnode-exporter} values: 00x10 alert_rule_test: - eval_time: 5m alertname: NodeDown exp_alerts: - exp_labels: severity: critical instance: sim-1values: 00x10模拟一条从第0分钟开始一直为0的序列共16个点。eval_time: 5m表示在第5分钟时评估规则这时for: 2m已经满足预期触发NodeDown告警。用这套方式新增规则可以在不真正制造故障的情况下验证逻辑非常适合在CI里跑。6. 我配置告警规则这些年踩过的坑6.1 规则不生效先查reload有段时间我总是碰到“规则改了UI上没变化”的情况。一开始以为是表达式写错后来发现只是没触发重载。Prometheus的规则文件不像targets那样能通过文件发现自动更新它没有类似file_sd_configs的机制。所以每次改完规则必须执行curl -X POST http://localhost:9090/-/reload前提是启动参数里带--web.enable-lifecycle。如果忘记这个参数只有SIGHUP能救。最好的习惯是把这个reload动作写进发布脚本里和规则文件更新绑定在一起。6.2 在expr里写死IP/主机名的教训早期我试过直接写instance192.168.1.10去匹配目标后来机房调整、机器迁移所有写死IP的规则全变成了“无法匹配”。Prometheus的标签设计本来就是让告警规则面向标签而非面向实体正确做法永远是用instance这类通用标签配合{jobnode-exporter}来做范围限定。确实需要针对某个目标定制规则时也应该在采集端给目标打特定标签而不是在规则里写死。6.3 告警疲劳比没有告警更可怕弹窗太多人就麻木了人一旦麻木真出事时也没人响应。这个道理做监控的都懂但真正主导配置的人很少敢砍规则。我后来养成一个习惯每个季度会统计一遍所有规则的历史触发次数找出那些“一直报警但从不产生工单”的规则逐个讨论是调阈值、改for还是直接下线。告警规则是在不断裁剪中变好的不是越加越多越好。我个人还有一个收尾建议每个新集群上线前不要只在测试环境验证规则而是挑两台预发机器真正断掉exporter人为触发一次NodeDown告警完整走一遍“Pending → Firing → Alertmanager → 通知送达 → 抑制生效”的流程。这套演练跑通了才算真正完成了Prometheus告警规则配置的闭环。