Prometheus告警规则模板：四层分级与阈值推导实战

告警规则写得好不好直接决定了值班那晚能不能睡个整觉。我见过太多团队把 Prometheus 部署起来、Grafana 面板拉得漂漂亮亮结果告警规则要么是从别处抄来的一堆up 0要么是阈值拍脑袋定的上线第一周就被误报淹没最后干脆把通知渠道一关了事。这套“常用 Prometheus 告警规则模板”要解决的正是这个问题它不是一个配置文件而是一套经过生产环境打磨的规则骨架覆盖主机、容器、中间件、应用层四个维度配套阈值推导逻辑和分级策略适合刚接手监控体系的新手照着落地也适合老手拿来对照查漏。我下面要拆的是这套模板背后的设计思路和实操细节。重点不在于给你一堆 YAML 让你复制粘贴而在于讲清楚每条规则为什么这么写、阈值怎么算出来的、哪些坑我踩过。你拿到手之后应该能自己判断这条规则放到我的环境里会不会误报要不要改。1. 规则模板的整体设计与分层思路1.1 为什么按“症状”而不是“原因”来组织告警新手最容易犯的错是把告警规则写成“原因清单”CPU 高了报一条、内存高了报一条、磁盘 IO 高了报一条。听起来很全面实际结果是——一台机器负载飙升你同时收到七八条告警手机震个不停但真正的问题只有一个。这就是典型的“告警风暴”根因被淹没在噪音里。这套模板的核心设计原则是症状驱动优先告警用户能感知到的、业务层面的异常比如请求错误率上升、接口延迟变高、服务不可用把资源类指标CPU、内存、磁盘降级为“预警”或“观察”级别只在持续异常时才触发。举个具体例子磁盘使用率 85% 不该是 P1 告警它只是个趋势信号但磁盘写满导致服务无法写入那就是 P1。前者用for拉长观察窗口后者用即时触发。这样设计的好处很直接值班同学收到 P1 告警时知道“用户正在受影响”会立刻处理收到 P2 预警时可以排进当天的工作清单。告警的优先级和人的响应动作一一对应而不是所有告警都一个响法。1.2 四层规则骨架的划分逻辑模板把规则分成四层每层的采集方式、指标命名、阈值基准都不一样混在一起写会非常乱。分层之后每层可以独立维护、独立调参。层级覆盖对象典型指标来源告警关注点建议级别主机层物理机、虚拟机node_exporterCPU、内存、磁盘、网络、文件句柄P2 为主容器层Pod、容器运行时kube-state-metrics、cAdvisor重启次数、OOM、副本数、调度失败P1/P2中间件层数据库、缓存、消息队列各中间件 exporter连接数、慢查询、队列积压、主从延迟P1/P2应用层业务服务应用埋点、blackbox_exporter错误率、延迟分位、可用性、探活P1 为主这个分层的实际意义在于责任归属。主机层告警通常归运维容器层归平台团队中间件层归 DBA 或中间件负责人应用层归业务研发。规则文件按层拆开路由配置里按team标签分流谁的孩子谁抱走避免“告警发到群里没人认领”的尴尬。1.3 分级策略P1 到 P3 的判定标准分级不是拍脑袋得有可执行的判定标准。我在模板里用的是一套“影响面 × 紧迫度”的二维判断P1立即处理核心业务不可用或错误率超过 5% 持续 2 分钟以上或数据面临丢失风险。响应要求5 分钟内有人接手。P2当天处理非核心业务异常或核心业务性能下降但未中断或资源使用率持续超过阈值 15 分钟。响应要求工作时间内处理。P3观察记录趋势性异常如磁盘增长过快、连接数缓慢爬升。响应要求记录进待办不强制即时响应。注意分级标准一定要和团队的实际值班能力匹配。如果团队只有两个人轮值P1 定义得太宽会导致天天被叫醒最后大家对告警脱敏真正的事故反而没人管。宁可 P1 少而准也不要多而滥。2. 主机层告警规则的核心细节与阈值推导2.1 CPU 与内存为什么不能只看瞬时值CPU 使用率的告警是最容易写错的。很多人直接写avg(rate(node_cpu_seconds_total{mode!idle}[1m])) by (instance) 0.81 分钟窗口、80% 阈值。这条规则在压测环境看着挺正常上了生产就是灾难——编译任务、日志轮转、定时备份都会让 CPU 短时冲高1 分钟窗口根本过滤不掉。我的做法是拉长窗口 提高阈值 加for。具体来说用 5 分钟的平均值阈值放到 85%for设为 10 分钟。这样只有持续 10 分钟 CPU 都压在 85% 以上才触发短时尖峰自动被平滑掉。表达式大致是这样- alert: HostHighCpuUsage expr: | 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: P2 team: infra annotations: summary: 主机 {{ $labels.instance }} CPU 持续高负载 description: 5 分钟平均 CPU 使用率 {{ $value | printf \%.1f\ }}%已持续 10 分钟请检查是否有异常进程。这里有个细节值得说rate的窗口用 5mfor用 10m两者不是随便定的。rate窗口太短比如 1m会让曲线抖动剧烈太长比如 30m又会掩盖突发问题5m 是个折中既能反映近期趋势又不会太敏感。for的 10m 则是给“持续”下定义——10 分钟内每个评估点都超标才算数。内存的坑更多。Linux 的内存使用率不能简单用1 - MemFree/MemTotal算因为 page cache 占用的内存是可回收的算进去会虚高。正确的算法是排除buff/cache- alert: HostHighMemoryUsage expr: | (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 90 for: 15m labels: severity: P2 team: infraMemAvailable是内核估算的“真正可用内存”已经扣掉了不可回收部分比MemFree靠谱得多。阈值我定在 90%因为内存到 90% 时系统通常还有缓冲余地到 95% 才开始影响新进程分配。for给 15 分钟是因为内存泄漏往往是缓慢爬升短窗口看不出来。2.2 磁盘使用率、inode 与预测性告警三件套磁盘告警要分三个维度写缺一不可。第一个是使用率第二个是 inode第三个是增长趋势预测。前两个是“已经出问题”第三个是“即将出问题”。使用率规则要注意排除只读文件系统和临时挂载点否则容器环境里一堆overlay、tmpfs会疯狂误报。用fstype过滤- alert: HostDiskSpaceUsage expr: | (1 - node_filesystem_avail_bytes{fstype~ext4|xfs|btrfs} / node_filesystem_size_bytes{fstype~ext4|xfs|btrfs}) * 100 85 for: 15m labels: severity: P2 team: infra annotations: summary: 主机 {{ $labels.instance }} 分区 {{ $labels.mountpoint }} 空间不足inode 耗尽是很多人忽略的故障类型。磁盘还有空间但 inode 用完了照样写不进新文件而且报错信息很迷惑“No space left on device” 但df -h显示有空间。规则写法类似把指标换成node_filesystem_files_free- alert: HostDiskInodeUsage expr: | (1 - node_filesystem_files_free{fstype~ext4|xfs} / node_filesystem_files{fstype~ext4|xfs}) * 100 85 for: 15m labels: severity: P2预测性告警用的是predict_linear函数这是 Prometheus 里被低估的一个好东西。它基于过去一段时间的增长斜率预测未来多久会写满- alert: HostDiskWillFillIn4Hours expr: | predict_linear(node_filesystem_avail_bytes{fstype~ext4|xfs}[6h], 4 * 3600) 0 for: 30m labels: severity: P3 team: infra这条规则的意思是按过去 6 小时的写入速度如果 4 小时内磁盘会写满就提前预警。for: 30m是为了过滤掉日志轮转、临时大文件造成的假斜率。这条规则的价值在于给你留出处理时间——4 小时足够你扩容或者清理而不是等磁盘真满了再救火。实操心得predict_linear在写入模式规律的环境里很准但在有明显周期性比如每天凌晨批量导入的环境里容易误报。如果你的业务有强周期特征把窗口拉长到 24h 以上或者干脆关掉这条改用固定阈值。2.3 网络与文件句柄容易被忽视的两类故障源网络告警我一般只写两条网卡错误包和连接数耗尽。错误包用node_network_receive_errs_total的增长率连接数用node_netstat_Tcp_CurrEstab对比系统上限。文件句柄则是node_filefd_allocated / node_filefd_maximum超过 80% 就要警惕因为句柄泄漏往往在业务高峰期才暴露等到报 “Too many open files” 时服务已经挂了。这两类指标的特点是“平时不动一动就是大事”所以阈值可以设得激进一点for短一点宁可早报。3. 容器层告警Kubernetes 场景下的关键规则3.1 Pod 重启与 OOM区分“正常滚动”和“真故障”容器环境里kube_pod_container_status_restarts_total这个指标一涨就告警是最常见的误报来源。滚动发布、配置变更、节点驱逐都会导致重启这些是预期内的。真正要抓的是“非预期重启”和“OOMKilled”。区分方法看重启的速率而不是绝对值。用increase算 15 分钟内的重启增量超过 3 次才报- alert: PodFrequentRestart expr: | increase(kube_pod_container_status_restarts_total[15m]) 3 for: 5m labels: severity: P1 team: platform annotations: summary: Pod {{ $labels.namespace }}/{{ $labels.pod }} 频繁重启OOM 的判断要看容器的last_terminated_reason等于OOMKilled时触发。这条规则比单纯看重启次数精准得多因为 OOM 是明确的内存超限信号说明 limit 设小了或者有内存泄漏- alert: PodOOMKilled expr: | kube_pod_container_status_last_terminated_reason{reasonOOMKilled} 1 for: 1m labels: severity: P1 team: platform3.2 副本数与调度失败可用性兜底kube_deployment_status_replicas_available小于期望副本数说明有 Pod 起不来。这条规则要结合for使用因为发布过程中副本数短暂不足是正常的给 5 分钟缓冲- alert: DeploymentReplicasMismatch expr: | kube_deployment_spec_replicas ! kube_deployment_status_replicas_available for: 5m labels: severity: P1 team: platform调度失败用kube_pod_status_unschedulable这条规则能提前发现资源不足或亲和性配置错误避免 Pod 一直 Pending 却没人知道。3.3 容器资源 limit 逼近预防性告警容器 CPU throttling 是个隐蔽的性能杀手。container_cpu_cfs_throttled_periods_total占比过高说明容器被限流了业务延迟会莫名其妙变高。这条规则我建议所有跑在线业务的团队都加上- alert: ContainerCpuThrottling expr: | rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m]) 0.25 for: 10m labels: severity: P2 team: platform阈值 25% 是经验值——超过四分之一的周期被限流业务性能已经明显受影响了。这条规则帮我在好几个项目里定位到“CPU limit 设太小”的问题比看平均使用率有效得多。4. 中间件与应用层规则的落地要点4.1 中间件连接池、慢查询与主从延迟中间件告警的关键是“贴着中间件自身的健康指标写”而不是只看主机资源。以数据库为例连接池使用率、慢查询数量、主从复制延迟是三条必写规则。连接池用当前连接数 / 最大连接数超过 80% 预警因为连接池打满后新请求会直接失败慢查询用rate(slow_queries_total[5m])持续大于 0 就值得关注主从延迟用seconds_behind_master超过 30 秒报 P1因为延迟过大意味着读到的可能是脏数据。缓存类中间件重点看命中率和内存碎片率。命中率骤降往往意味着缓存穿透或 key 设计有问题内存碎片率过高mem_fragmentation_ratio 1.5说明内存分配效率低该重启或扩容了。消息队列则盯积压量consumer_lag积压持续增长说明消费能力不足这条规则要结合业务高峰时段调整阈值。4.2 应用层错误率、延迟分位与探活应用层是症状驱动原则体现最明显的地方。错误率规则用rate(http_requests_total{status~5..}[5m]) / rate(http_requests_total[5m])超过 5% 持续 2 分钟报 P1。这里用 5 分钟窗口是因为错误率本身波动大窗口太短会误报太长反应迟钝。延迟告警一定要用分位数而不是平均值。平均值会被大量快请求拉低掩盖长尾问题。用histogram_quantile(0.99, ...)看 P99 延迟超过 SLA 的 1.5 倍报 P2。比如 SLA 是 200msP99 超过 300ms 就告警。探活用blackbox_exporter的probe_success等于 0 持续 1 分钟报 P1。这条规则看似简单但它是最后一道防线——前面所有指标都正常但服务实际不可达的情况并不少见探活能兜住。4.3 规则分组与评估间隔的调优所有规则写完后rule_files里的分组和evaluation_interval要调。我的经验是P1 规则单独一组评估间隔 15sP2/P3 规则另一组评估间隔 30s 或 60s。这样既保证关键告警的时效性又不让 Prometheus 评估压力过大。规则文件按层级拆成host.rules.yml、container.rules.yml、middleware.rules.yml、app.rules.yml每个文件内部再按groups细分方便后续维护和灰度调整。5. 常见问题与排查技巧实录5.1 告警不触发或延迟触发怎么查最常见的原因是for设得太长或者evaluation_interval和for不匹配。比如for: 10m但评估间隔是 1m理论上要 10 个评估点都满足才触发实际可能因为数据点缺失导致永远凑不齐。排查方法是去 Prometheus 的/alerts页面看规则状态State显示pending说明条件满足了但在等for显示inactive说明条件根本没满足这时候要检查表达式本身。另一个隐蔽原因是标签不匹配。告警规则的expr里用了某个标签做聚合但annotations里引用了不存在的标签会导致告警生成失败但不报错。养成习惯写完规则用promtool check rules校验一遍能提前发现语法和标签问题。5.2 误报太多怎么系统性收敛误报收敛不能靠一条条改阈值要有系统方法。我的做法分三步第一步把所有告警按触发频次排序找出 Top 10 噪音源第二步对每个噪音源判断是“阈值不合理”还是“规则设计错误”——前者调参后者重写第三步给高频但非紧急的告警降级或加长for观察一周再决定是否保留。有个具体技巧给告警加severity之外的confidence标签标记这条规则的“可信度”。新规则先标low跑两周看误报率稳定了再升high。路由配置里low的告警只发到低优先级渠道不打扰值班。5.3 常见问题速查表现象可能原因排查动作规则显示 inactive 但指标确实异常表达式标签过滤写错在 Prometheus 查询框单独跑 expr看返回结果告警反复触发又恢复for太短或阈值卡在临界值拉长for阈值留 5% 缓冲告警发了但没人收到Alertmanager 路由或静默配置问题检查 route 匹配规则和 silence 列表同一故障收到多条告警缺少告警聚合或 inhibit 规则配置inhibit_rules高级别抑制低级别规则评估报错函数用法错误或指标不存在promtool check rules 查指标是否存在避坑技巧inhibit_rules是减少告警风暴的利器。比如配置“主机宕机时抑制该主机上所有其他告警”一条up 0就能压住几十条衍生告警。但 inhibit 规则要写得精确匹配标签太宽会误抑制真正需要关注的告警。6. 模板落地后的维护与迭代规则模板不是写完就一劳永逸的。业务在变指标在变阈值也得跟着调。我一般建议每季度做一次告警回顾统计各规则的触发次数、误报率、平均响应时间把长期不触发的规则标记为“待观察”把误报率高的规则重写或下线。这套模板给的是起点真正的价值在于你根据自己环境调出来的那版——那才是最适合你的规则集。我在实际维护中体会最深的一点是告警规则的数量和监控成熟度不是正相关的。一个只有 30 条精准规则的体系比 300 条杂乱规则的体系有用得多。每次想加一条新规则前先问自己这条告警触发时我会做什么动作如果答不上来那这条规则大概率不该存在。