1. 告警设计的底层逻辑先搞清楚“告警是给谁看的”这些年我接过不少监控项目发现一个挺常见的现象很多人拿到 node_exporter 之后最先做的事情是打开 Grafana把 CPU、内存、磁盘面板一拉再照着网上抄几条告警规则然后就觉得监控大功告成了。结果跑了一两个星期告警群里天天夜里像过年一样热闹白天又没人愿意看最后大家默默把通知关掉监控沦为“事后考古工具”。问题不在 node_exporter也不在 Prometheus而在我们常常把“指标采集”和“告警治理”当成了一件事。实际上node_exporter 只负责把主机层面的运行数据暴露出来它能告诉你“现在内存用了多少”但它不会告诉你“这种情况要不要半夜喊人”。从指标到告警中间隔着一层非常关键的转译我们要把机器状态翻译成“需要人处理的事情”而且翻译得越精准告警系统的价值才越大。这也是我认为“告警的艺术”真正成立的原因。告警规则不是一个 if 判断更像是在写一本运维值班手册只不过这本手册的执行者是 Prometheus 和 Alertmanager。写得太粗漏报事故写得太细告警疲劳阈值拍脑袋误报满天飞。所以这篇文章会沿着“node_exporter 指标 - 告警规则 - Alertmanager 收敛通知”这条线把从指标到生产级规则之间容易踩的坑、值得保留的经验讲透。适合正在搭监控、被告警轰炸、或者想把告警规则从“能用”打磨成“好用”的工程师。在写第一条规则之前我建议你先过三个问题。第一个问题这个指标跌到或涨到什么程度意味着用户已经感受到不可用了第二个问题这种状态要持续多久才算故障瞬时尖峰要不要过滤掉第三个问题一旦触发谁来处理处理动作是什么这三个问题想不清楚PromQL 写得再漂亮发出去的也只是噪音。所以你会发现真正专业的告警设计第一步永远是“定义故障”而不是“写表达式”。CPU 使用率 90% 是不是故障不一定。如果业务是离线批量计算高负载反而说明资源用上了如果业务是低延迟在线接口CPU 90% 持续十分钟可能已经把尾延时拖垮了。同一套指标在不同业务下会得出完全相反的结论。这就是我为什么说告警规则的表达只是最后一步前期的语义设计才是灵魂。2. node_exporter 指标选型哪些指标值得做成告警2.1 CPU用 idle 指标反推使用率别把 counter 当 gauge 用CPU 是大家最熟悉也最容易写错的指标。node_exporter 暴露的node_cpu_seconds_total是一个 counter也就是“从开机累计到现在每种 mode 下 CPU 跑了多少秒”。因为是累计值直接拿来用没有意义必须配合 rate 或 irate 看增量。新手常犯的错误是直接写node_cpu_seconds_total{modeuser} 80这种规则基本不会立刻生效因为累计值总是在增长只有长时间不增长才说明 CPU 停摆了。正确处理是先算“非空闲率”也就是用总的 CPU 时间减去 idle 时间再除以总时间。我更推荐用 idle 反推因为 idle 是一个明确且稳定的 mode语义不会受 iowait、steal 这些分类变化影响100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这条表达式计算的是过去 5 分钟内每个实例的平均 CPU 使用率。窗口用 5 分钟而不是 1 分钟是为了让告警看得更稳。irate虽然对瞬时尖峰更敏感但在告警规则里我基本不用因为它对短时间窗口内的采样抖动太敏感很容易造成“几分钟前一切正常突然告警又自己恢复”的怪异现象。irate 适合放在 Grafana 面板上看毛刺告警规则更适合用 rate。CPU 告警还有一个指标可以参考负载。node_load1本身是个 gauge反映的是系统运行队列长度但它没有“多少算高”的绝对标准。负载 30 在一台 64 核机器上可能算很空闲在 4 核机器上已经要命了。所以如果要对负载做告警必须以 CPU 核数作为参照物node_load1 on(instance) count by(instance) (node_cpu_seconds_total{modeidle}) * 0.7这条规则表达的意思是1 分钟平均负载超过机器核数的 70% 才告警。不过负载是瞬时值建议再加一个较长的 for避免正在编译、正在处理突发流量时误报。2.2 内存MemAvailable 比 MemFree 可靠得多内存使用率几乎是每个监控系统都要做的规则但很多规则从一开始就选错了数据源。node_memory_MemFree_bytes这个指标在 Linux 下只代表“完全没人用的物理内存”。现在的服务器上系统为了提升性能会把大量空闲内存用在 page cache 上这部分内存在 MemFree 里看不到但真到业务需要时内核可以立刻回收。如果直接用 MemFree 算内存使用率很多正常运行的服务会长期显示“内存 90% 以上”然后不停触发告警。正确做法是用node_memory_MemAvailable_bytes。这是内核根据当前内存压力、可回收缓存、swap 情况综合估算出来的“可用内存”更接近业务真实感受。推荐的内存使用率计算是(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100这条表达式的语义是可用内存越少、使用率越高。但要注意MemAvailable 只是估算值不代表系统一定马上出问题。如果内存使用率持续高位而且 swap 用量同步上涨那才是真正的压力信号。如果只是可用内存低但 swap 一直没用通常是 page cache 占了大量内存业务运行未必受影响。如果负责的是高负载场景我还会额外关注node_pressure_memory相关的指标。PSI 指标能直接反映内存资源在系统层面的 stall 时间当node_pressure_memory_waiting_seconds_total快速上涨时说明任务真的在等内存了这比单看使用率更能说明“内存不够用”。2.3 磁盘先过滤掉伪文件系统再谈使用率和空间预测磁盘告警是误报重灾区原因不是阈值难定而是很多人的告警表达式把不该监控的东西也纳进来了。node_exporter 默认会采集所有挂载点的文件系统信息其中包含 tmpfs、overlay、squashfs、loop 设备等。容器环境下尤其明显如果你直接写(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 90大概率会在 /dev/shm、/run 这类 tmpfs 上持续告警。因为这些伪文件系统吃的是内存重启就清空使用率波动极大没有长期容量管理的意义。做磁盘告警前第一步必须过滤node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs, mountpoint!~^/(run|sys|proc|dev)/.*}过滤之后再按设备做一个通用规则(1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs} / node_filesystem_size_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}) * 100 90磁盘空间只做使用率阈值还不够。运维过程中最难受的不是空间已经满了而是分区眼看着一小时一小时往下掉你不知道它什么时候会满。PromQL 提供了一个叫predict_linear的函数可以基于过去 6 小时的变化趋势预测 4 小时后剩余空间是否归零predict_linear(node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}[6h], 4 * 3600) 0这个规则能在磁盘还没满之前就告诉你“按当前增速4 小时内会写满”。不过我自己的经验是这类预测规则要特别小心日志切割、临时文件清理、大文件被删都会显著影响预测结果误报率比普通阈值要高。想减少误报可以把拟合窗口拉长到 6 到 12 小时同时给规则加一个for: 30m让趋势连续一段时间再触发。inode 耗尽也值得单独建一条规则。很多工程师对磁盘空间敏感却忘了 inode 一旦耗尽即使空间还剩很多文件也创建不出来。规则可以写成node_filesystem_files_free{fstype!~tmpfs|overlay|squashfs|ramfs} / node_filesystem_files{fstype!~tmpfs|overlay|squashfs|ramfs} * 100 102.4 时钟同步与 systemd两个很容易漏掉的生产级指标主机层告警通常被大家盯得最多的是 CPU、内存、磁盘但真正在生产环境里闯祸的往往是时钟漂移和服务异常退出。node_exporter 暴露了node_time_seconds它反映的是主机当前系统时间单位是 Unix 时间戳。如果主机时钟发生漂移最直接的影响是日志时间错乱、认证票据失败、分布式系统节点间通信异常。在 PromQL 里有一个函数time()返回的是 Prometheus 服务器当前时间拿两者做差就能判断主机时间是否偏差过大abs(node_time_seconds - time()) 2我在实际中见过把阈值设成 0.5 秒的结果一有 NTP 校时就触发非常烦人。生产经验建议阈值设在 2 到 3 秒之间并且for: 1m既不会漏掉严重的时钟偏移也不会被正常的校时抖动干扰。需要注意如果 Prometheus 服务器自己的时钟都不准这个规则就失去意义了所以监控服务器本身也要有稳定的时间同步。另一个容易漏的是 systemd 服务的异常状态。node_exporter 的 systemd collector 会把每个 unit 的当前状态暴露出来对一个 production 主机来说最值得关注的是 failed 状态node_systemd_unit_state{statefailed} 1如果你的主机上跑了很多无关服务建议用 name 标签把核心服务过滤出来避免一个无关紧要的定时任务失败也拉高 noise。实际配置时要注意事件里报 failed 只是“当时那一刻的状态”,如果系统配置了 Restartalways服务可能很快被拉起failed 状态很快消失。所以建议for设在 1 分钟左右确认它不是瞬时抖动。2.5 文件描述符和网络错包不常发生但发生就是事故文件描述符耗尽是个低频但致命的问题。当进程频繁创建 socket、打开文件却没有正常释放时fd 会持续增长一旦撞上系统上限新连接直接失败业务表现看起来像“假死”。node_exporter 有现成的指标node_filefd_allocated / node_filefd_maximum 0.8这个规则可以设为 severity: warning因为 80% 到 100% 之间留出了操作余地。真正到了 100%再强的告警也救不回来最好早一点介入查文件句柄泄漏。网络层面的指标我建议不要对所有错误都做告警因为网络环境里 transient error 太多了。比较有参考价值的是node_network_receive_errs_total和node_network_transmit_errs_total它们分别表示收包和发包的错误计数。如果这两个 counter 在某段时间内持续增加大概率是网卡或者链路出现了实质问题。用 rate 看增量rate(node_network_receive_errs_total[5m]) 0需要注意的是物理机上的多队列网卡、bond 接口、虚拟化环境里的 veth接口名千奇百怪一定要先通过已有的监控面板看清楚哪些接口长期存在稳定流量再决定要不要对所有接口统一做规则。否则 veth 接口偶发丢几个包也足以让你的告警群热闹起来。3. 生产级告警规则怎么落地阈值、PromQL 和 for 的组合设计3.1 设置阈值前先想清楚容量模型到真正写规则的时候很多人第一个问题就是“阈值定多少合适”。但我建议先想一下你监控的对象是“利用率”还是“饱和度”。利用率回答的是“资源用了多少”比如 CPU 用了 80%、内存用了 85%这只能说明占用情况。饱和度回答的是“资源是否已经排不上队”比如 CPU run queue 很长、内存开始 swap、磁盘 IO 等待时间飙升。生产级告警真正关心的往往是饱和度而不是利用率。利用率高并不代表系统要出问题饱和度起来了用户的感受才会明显劣化。所以阈值的设定不能凭空拍。比如云服务器CPU 使用率定 85% 还是 90%取决于你对自己的业务峰值有没有认知。最好的办法是先通过 node_exporter Grafana 积累至少一两个星期的基线数据看看正常业务高峰时这几个指标大概在什么水位然后在“高于正常水位 15% 到 20%”的位置设置告警线。没有基线的阈值都是盲猜猜错了只会带来更多的告警疲劳。另外还有个容易犯的错误把使用率阈值设得过于接近 100%。比如磁盘使用率到 99% 才告警看起来能最大化利用空间但留给运维的反应窗口几乎为零。磁盘写满不是瞬间发生的通常有一个缓慢增长的过程这就是为什么前文提到使用率阈值和趋势预测要配合使用。3.2 一套可以直接参考的 Prometheus 规则示例下面给出一套比较通用的告警规则覆盖主机 CPU、内存、磁盘、时钟、systemd 服务和文件描述符。这套规则不是让你直接照搬而是提供一个参考骨架实际布到生产环境时阈值和过滤条件都要结合自己的容量模型调整。groups: - name: node-host-rules rules: - alert: HostHighCpuLoad expr: | 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} CPU 使用率过高 description: {{ $labels.instance }} CPU 使用率已超过 85%持续 10 分钟当前值 {{ $value }}% - alert: HostHighMemoryUsage expr: | (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 92 for: 5m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 内存使用率过高 description: {{ $labels.instance }} 内存可用率已低于 8%持续 5 分钟 - alert: HostDiskWillFillIn4Hours expr: | predict_linear(node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}[6h], 4 * 3600) 0 for: 30m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 磁盘将在 4 小时内写满 description: 挂载点 {{ $labels.mountpoint }} 按当前增长速度预计 4 小时内空间耗尽 - alert: HostClockSkewDetected expr: | abs(node_time_seconds - time()) 2 for: 1m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 系统时间偏差超过 2 秒 description: 实例当前时间与监控服务器时间差超过 2 秒请检查 NTP 同步状态 - alert: HostSystemdUnitFailed expr: | node_systemd_unit_state{statefailed} 1 for: 1m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 的 systemd 单元进入 failed 状态 description: 单元 {{ $labels.name }} 已经处于 failed 状态请立即检查 - alert: HostFileDescriptorExhausting expr: | node_filefd_allocated / node_filefd_maximum 0.8 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 文件描述符使用率超过 80% description: 当前分配文件描述符占上限的 80% 以上持续 10 分钟这套规则里CPU 告警我加了 10 分钟的 for是为了避开短时间内的编译、备份等高 CPU 任务。内存使用率的 for 设成 5 分钟因为内存水位一旦异常影响是持续的不需要等太久。时钟偏移的 for 只有 1 分钟因为时间偏差如果持续存在越早发现越好。systemd unit failed 的 for 也是 1 分钟但前提是服务本身不是 instant restart 的需要根据你的业务调。3.3 for 到底该怎么填把瞬时毛刺过滤掉Prometheus 告警规则里的for字段定义了“表达式持续成立多久之后才真正触发告警”。这个字段是生产级规则和玩具规则最大的分水岭。如果你把 for 设成 0 或者不写那任何一次 scrape 周期的瞬时抖动都可能触发告警最终结果就是告警群被各种“幽灵消息”刷屏。for 的设计原则是评估间隔越短、数据抖动越大for 就要越长。Prometheus 的默认evaluation_interval一般是 15 秒到 1 分钟一条规则要至少持续 2 到 3 个评估周期才进入 pending 状态并有意义。实际建议是水位型告警比如 CPU 使用率、内存使用率for 设在 5 到 15 分钟之间状态型告警比如服务 failed、实例 downfor 设在 1 到 2 分钟即可趋势预测型告警比如磁盘将满for 建议设在 10 到 30 分钟因为趋势预测本身基于回归算法容易受单次异常采样影响。我还想分享一个经验不要在 for 上追求“绝对实时”。很多刚搭监控的朋友希望告警延迟越小越好于是把所有 for 都设成 10 秒。但监控告警不是业务接口不需要毫秒级响应恰恰相反适当的延迟能过滤掉绝大多数自愈型抖动。毕竟很多瞬时故障在你看到告警之前系统已经自己恢复了这种消息对值班同学没有任何价值。3.4 labels 和 annotations 要写成“拿来就能干活”的样子告警规则里的 labels 和 annotations 经常被忽略但它们直接影响处置效率。labels 里至少要包含 severity 等级方便 Alertmanager 做路由和抑制annotation 里的 summary 和 description 要写清楚“哪台机器、什么问题、持续多久、当前值多少”。我见过不少规则里只写一句“CPU 告警”点开详情才看到 instance。这种告警到了凌晨值班同学还得再登录 Prometheus 查半天才知道是哪台机器非常低效。正确做法是充分利用 Prometheus 的模板语法把实例标签、挂载点、当前值全部塞进描述里。上一个小节的 YAML 里已经用到{{ $labels.instance }}、{{ $labels.mountpoint }}和{{ $value }}这些模板在告警触发时会自动替换成实际值。不要把告警描述写成一段只给机器看的技术日志。它最终是被值班的人、甚至是不熟悉基础架构的应用负责人看到的。描述里应该有大白话一样的信息哪里出了问题、严重程度如何、目前指标是多少。如果要处理也尽量在 description 里给出第一步检查方向。这条经验可以显著降低 MTTR也少挨很多“这告警到底啥意思”的抱怨。4. Alertmanager 收敛配置让告警从轰炸变成对话4.1 路由规划不同团队只收到自己的告警Prometheus 负责判断“有没有问题”Alertmanager 负责决定“这个问题通知谁、怎么通知”。业务规模一旦上来所有告警都发到一个群、一个 receiver等于没做告警管理。我比较推荐按团队和按服务拆路由。主机层的告警可以统一进基础设施群数据库相关规则单独路由给 DBA 群业务应用层的告警路由给对应业务研发群。在路由上推荐用告警里的自定义 label 来区分比如给不同告警打上team: infra、team: db、team: pay然后 Alertmanager 依据这些 label 做分发。route: receiver: default-webhook group_by: - alertname - instance group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: - teamdb receiver: db-webhook - matchers: - severitycritical receiver: oncall-webhook这段配置的意思是普通告警进默认的 webhook匹配到 teamdb 的进数据库 webhookcritical 等级的进值班电话/更高优通知。路由顺序很重要Alertmanager 会从上到下匹配所以更具体的规则要放在前面。4.2 分组和抑制同一台机器别同一时间轰炸好几种声音Alertmanager 的分组机制解决的是“同一时间段内同类告警合并成一条通知”的问题。比如一台机器有多个挂载点同时磁盘将满如果不分组会一次弹五六条消息这其实是同一次故障应该合并成一条通知里面列出所有受影响的挂载点。group_by配置里建议把告警名、实例、严重程度放进去。比如group_by: [alertname, instance]同一台机器的同一个告警会聚合为一条。有些场景你还想按集群聚合比如整个集群都存在时钟偏差那把cluster也加进来。但要注意group_by 的维度越多通知聚合度越低维度越少通知越少但详情可能不够明确。实践中最常用的是alertname加instance既避免刷屏又能定位到机器。抑制规则也很重要。很多告警之间是因果关系比如一台机器因为 CPU 100% 触发了高负载告警同时它的服务健康检查也挂了。如果 service down 已经是 critical那后面出来的 CPU warning 就不必再打扰人了。Alertmanager 的 inhibit_rules 可以做到“高等级告警压制低等级相关告警”inhibit_rules: - source_matchers: - severitycritical target_matchers: - severitywarning equal: - instance这段配置的含义是同一台 instance 上如果已经存在 critical 告警那么所有 warning 告警都会被抑制。实战中这个规则可以大幅减少告警风暴但要小心不要在跨 instance 的场景乱用 equal否则容易把本应送达的告警也吞掉。4.3 静默与维护窗口发版和重启时给告警一个“免打扰开关”生产环境经常有主动变更行为发版、扩容、重启、换硬件。这些操作必然会导致某些指标短期异常这时候最好的办法不是关监控而是给 Alertmanager 设置一个静默时间。Alertmanager 提供 silence 机制你可以在 UI 上或通过 API 创建一条基于标签匹配的静默规则比如匹配某个 instance、持续 30 分钟。这样维护期间系统不会因为你的主动操作产生误报。我建议把静默流程做成公司内部的标准操作任何同学要重启机器先到 Alertmanager 创建静默再执行操作操作结束后主动删除静默。这里有个小坑silence 是一次性配置和常规告警规则一样也需要维护。如果团队里很多人习惯“重启个服务就静默半小时”静默到期却忘了删那这段时间里的真实故障也会被屏蔽。更好的方案是让发版系统自动创建静默并在流水线结束时自动删除静默避免人为遗忘。4.4 通知内容的可读性同一个告警不同的写法不同的处置效率Alertmanager 最终把告警发到钉钉、企微或 Slack靠的是 notch 模板。很多团队的模板非常简单只输出告警名和标签消息里全是[Firing]、instance10.0.0.1:9100这样的原始数据。对于不熟悉 Prometheus 的业务同学来说这种消息几乎没有可读性。建议在模板里做几件事把 instance 的端口去掉只保留 IP把主机 IP 转成可读的主机名把标签中的关键信息汇总成一句人话。比如模板里可以写{{ range .Alerts }} {{ .Labels.alertname }} on {{ .Labels.instance }} {{ .Annotations.summary }} {{ .Annotations.description }} {{ end }}另一个容易被忽略的点是严重程度标识。因为不同接收方可能只关注某一种 severity建议在通知标题里先写[Critical]或[Warning]这样值班同学扫一眼通知列表就能决定优先级。通知平台最终是人看的多花一点时间打磨可读性远比多写十条规则更能提升告警系统的效率。5. 常见问题与避坑实录从误报到漏报的排查思路5.1 主机重启为什么带来一堆“幽灵告警”我见过最典型的一个场景某台 node_exporter 因为系统重启失联了几分钟等它恢复之后CPU、内存、磁盘、systemd 一下子进来了四五条告警弄得值班同学以为出了大事。实际上只是机器重启了服务正在慢慢拉起。原因在于 Prometheus 在抓取中断期间会产生数据空洞重启完成后 counter 重新开始计数。如果你用的是 rate 类表达式短时间窗口内自然会计算出异常高的增量。针对这类情况要做两件事第一instance 自身的失联要用up 0或absent规则单独管理别依赖其他指标间接表示第二给水位类告警设置足够长的 for给系统恢复留时间比如 CPU、内存告警最少for: 5m。我甚至见过有人把磁盘告警也设成 for 0结果重启后伪文件系统未完全挂载期间疯狂触发最后不得已把规则删了重写这都属于经验不足的代价。5.2 内存告警一直响业务却毫无影响内存使用率一直接近 95%但页面响应时间一切正常这种告警是不是误报要分两种情况看。一种是没有过滤掉 page cache内存使用率看着高内核随时可以回收这部分缓存给业务用这属于表达式选错指标应该回到 MemAvailable 方案。另一种是 MemAvailable 确实很低但业务负载还撑得住这时候只靠内存水位很难判断严重程度需要辅以 swap 使用量、PSI 压力指标一起看。如果 swap 使用量长期不涨说明内核还有余力压缩和回收缓存一旦node_pressure_memory_waiting_seconds_total开始明显上涨那就说明真的有人在等内存了。我自己的处理建议是内存 use 告警定位为 warning把 swap 和 PSI 指标告警作为 critical 的判定依据。这两条一起看才不会在正常服务上反复收到“内存爆了”的消息。5.3 磁盘告警反复出现多半是过滤条件没写全前文已经提过磁盘告警必须先排除伪文件系统但实际生产环境远比想象中复杂。有人过滤了 tmpfs 和 overlay却忘了过滤squashfs于是在某些容器镜像层上出现使用率 100%有人过滤了文件系统类型却忘了过滤/boot这种长期不动的分区还有人把mountpoint过滤条件写成了精确匹配导致/data和/data2被漏掉。最稳妥的做法是先在 Grafana 里把所有node_filesystem_size_bytes序列拉出来看清当前主机上究竟有哪些文件系统再决定哪些需要纳入监控。过滤是一种减法你在生产环境用的采集指标越宽过滤器就越要写得严谨。完整的过滤正则最好统一维护成一个模板常量放在所有磁盘规则的 expr 里不要每个规则各自写一套否则后期维护会非常痛苦。5.4 for 时长到底应该怎么分布我的 5/10/30 分钟规律for 时长虽然需要根据场景调整但我个人在实践中总结了一套相对通用的规律状态类告警 1 到 2 分钟水位类告警 5 到 10 分钟趋势预测类告警 15 到 30 分钟。为什么差异这么大因为它们的语义完全不同。状态类告警说明某件事已经发生了比如服务进 failed、主机失联这类告警不需要等太久等太久反而错过处置窗口。水位类告警只是“资源用量比较高”可能持续一段时间后自动回落给 5 到 10 分钟是为了过滤业务高峰。趋势预测类告警本来就是在预测未来单次抖动对回归结果的影响不可忽视拉长 for 能显著减少
从node_exporter到生产级告警：Prometheus告警规则设计与避坑实践
1. 告警设计的底层逻辑先搞清楚“告警是给谁看的”这些年我接过不少监控项目发现一个挺常见的现象很多人拿到 node_exporter 之后最先做的事情是打开 Grafana把 CPU、内存、磁盘面板一拉再照着网上抄几条告警规则然后就觉得监控大功告成了。结果跑了一两个星期告警群里天天夜里像过年一样热闹白天又没人愿意看最后大家默默把通知关掉监控沦为“事后考古工具”。问题不在 node_exporter也不在 Prometheus而在我们常常把“指标采集”和“告警治理”当成了一件事。实际上node_exporter 只负责把主机层面的运行数据暴露出来它能告诉你“现在内存用了多少”但它不会告诉你“这种情况要不要半夜喊人”。从指标到告警中间隔着一层非常关键的转译我们要把机器状态翻译成“需要人处理的事情”而且翻译得越精准告警系统的价值才越大。这也是我认为“告警的艺术”真正成立的原因。告警规则不是一个 if 判断更像是在写一本运维值班手册只不过这本手册的执行者是 Prometheus 和 Alertmanager。写得太粗漏报事故写得太细告警疲劳阈值拍脑袋误报满天飞。所以这篇文章会沿着“node_exporter 指标 - 告警规则 - Alertmanager 收敛通知”这条线把从指标到生产级规则之间容易踩的坑、值得保留的经验讲透。适合正在搭监控、被告警轰炸、或者想把告警规则从“能用”打磨成“好用”的工程师。在写第一条规则之前我建议你先过三个问题。第一个问题这个指标跌到或涨到什么程度意味着用户已经感受到不可用了第二个问题这种状态要持续多久才算故障瞬时尖峰要不要过滤掉第三个问题一旦触发谁来处理处理动作是什么这三个问题想不清楚PromQL 写得再漂亮发出去的也只是噪音。所以你会发现真正专业的告警设计第一步永远是“定义故障”而不是“写表达式”。CPU 使用率 90% 是不是故障不一定。如果业务是离线批量计算高负载反而说明资源用上了如果业务是低延迟在线接口CPU 90% 持续十分钟可能已经把尾延时拖垮了。同一套指标在不同业务下会得出完全相反的结论。这就是我为什么说告警规则的表达只是最后一步前期的语义设计才是灵魂。2. node_exporter 指标选型哪些指标值得做成告警2.1 CPU用 idle 指标反推使用率别把 counter 当 gauge 用CPU 是大家最熟悉也最容易写错的指标。node_exporter 暴露的node_cpu_seconds_total是一个 counter也就是“从开机累计到现在每种 mode 下 CPU 跑了多少秒”。因为是累计值直接拿来用没有意义必须配合 rate 或 irate 看增量。新手常犯的错误是直接写node_cpu_seconds_total{modeuser} 80这种规则基本不会立刻生效因为累计值总是在增长只有长时间不增长才说明 CPU 停摆了。正确处理是先算“非空闲率”也就是用总的 CPU 时间减去 idle 时间再除以总时间。我更推荐用 idle 反推因为 idle 是一个明确且稳定的 mode语义不会受 iowait、steal 这些分类变化影响100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这条表达式计算的是过去 5 分钟内每个实例的平均 CPU 使用率。窗口用 5 分钟而不是 1 分钟是为了让告警看得更稳。irate虽然对瞬时尖峰更敏感但在告警规则里我基本不用因为它对短时间窗口内的采样抖动太敏感很容易造成“几分钟前一切正常突然告警又自己恢复”的怪异现象。irate 适合放在 Grafana 面板上看毛刺告警规则更适合用 rate。CPU 告警还有一个指标可以参考负载。node_load1本身是个 gauge反映的是系统运行队列长度但它没有“多少算高”的绝对标准。负载 30 在一台 64 核机器上可能算很空闲在 4 核机器上已经要命了。所以如果要对负载做告警必须以 CPU 核数作为参照物node_load1 on(instance) count by(instance) (node_cpu_seconds_total{modeidle}) * 0.7这条规则表达的意思是1 分钟平均负载超过机器核数的 70% 才告警。不过负载是瞬时值建议再加一个较长的 for避免正在编译、正在处理突发流量时误报。2.2 内存MemAvailable 比 MemFree 可靠得多内存使用率几乎是每个监控系统都要做的规则但很多规则从一开始就选错了数据源。node_memory_MemFree_bytes这个指标在 Linux 下只代表“完全没人用的物理内存”。现在的服务器上系统为了提升性能会把大量空闲内存用在 page cache 上这部分内存在 MemFree 里看不到但真到业务需要时内核可以立刻回收。如果直接用 MemFree 算内存使用率很多正常运行的服务会长期显示“内存 90% 以上”然后不停触发告警。正确做法是用node_memory_MemAvailable_bytes。这是内核根据当前内存压力、可回收缓存、swap 情况综合估算出来的“可用内存”更接近业务真实感受。推荐的内存使用率计算是(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100这条表达式的语义是可用内存越少、使用率越高。但要注意MemAvailable 只是估算值不代表系统一定马上出问题。如果内存使用率持续高位而且 swap 用量同步上涨那才是真正的压力信号。如果只是可用内存低但 swap 一直没用通常是 page cache 占了大量内存业务运行未必受影响。如果负责的是高负载场景我还会额外关注node_pressure_memory相关的指标。PSI 指标能直接反映内存资源在系统层面的 stall 时间当node_pressure_memory_waiting_seconds_total快速上涨时说明任务真的在等内存了这比单看使用率更能说明“内存不够用”。2.3 磁盘先过滤掉伪文件系统再谈使用率和空间预测磁盘告警是误报重灾区原因不是阈值难定而是很多人的告警表达式把不该监控的东西也纳进来了。node_exporter 默认会采集所有挂载点的文件系统信息其中包含 tmpfs、overlay、squashfs、loop 设备等。容器环境下尤其明显如果你直接写(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 90大概率会在 /dev/shm、/run 这类 tmpfs 上持续告警。因为这些伪文件系统吃的是内存重启就清空使用率波动极大没有长期容量管理的意义。做磁盘告警前第一步必须过滤node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs, mountpoint!~^/(run|sys|proc|dev)/.*}过滤之后再按设备做一个通用规则(1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs} / node_filesystem_size_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}) * 100 90磁盘空间只做使用率阈值还不够。运维过程中最难受的不是空间已经满了而是分区眼看着一小时一小时往下掉你不知道它什么时候会满。PromQL 提供了一个叫predict_linear的函数可以基于过去 6 小时的变化趋势预测 4 小时后剩余空间是否归零predict_linear(node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}[6h], 4 * 3600) 0这个规则能在磁盘还没满之前就告诉你“按当前增速4 小时内会写满”。不过我自己的经验是这类预测规则要特别小心日志切割、临时文件清理、大文件被删都会显著影响预测结果误报率比普通阈值要高。想减少误报可以把拟合窗口拉长到 6 到 12 小时同时给规则加一个for: 30m让趋势连续一段时间再触发。inode 耗尽也值得单独建一条规则。很多工程师对磁盘空间敏感却忘了 inode 一旦耗尽即使空间还剩很多文件也创建不出来。规则可以写成node_filesystem_files_free{fstype!~tmpfs|overlay|squashfs|ramfs} / node_filesystem_files{fstype!~tmpfs|overlay|squashfs|ramfs} * 100 102.4 时钟同步与 systemd两个很容易漏掉的生产级指标主机层告警通常被大家盯得最多的是 CPU、内存、磁盘但真正在生产环境里闯祸的往往是时钟漂移和服务异常退出。node_exporter 暴露了node_time_seconds它反映的是主机当前系统时间单位是 Unix 时间戳。如果主机时钟发生漂移最直接的影响是日志时间错乱、认证票据失败、分布式系统节点间通信异常。在 PromQL 里有一个函数time()返回的是 Prometheus 服务器当前时间拿两者做差就能判断主机时间是否偏差过大abs(node_time_seconds - time()) 2我在实际中见过把阈值设成 0.5 秒的结果一有 NTP 校时就触发非常烦人。生产经验建议阈值设在 2 到 3 秒之间并且for: 1m既不会漏掉严重的时钟偏移也不会被正常的校时抖动干扰。需要注意如果 Prometheus 服务器自己的时钟都不准这个规则就失去意义了所以监控服务器本身也要有稳定的时间同步。另一个容易漏的是 systemd 服务的异常状态。node_exporter 的 systemd collector 会把每个 unit 的当前状态暴露出来对一个 production 主机来说最值得关注的是 failed 状态node_systemd_unit_state{statefailed} 1如果你的主机上跑了很多无关服务建议用 name 标签把核心服务过滤出来避免一个无关紧要的定时任务失败也拉高 noise。实际配置时要注意事件里报 failed 只是“当时那一刻的状态”,如果系统配置了 Restartalways服务可能很快被拉起failed 状态很快消失。所以建议for设在 1 分钟左右确认它不是瞬时抖动。2.5 文件描述符和网络错包不常发生但发生就是事故文件描述符耗尽是个低频但致命的问题。当进程频繁创建 socket、打开文件却没有正常释放时fd 会持续增长一旦撞上系统上限新连接直接失败业务表现看起来像“假死”。node_exporter 有现成的指标node_filefd_allocated / node_filefd_maximum 0.8这个规则可以设为 severity: warning因为 80% 到 100% 之间留出了操作余地。真正到了 100%再强的告警也救不回来最好早一点介入查文件句柄泄漏。网络层面的指标我建议不要对所有错误都做告警因为网络环境里 transient error 太多了。比较有参考价值的是node_network_receive_errs_total和node_network_transmit_errs_total它们分别表示收包和发包的错误计数。如果这两个 counter 在某段时间内持续增加大概率是网卡或者链路出现了实质问题。用 rate 看增量rate(node_network_receive_errs_total[5m]) 0需要注意的是物理机上的多队列网卡、bond 接口、虚拟化环境里的 veth接口名千奇百怪一定要先通过已有的监控面板看清楚哪些接口长期存在稳定流量再决定要不要对所有接口统一做规则。否则 veth 接口偶发丢几个包也足以让你的告警群热闹起来。3. 生产级告警规则怎么落地阈值、PromQL 和 for 的组合设计3.1 设置阈值前先想清楚容量模型到真正写规则的时候很多人第一个问题就是“阈值定多少合适”。但我建议先想一下你监控的对象是“利用率”还是“饱和度”。利用率回答的是“资源用了多少”比如 CPU 用了 80%、内存用了 85%这只能说明占用情况。饱和度回答的是“资源是否已经排不上队”比如 CPU run queue 很长、内存开始 swap、磁盘 IO 等待时间飙升。生产级告警真正关心的往往是饱和度而不是利用率。利用率高并不代表系统要出问题饱和度起来了用户的感受才会明显劣化。所以阈值的设定不能凭空拍。比如云服务器CPU 使用率定 85% 还是 90%取决于你对自己的业务峰值有没有认知。最好的办法是先通过 node_exporter Grafana 积累至少一两个星期的基线数据看看正常业务高峰时这几个指标大概在什么水位然后在“高于正常水位 15% 到 20%”的位置设置告警线。没有基线的阈值都是盲猜猜错了只会带来更多的告警疲劳。另外还有个容易犯的错误把使用率阈值设得过于接近 100%。比如磁盘使用率到 99% 才告警看起来能最大化利用空间但留给运维的反应窗口几乎为零。磁盘写满不是瞬间发生的通常有一个缓慢增长的过程这就是为什么前文提到使用率阈值和趋势预测要配合使用。3.2 一套可以直接参考的 Prometheus 规则示例下面给出一套比较通用的告警规则覆盖主机 CPU、内存、磁盘、时钟、systemd 服务和文件描述符。这套规则不是让你直接照搬而是提供一个参考骨架实际布到生产环境时阈值和过滤条件都要结合自己的容量模型调整。groups: - name: node-host-rules rules: - alert: HostHighCpuLoad expr: | 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} CPU 使用率过高 description: {{ $labels.instance }} CPU 使用率已超过 85%持续 10 分钟当前值 {{ $value }}% - alert: HostHighMemoryUsage expr: | (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 92 for: 5m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 内存使用率过高 description: {{ $labels.instance }} 内存可用率已低于 8%持续 5 分钟 - alert: HostDiskWillFillIn4Hours expr: | predict_linear(node_filesystem_avail_bytes{fstype!~tmpfs|overlay|squashfs|ramfs}[6h], 4 * 3600) 0 for: 30m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 磁盘将在 4 小时内写满 description: 挂载点 {{ $labels.mountpoint }} 按当前增长速度预计 4 小时内空间耗尽 - alert: HostClockSkewDetected expr: | abs(node_time_seconds - time()) 2 for: 1m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 系统时间偏差超过 2 秒 description: 实例当前时间与监控服务器时间差超过 2 秒请检查 NTP 同步状态 - alert: HostSystemdUnitFailed expr: | node_systemd_unit_state{statefailed} 1 for: 1m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} 的 systemd 单元进入 failed 状态 description: 单元 {{ $labels.name }} 已经处于 failed 状态请立即检查 - alert: HostFileDescriptorExhausting expr: | node_filefd_allocated / node_filefd_maximum 0.8 for: 10m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 文件描述符使用率超过 80% description: 当前分配文件描述符占上限的 80% 以上持续 10 分钟这套规则里CPU 告警我加了 10 分钟的 for是为了避开短时间内的编译、备份等高 CPU 任务。内存使用率的 for 设成 5 分钟因为内存水位一旦异常影响是持续的不需要等太久。时钟偏移的 for 只有 1 分钟因为时间偏差如果持续存在越早发现越好。systemd unit failed 的 for 也是 1 分钟但前提是服务本身不是 instant restart 的需要根据你的业务调。3.3 for 到底该怎么填把瞬时毛刺过滤掉Prometheus 告警规则里的for字段定义了“表达式持续成立多久之后才真正触发告警”。这个字段是生产级规则和玩具规则最大的分水岭。如果你把 for 设成 0 或者不写那任何一次 scrape 周期的瞬时抖动都可能触发告警最终结果就是告警群被各种“幽灵消息”刷屏。for 的设计原则是评估间隔越短、数据抖动越大for 就要越长。Prometheus 的默认evaluation_interval一般是 15 秒到 1 分钟一条规则要至少持续 2 到 3 个评估周期才进入 pending 状态并有意义。实际建议是水位型告警比如 CPU 使用率、内存使用率for 设在 5 到 15 分钟之间状态型告警比如服务 failed、实例 downfor 设在 1 到 2 分钟即可趋势预测型告警比如磁盘将满for 建议设在 10 到 30 分钟因为趋势预测本身基于回归算法容易受单次异常采样影响。我还想分享一个经验不要在 for 上追求“绝对实时”。很多刚搭监控的朋友希望告警延迟越小越好于是把所有 for 都设成 10 秒。但监控告警不是业务接口不需要毫秒级响应恰恰相反适当的延迟能过滤掉绝大多数自愈型抖动。毕竟很多瞬时故障在你看到告警之前系统已经自己恢复了这种消息对值班同学没有任何价值。3.4 labels 和 annotations 要写成“拿来就能干活”的样子告警规则里的 labels 和 annotations 经常被忽略但它们直接影响处置效率。labels 里至少要包含 severity 等级方便 Alertmanager 做路由和抑制annotation 里的 summary 和 description 要写清楚“哪台机器、什么问题、持续多久、当前值多少”。我见过不少规则里只写一句“CPU 告警”点开详情才看到 instance。这种告警到了凌晨值班同学还得再登录 Prometheus 查半天才知道是哪台机器非常低效。正确做法是充分利用 Prometheus 的模板语法把实例标签、挂载点、当前值全部塞进描述里。上一个小节的 YAML 里已经用到{{ $labels.instance }}、{{ $labels.mountpoint }}和{{ $value }}这些模板在告警触发时会自动替换成实际值。不要把告警描述写成一段只给机器看的技术日志。它最终是被值班的人、甚至是不熟悉基础架构的应用负责人看到的。描述里应该有大白话一样的信息哪里出了问题、严重程度如何、目前指标是多少。如果要处理也尽量在 description 里给出第一步检查方向。这条经验可以显著降低 MTTR也少挨很多“这告警到底啥意思”的抱怨。4. Alertmanager 收敛配置让告警从轰炸变成对话4.1 路由规划不同团队只收到自己的告警Prometheus 负责判断“有没有问题”Alertmanager 负责决定“这个问题通知谁、怎么通知”。业务规模一旦上来所有告警都发到一个群、一个 receiver等于没做告警管理。我比较推荐按团队和按服务拆路由。主机层的告警可以统一进基础设施群数据库相关规则单独路由给 DBA 群业务应用层的告警路由给对应业务研发群。在路由上推荐用告警里的自定义 label 来区分比如给不同告警打上team: infra、team: db、team: pay然后 Alertmanager 依据这些 label 做分发。route: receiver: default-webhook group_by: - alertname - instance group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: - teamdb receiver: db-webhook - matchers: - severitycritical receiver: oncall-webhook这段配置的意思是普通告警进默认的 webhook匹配到 teamdb 的进数据库 webhookcritical 等级的进值班电话/更高优通知。路由顺序很重要Alertmanager 会从上到下匹配所以更具体的规则要放在前面。4.2 分组和抑制同一台机器别同一时间轰炸好几种声音Alertmanager 的分组机制解决的是“同一时间段内同类告警合并成一条通知”的问题。比如一台机器有多个挂载点同时磁盘将满如果不分组会一次弹五六条消息这其实是同一次故障应该合并成一条通知里面列出所有受影响的挂载点。group_by配置里建议把告警名、实例、严重程度放进去。比如group_by: [alertname, instance]同一台机器的同一个告警会聚合为一条。有些场景你还想按集群聚合比如整个集群都存在时钟偏差那把cluster也加进来。但要注意group_by 的维度越多通知聚合度越低维度越少通知越少但详情可能不够明确。实践中最常用的是alertname加instance既避免刷屏又能定位到机器。抑制规则也很重要。很多告警之间是因果关系比如一台机器因为 CPU 100% 触发了高负载告警同时它的服务健康检查也挂了。如果 service down 已经是 critical那后面出来的 CPU warning 就不必再打扰人了。Alertmanager 的 inhibit_rules 可以做到“高等级告警压制低等级相关告警”inhibit_rules: - source_matchers: - severitycritical target_matchers: - severitywarning equal: - instance这段配置的含义是同一台 instance 上如果已经存在 critical 告警那么所有 warning 告警都会被抑制。实战中这个规则可以大幅减少告警风暴但要小心不要在跨 instance 的场景乱用 equal否则容易把本应送达的告警也吞掉。4.3 静默与维护窗口发版和重启时给告警一个“免打扰开关”生产环境经常有主动变更行为发版、扩容、重启、换硬件。这些操作必然会导致某些指标短期异常这时候最好的办法不是关监控而是给 Alertmanager 设置一个静默时间。Alertmanager 提供 silence 机制你可以在 UI 上或通过 API 创建一条基于标签匹配的静默规则比如匹配某个 instance、持续 30 分钟。这样维护期间系统不会因为你的主动操作产生误报。我建议把静默流程做成公司内部的标准操作任何同学要重启机器先到 Alertmanager 创建静默再执行操作操作结束后主动删除静默。这里有个小坑silence 是一次性配置和常规告警规则一样也需要维护。如果团队里很多人习惯“重启个服务就静默半小时”静默到期却忘了删那这段时间里的真实故障也会被屏蔽。更好的方案是让发版系统自动创建静默并在流水线结束时自动删除静默避免人为遗忘。4.4 通知内容的可读性同一个告警不同的写法不同的处置效率Alertmanager 最终把告警发到钉钉、企微或 Slack靠的是 notch 模板。很多团队的模板非常简单只输出告警名和标签消息里全是[Firing]、instance10.0.0.1:9100这样的原始数据。对于不熟悉 Prometheus 的业务同学来说这种消息几乎没有可读性。建议在模板里做几件事把 instance 的端口去掉只保留 IP把主机 IP 转成可读的主机名把标签中的关键信息汇总成一句人话。比如模板里可以写{{ range .Alerts }} {{ .Labels.alertname }} on {{ .Labels.instance }} {{ .Annotations.summary }} {{ .Annotations.description }} {{ end }}另一个容易被忽略的点是严重程度标识。因为不同接收方可能只关注某一种 severity建议在通知标题里先写[Critical]或[Warning]这样值班同学扫一眼通知列表就能决定优先级。通知平台最终是人看的多花一点时间打磨可读性远比多写十条规则更能提升告警系统的效率。5. 常见问题与避坑实录从误报到漏报的排查思路5.1 主机重启为什么带来一堆“幽灵告警”我见过最典型的一个场景某台 node_exporter 因为系统重启失联了几分钟等它恢复之后CPU、内存、磁盘、systemd 一下子进来了四五条告警弄得值班同学以为出了大事。实际上只是机器重启了服务正在慢慢拉起。原因在于 Prometheus 在抓取中断期间会产生数据空洞重启完成后 counter 重新开始计数。如果你用的是 rate 类表达式短时间窗口内自然会计算出异常高的增量。针对这类情况要做两件事第一instance 自身的失联要用up 0或absent规则单独管理别依赖其他指标间接表示第二给水位类告警设置足够长的 for给系统恢复留时间比如 CPU、内存告警最少for: 5m。我甚至见过有人把磁盘告警也设成 for 0结果重启后伪文件系统未完全挂载期间疯狂触发最后不得已把规则删了重写这都属于经验不足的代价。5.2 内存告警一直响业务却毫无影响内存使用率一直接近 95%但页面响应时间一切正常这种告警是不是误报要分两种情况看。一种是没有过滤掉 page cache内存使用率看着高内核随时可以回收这部分缓存给业务用这属于表达式选错指标应该回到 MemAvailable 方案。另一种是 MemAvailable 确实很低但业务负载还撑得住这时候只靠内存水位很难判断严重程度需要辅以 swap 使用量、PSI 压力指标一起看。如果 swap 使用量长期不涨说明内核还有余力压缩和回收缓存一旦node_pressure_memory_waiting_seconds_total开始明显上涨那就说明真的有人在等内存了。我自己的处理建议是内存 use 告警定位为 warning把 swap 和 PSI 指标告警作为 critical 的判定依据。这两条一起看才不会在正常服务上反复收到“内存爆了”的消息。5.3 磁盘告警反复出现多半是过滤条件没写全前文已经提过磁盘告警必须先排除伪文件系统但实际生产环境远比想象中复杂。有人过滤了 tmpfs 和 overlay却忘了过滤squashfs于是在某些容器镜像层上出现使用率 100%有人过滤了文件系统类型却忘了过滤/boot这种长期不动的分区还有人把mountpoint过滤条件写成了精确匹配导致/data和/data2被漏掉。最稳妥的做法是先在 Grafana 里把所有node_filesystem_size_bytes序列拉出来看清当前主机上究竟有哪些文件系统再决定哪些需要纳入监控。过滤是一种减法你在生产环境用的采集指标越宽过滤器就越要写得严谨。完整的过滤正则最好统一维护成一个模板常量放在所有磁盘规则的 expr 里不要每个规则各自写一套否则后期维护会非常痛苦。5.4 for 时长到底应该怎么分布我的 5/10/30 分钟规律for 时长虽然需要根据场景调整但我个人在实践中总结了一套相对通用的规律状态类告警 1 到 2 分钟水位类告警 5 到 10 分钟趋势预测类告警 15 到 30 分钟。为什么差异这么大因为它们的语义完全不同。状态类告警说明某件事已经发生了比如服务进 failed、主机失联这类告警不需要等太久等太久反而错过处置窗口。水位类告警只是“资源用量比较高”可能持续一段时间后自动回落给 5 到 10 分钟是为了过滤业务高峰。趋势预测类告警本来就是在预测未来单次抖动对回归结果的影响不可忽视拉长 for 能显著减少