Prometheus告警规则模板：从资源到应用，告别误报与噪音

告警规则这件事我见过太多团队栽在同一个坑里Prometheus 部署得漂漂亮亮Grafana 大盘也画得有模有样结果真出故障的时候要么一条告警都没响要么半夜被三百条重复通知炸醒爬起来一看全是同一个根因引发的连锁反应。问题往往不在监控系统本身而在于告警规则这套判断逻辑从一开始就是拍脑袋写的——阈值随手填、for 时长不设、标签不统一、该用 rate 的地方用了 irate该聚合的地方没聚合。这篇内容我想聊的就是一套可以直接拿去用的 Prometheus 告警规则模板以及这些模板背后每一行配置为什么这么写。它面向的是已经把 Prometheus 跑起来、手里有 node_exporter 和各种中间件 exporter、但告警规则还停留在抄一段算一段阶段的同学。我会按资源层、应用层、中间件层、告警治理四个维度拆开讲每个规则都给出可直接复制的 YAML、阈值选取的依据、以及我在实际环境里踩过的坑。看完你至少能做到两件事一是把一套覆盖主机、容器、数据库、消息队列的基础告警体系搭起来二是知道哪些规则是噪音制造机该删就删。1. 先想清楚告警规则到底在判断什么很多人写告警规则的第一反应是CPU 超过 80% 就报警这几乎是最典型的错误起点。告警的本质不是某个指标达到了某个数值而是某个业务能力正在或即将受损。CPU 80% 可能什么事都没有CPU 40% 也可能因为线程池打满而服务已经挂了。所以在动手写 YAML 之前得先把判断逻辑的层次理清楚。1.1 告警的三个层次症状、原因、征兆我习惯把告警分成三层。症状层是用户能感知到的东西比如接口错误率上升、P99 延迟飙高、订单创建失败原因层是导致症状的直接技术因素比如某个 Pod 的 CPU 被限流、数据库连接池耗尽、磁盘写满征兆层是还没造成影响但趋势不妙的信号比如内存使用率连续两小时缓慢爬升、磁盘剩余空间按当前写入速度还能撑三天。这三层的告警策略完全不同。症状层必须做到少而准每一条都要能直接对应到用户影响值班的人看到就得立刻处理原因层可以多一些用来快速定位征兆层适合做成低优先级的工单或者日报而不是半夜打电话。我见过最糟糕的配置是把征兆层的东西全配成 P1 告警结果团队对告警彻底脱敏真正的故障来了反而没人看。模板设计上我给每个规则都标注了层级。资源类指标CPU、内存、磁盘大多属于原因层和征兆层应用类指标错误率、延迟属于症状层中间件类连接数、队列积压介于原因和症状之间。这个分层直接决定了后面severity标签怎么打、通知走哪个通道。1.2 为什么 for 字段比阈值更重要新手最容易忽略的就是for。一条up 0的规则如果不加for网络抖一下、exporter 重启一次告警就飞出去了。我一般给基础可用性规则设for: 1m到2m给资源使用率设for: 5m到15m给趋势类设for: 30m甚至更长。这里有个反直觉的经验阈值可以松for 不能短。比如磁盘使用率设 85% 加for: 10m比设 80% 加for: 1m要靠谱得多。因为磁盘从 80% 涨到 85% 通常有足够时间而 1 分钟的瞬时波动太容易误报。反过来如果某个指标本身波动极大比如瞬时 QPS那要么用avg_over_time平滑要么把 for 拉长绝不能靠调阈值硬压。还有一个细节for的计时是从表达式第一次为真开始算的如果中间有一次评估为假计时会重置。所以对于间歇性抽风的指标单纯加 for 不一定管用得配合聚合函数。比如某个接口偶尔超时用rate(errors[5m]) 0.05加for: 5m比用瞬时值靠谱得多。1.3 标签体系决定了告警能不能被正确路由告警发出去之后要能路由到对的人靠的就是标签。我在模板里强制要求每条规则至少带这几个标签severitycritical/warning/info、team归属团队、categoryresource/application/middleware、runbook处理手册链接。前三个用于 Alertmanager 的路由匹配最后一个用于值班的人点进去看怎么处理。severity的取值不要贪多三级足够。critical 走电话加即时消息warning 走即时消息info 只进日报。我见过有团队分了五级结果路由规则写了一百多行维护成本高得离谱最后没人搞得清楚哪条告警该走哪。标签值也要统一别一会儿critical一会儿Critical一会儿P1Alertmanager 的匹配是大小写敏感的这种不一致会导致告警静默失效。2. 主机资源层最基础也最容易写错的规则主机层规则是所有监控的地基node_exporter 提供的指标足够覆盖 CPU、内存、磁盘、网络、文件系统。但恰恰是这些看起来最简单的规则误报率最高。下面这套模板是我在多个环境里反复调过的版本。2.1 CPU 与负载别只看使用率直接上规则groups: - name: host-resource rules: - alert: HostHighCpuLoad expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} CPU 使用率过高 description: CPU 使用率持续 10 分钟超过 85%当前值 {{ $value | printf \%.1f\ }}% - alert: HostLoadHigh expr: node_load5 / count by (instance) (node_cpu_seconds_total{modeidle}) 1.5 for: 15m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 负载偏高 description: 5 分钟平均负载与核数比值超过 1.5当前 {{ $value | printf \%.2f\ }}CPU 规则用100 - idle是最稳的算法比直接对node_cpu_seconds_total求和再减要清晰。阈值 85% 加for: 10m是我实测下来误报最少的组合——短时编译、批量任务会把 CPU 顶到 90% 以上但很少持续 10 分钟。负载规则更值得说。node_load5是绝对值单看没意义必须除以核数。核数用count by (instance) (node_cpu_seconds_total{modeidle})算因为每个核都有一条 idle 记录。比值超过 1.5 说明有排队超过 2 基本就是过载了。这里用node_load5而不是node_load1是因为 1 分钟负载抖动太大5 分钟更能反映真实压力。注意容器化环境里 node_exporter 看到的是宿主机负载如果你的业务跑在容器里且做了 CPU limit宿主机负载高不代表容器有问题反之亦然。这种情况要额外配 cgroup 级别的规则不能只靠主机规则。2.2 内存available 才是关键指标- alert: HostMemoryHigh expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 90 for: 10m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 内存使用率过高 description: 可用内存低于 10%当前使用率 {{ $value | printf \%.1f\ }}%内存这块最大的坑是用MemFree而不是MemAvailable。Linux 会把大量内存拿去做 page cacheMemFree常年很低但这些都是可回收的用MemFree算使用率会一直误报。MemAvailable才是内核估算的真正可用内存包含可回收的 cache。这个细节不知道坑过多少人。阈值我设 90% 而不是 80%因为内存使用率天然就高很多服务会主动吃满缓存。真正危险的是 available 掉到很低之后开始触发 OOM Killer所以 90% 加 10 分钟是个合理的预警点。如果你的服务对内存敏感可以再补一条node_memory_MemAvailable_bytes 512MB的绝对阈值规则两条一起看更准。2.3 磁盘空间和 inode 要分开看- alert: HostDiskSpaceLow expr: (node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 100 15 for: 10m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 空间不足 description: 剩余空间低于 15%当前 {{ $value | printf \%.1f\ }}% - alert: HostDiskWillFillIn24h expr: predict_linear(node_filesystem_avail_bytes{fstype!~tmpfs|overlay}[6h], 24 * 3600) 0 for: 30m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} 预计 24 小时内写满 description: 按最近 6 小时写入速度推算24 小时内将耗尽空间磁盘规则有两个要点。第一必须过滤fstypetmpfs和overlay这类文件系统容量小、变化快纳入告警纯属制造噪音。第二除了静态阈值一定要加predict_linear的趋势预测。静态阈值只能告诉你现在快满了趋势预测能告诉你还有多久满后者对安排扩容窗口有用得多。predict_linear的用法是拿最近 6 小时的数据做线性回归预测 24 小时后剩余空间。如果预测值小于 0说明按当前速度 24 小时内会写满。这个规则对日志盘特别有用因为日志增长往往是线性的预测很准。但要注意如果磁盘写入是突发性的比如每天凌晨跑批线性预测会失真这时候要么拉长观测窗口要么干脆只用静态阈值。inode 规则单独列一条- alert: HostInodeLow expr: (node_filesystem_files_free{fstype!~tmpfs|overlay} / node_filesystem_files{fstype!~tmpfs|overlay}) * 100 10 for: 10m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 磁盘 {{ $labels.mountpoint }} inode 不足inode 耗尽是个很隐蔽的故障——磁盘明明还有空间但就是创建不了新文件。大量小文件场景邮件队列、缓存目录、session 文件特别容易中招。这条规则不能省。2.4 网络与文件描述符- alert: HostNetworkReceiveErrors expr: rate(node_network_receive_errs_total{device!~lo|veth.*|docker.*|br-.*}[5m]) 0 for: 5m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 网卡 {{ $labels.device }} 接收错误 - alert: HostFileDescriptorExhausted expr: node_filefd_allocated / node_filefd_maximum * 100 85 for: 10m labels: severity: warning category: resource annotations: summary: 主机 {{ $labels.instance }} 文件描述符使用率过高网络错误规则里device的过滤很关键lo、veth、docker、br-这些虚拟设备在容器环境里数量多、波动大不过滤的话告警会刷屏。文件描述符这条规则经常被忽略但 fd 耗尽会导致服务无法建立新连接表现是服务还活着但就是不响应排查起来很费劲提前告警能省很多事。3. 应用层从 RED 方法出发的症状告警应用层告警我强烈建议按 RED 方法来组织——Rate请求速率、Errors错误率、Duration延迟。这三个维度直接对应用户是否受影响是症状层告警的核心。前提是你的应用暴露了对应的指标不管是自己埋点还是用 exporter 采集。3.1 错误率分母的选择决定告警质量- name: application-red rules: - alert: AppHighErrorRate expr: | sum by (service) (rate(http_requests_total{status~5..}[5m])) / sum by (service) (rate(http_requests_total[5m])) 0.05 for: 5m labels: severity: critical category: application annotations: summary: 服务 {{ $labels.service }} 5xx 错误率超过 5% description: 当前错误率 {{ $value | printf \%.2f\ }}%错误率规则最容易犯的错是分母选错。用rate(http_requests_total[5m])做分母意味着把 4xx 也算进去了。但 4xx 通常是客户端问题参数错误、鉴权失败不该算进服务端错误率。更严谨的做法是分母只算 2xx 和 5xx或者干脆用总请求数但把 4xx 单独监控。另一个坑是低流量下的误报。如果某个服务 5 分钟内只有 10 个请求其中 1 个失败错误率就是 10%直接触发 critical。这种小样本放大问题很常见。解决办法是加一个绝对量条件expr: | ( sum by (service) (rate(http_requests_total{status~5..}[5m])) / sum by (service) (rate(http_requests_total[5m])) 0.05 ) and ( sum by (service) (rate(http_requests_total[5m])) 1 )and后面这个条件要求每秒至少 1 个请求低于这个量级不告警。这个技巧我在好几个环境里用过能砍掉大量低流量误报。3.2 延迟P99 比平均值有用一百倍- alert: AppHighLatency expr: | histogram_quantile(0.99, sum by (service, le) (rate(http_request_duration_seconds_bucket[5m])) ) 1 for: 10m labels: severity: warning category: application annotations: summary: 服务 {{ $labels.service }} P99 延迟超过 1 秒延迟告警必须用分位数平均值会被大量快请求稀释完全反映不了长尾。histogram_quantile配合_bucket指标是标准做法但有几个细节要注意。第一le标签必须保留在sum by里否则分位数算不出来。第二bucket 的边界要合理如果最上面的 bucket 是InfP99 可能落在最后一个有限 bucket 之外算出来的值会失真。第三rate的窗口要和 bucket 的采集周期匹配5 分钟窗口配 15 秒采集是常见组合。阈值 1 秒是通用起点实际要按业务定。面向用户的接口 200ms 就该告警内部服务 1 秒可以接受批处理接口可能 10 秒都正常。我建议每个服务单独配别用一个全局阈值套所有服务。3.3 服务可用性与重启检测- alert: ServiceDown expr: up{job~.} 0 for: 2m labels: severity: critical category: application annotations: summary: 目标 {{ $labels.instance }} ({{ $labels.job }}) 无法抓取 description: Prometheus 已连续 2 分钟无法抓取该目标 - alert: ContainerRestartingFrequently expr: increase(kube_pod_container_status_restarts_total[1h]) 3 for: 5m labels: severity: warning category: application annotations: summary: 容器 {{ $labels.container }} 频繁重启up 0是最基础的规则但for: 2m不能省否则 Prometheus 自己重启或者配置 reload 的时候会误报一片。重启检测用increase统计 1 小时内重启次数超过 3 次说明有问题——可能是 OOM、可能是探针配置不当、也可能是代码崩溃。这条规则配合kube_pod_container_status_last_terminated_reason能直接看出重启原因排查效率高很多。4. 中间件层连接数和队列积压是重灾区中间件告警的核心思路是盯住资源耗尽和积压两类信号。数据库连接池打满、消息队列积压、缓存命中率暴跌这些都是故障的前兆而且往往比应用层症状更早出现。4.1 数据库连接池与慢查询- name: middleware-database rules: - alert: DatabaseConnectionPoolExhausted expr: | sum by (instance) (mysql_global_status_threads_connected) / sum by (instance) (mysql_global_variables_max_connections) 0.8 for: 5m labels: severity: critical category: middleware annotations: summary: 数据库 {{ $labels.instance }} 连接数接近上限 description: 连接使用率 {{ $value | printf \%.1f\ }}% - alert: DatabaseSlowQueries expr: rate(mysql_global_status_slow_queries[5m]) 1 for: 10m labels: severity: warning category: middleware annotations: summary: 数据库 {{ $labels.instance }} 慢查询增多连接池规则用已用/上限的比值阈值 80% 是经验值。为什么不是 90%因为连接数从 80% 涨到 100% 可能只需要几秒突发流量留 20% 的缓冲能让你有时间介入。慢查询用rate算每秒慢查询数超过 1 说明有 SQL 在拖后腿配合慢查询日志能快速定位。这里有个我踩过的坑max_connections是变量不是状态指标名是mysql_global_variables_max_connections别写成status。另外不同版本的 exporter 指标名可能有差异上线前一定要先在 Prometheus 里查一下实际指标名别直接抄。4.2 消息队列积压- alert: MessageQueueBacklog expr: rabbitmq_queue_messages_ready{queue!~^amq\\..*} 10000 for: 10m labels: severity: warning category: middleware annotations: summary: 队列 {{ $labels.queue }} 积压超过 1 万条 - alert: MessageQueueNoConsumer expr: rabbitmq_queue_consumers 0 and rabbitmq_queue_messages_ready 0 for: 5m labels: severity: critical category: middleware annotations: summary: 队列 {{ $labels.queue }} 有积压但没有消费者积压告警的阈值要按队列的实际吞吐定1 万条对高吞吐队列可能就几秒的事对低吞吐队列可能是几小时。更聪明的做法是用积压增长速度而不是绝对值expr: deriv(rabbitmq_queue_messages_ready[10m]) 10deriv算的是每秒变化率大于 10 说明积压正在快速上涨这比静态阈值更能反映问题。不过deriv对突刺敏感最好和绝对值规则配合用。有积压但没消费者这条规则价值极高。消费者全挂了但队列还在收消息这种情况如果不告警等发现的时候积压可能已经几十万条恢复起来非常痛苦。rabbitmq_queue_consumers 0配合messages_ready 0能精准命中这个场景。4.3 缓存命中率- alert: CacheHitRateLow expr: | rate(redis_keyspace_hits_total[5m]) / (rate(redis_keyspace_hits_total[5m]) rate(redis_keyspace_misses_total[5m])) 0.8 for: 15m labels: severity: warning category: middleware annotations: summary: Redis {{ $labels.instance }} 缓存命中率低于 80%命中率暴跌通常意味着缓存穿透或者 key 设计有问题会导致后端数据库压力骤增。阈值 80% 是通用值实际要看业务——有些场景 95% 才算正常。这条规则要和数据库 QPS 规则一起看命中率下降往往伴随数据库 QPS 上升两个信号叠加基本能确认是缓存问题。5. 告警治理让规则真正可维护的几个硬规矩规则写完只是开始真正难的是让它长期可维护。我见过太多团队规则文件越堆越大最后没人敢动因为不知道删了会怎样。下面这几条是我在实践中总结的硬规矩。5.1 用 recording rules 预计算别让告警表达式太复杂告警表达式里塞一堆sum by和rate会让 Prometheus 每次评估都重算一遍规则多了之后评估延迟会很明显。把常用的聚合提前用 recording rules 算好- name: recording-rules rules: - record: service:http_error_rate:5m expr: | sum by (service) (rate(http_requests_total{status~5..}[5m])) / sum by (service) (rate(http_requests_total[5m])) - record: instance:cpu_usage:5m expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)告警规则直接引用service:http_error_rate:5m表达式清爽评估也快。recording rule 的命名我遵循level:metric:operations的约定比如instance:cpu_usage:5m表示 instance 级别的 cpu_usage5 分钟窗口。这个约定不是强制的但统一之后可读性提升明显。5.2 每条告警都要有 runbook 和负责人没有 runbook 的告警等于没有告警。值班的人半夜被叫醒看到CPU 高三个字第一反应是懵的。runbook 不需要多长写清楚三件事就行这个告警通常意味着什么、第一步查什么、找谁。我一般把 runbook 放在内部 wiki用runbook标签挂链接。负责人用team标签标注配合 Alertmanager 的路由规则不同团队的告警走不同通道。这里有个细节team标签的值要和组织架构对齐别用缩写或者代号否则新人根本看不懂该找谁。5.3 定期做告警审计砍掉噪音我建议每个季度做一次告警审计看三个数据过去一季度每条告警的触发次数、其中真正需要人工介入的比例、平均响应时间。触发次数高但介入比例低的基本就是噪音要么调阈值要么直接删。有个很实用的做法是给告警加一个actionable标签值为true或false。false的告警只进日报不进即时通知观察一段时间后如果确实没人看就删掉。这个机制能有效防止规则无限膨胀。5.4 抑制规则别让一个根因炸出几十条告警最后说抑制。一个数据库挂了依赖它的十个服务全部报错如果每个服务都配了错误率告警值班的人会收到几十条通知根本分不清主次。Alertmanager 的inhibit_rules能解决这个问题inhibit_rules: - source_match: severity: critical category: middleware target_match: severity: warning equal: [instance]意思是同一个 instance 上如果已经有 critical 的中间件告警就抑制它的 warning 告警。这样数据库挂了只会收到一条 critical而不是被一堆衍生告警淹没。抑制规则要谨慎设计equal的标签选错了可能把该报的也抑制掉建议先在测试环境验证。6. 几个我反复踩过的具体坑规则模板给完了最后聊几个具体到让人抓狂的坑都是我在实际环境里真金白银换来的。第一个是时间窗口和采集周期的错配。rate的窗口如果小于采集周期的两倍算出来的值会不准甚至为 0。比如采集周期 30 秒rate(x[1m])只有两个点稍微抖一下结果就失真。经验法则是窗口至少是采集周期的 4 倍30 秒采集就用[2m]起步。第二个是标签基数爆炸。给告警表达式加by (instance, pod, container, endpoint)这种高基数标签会导致 recording rule 产生海量时间序列Prometheus 内存直接起飞。聚合时只保留真正需要的标签路由用的标签severity、team在告警规则里写死别从指标里带。第三个是**for和keep_firing_for的区别**。for是持续为真多久才触发keep_firing_for是触发后即使条件不满足也保持多久。后者适合那些会抖动的指标避免告警反复触发和恢复。这个字段在较新版本的 Prometheus 里才有用之前确认版本。第四个是告警恢复通知的噪音。默认情况下告警恢复也会发通知如果某个指标在阈值附近反复横跳你会收到触发-恢复-触发-恢复的循环轰炸。解决办法是给这类规则加keep_firing_for或者干脆把阈值调得离正常值远一点让它别那么容易触发。第五个是别用告警做容量规划。告警是出事了叫我不是告诉我未来会怎样。容量规划要靠趋势分析和定期 review指望告警提前一周告诉你磁盘要满是不现实的。predict_linear能给你 24 小时的预警再长就不准了。这套模板我建议不要一次性全上先挑症状层的几条服务可用性、错误率、延迟跑起来观察一周误报情况再逐步加原因层和征兆层。规则是养出来的不是抄出来的每条规则上线后都要有人盯着它的触发记录该调的调、该删的删。监控系统最大的敌人从来不是指标不够而是告警太多导致没人看。