凌晨三点，监控大屏上其实早就一片血红了，CPU、内存、错误率三条曲线跟心电图急停似的。但问题就出在“其实早就红了”这六个字上——大屏挂在办公室，没人二十四小时盯着它，报警电话反而是客户那边打过来的。从那次之后我做了一件事，把Grafana从一块被动展示的屏幕，改造成一个主动喊人的告警中枢。这篇文章不讲那些官方文档里已经写烂的基础概念，而是从一个实际运维者的角度，把Grafana配置页面告警这条链路上最容易卡住人的地方、最容易被忽略的细节、以及踩过坑之后总结出来的经验，完完整整捋一遍。
适合谁看呢？两类人：一是团队里监控面板已经搭起来了、但告警一直没正经配上的同学；二是配了告警但总在“该响不响、不该响乱响”之间反复横跳的运维老手。无论你是刚接触Grafana的新手，还是已经在用Prometheus、Loki、Alertmanager的进阶用户，这篇文章里提到的思路和排错方法都能直接拿过去用。
1. 监控图表不会喊救命——为什么非配告警不可
1.1 一次凌晨故障让我彻底改变了监控习惯
那次故障具体是什么业务我就不说了，过程很有代表性：凌晨两点数据库连接数开始缓慢上涨，当时的监控面板上Connections曲线从200慢慢爬到1900，距离限额还差一口饭。面板画得清清楚楚，问题在于没人看。等我第二天早上刷手机看到客户群里有人问“昨晚是不是有问题”的时候，祸已经闯完了。
这件事让我彻底想明白一个道理：监控系统和告警系统是两码事。监控解决的是“出了问题如何定性”，告警解决的是“出了问题如何及时知道”。大多数人用Grafana就停留在第一层，图表画得漂漂亮亮，然后在运维群里挂个链接，让大家“有事自己看”。可一旦没有人主动去看，监控的价值就等于零。
所以在Grafana上配告警，不等于简简单单在某块面板上加个Alert标签栏，它背后的逻辑是：把“需要人关注的状态”翻译成“可以被程序判断的条件”，再通过稳定的通知渠道推给正确的人。这一整条链路，才算真正把监控用了起来。
1.2 新版告警和旧版Dashboard Alert，先分清楚你用的是哪一套
配告警之前有个前提要搞清楚：你现在用的是Grafana的哪套告警体系，页面完全不同，配置思路也完全不同。
- Legacy Dashboard Alert（旧版面板告警）：在某个Panel的Alert标签里配置，写查询条件、设置阈值、选评估周期，最后把通知发到旧的联系人渠道。它的缺点是告警和面板强绑定，面板删了告警也没了，而且通知方式、去重、分组能力都很弱。Grafana官方早就把它标记为废弃功能，9.0之后新装实例默认走的是新版告警。
- Unified Alerting（新版统一告警）：从Grafana 8.0开始引入，9.0之后全面接管。它把告警规则、联系人、通知策略三者解耦，规则可以独立于面板存在，支持多数据源，支持非常细的路由匹配和分组聚合。
绝大多数人现在打开Grafana，左侧菜单里看到的是Alerting这个独立入口，也就是新版。如果你在面板编辑里看到黄色的"Alert"标签，那多半是还在用旧版。建议尽早迁移到新版，因为新版不只是页面变了，更重要的是它把告警从“展示附属品”提升到了“完整子系统”的位置。
还有一个容易混淆的概念是Prometheus Alertmanager。很多人以为Grafana的告警功能就是Alertmanager，两者确实有关系但不一样：Alertmanager是Prometheus体系中负责接收由Prometheus服务器预计算好的告警事件，然后做分组、抑制、静默并发送通知的组件；而Grafana Unified Alerting自己有内置的Alertmanager实现，同时也可以选择“使用外部Alertmanager实例”来接管通知发送。简单理解，Grafana负责基于数据源查询条件计算告警，Alertmanager负责把计算出来的告警怎么发、发给谁、什么时候发。新版Grafana里，如果是默认配置，这个“怎么发”的活就是Grafana自己那套联系人和通知策略在干。
提示：到底用Grafana自带Alertmanager，还是对接外部的Prometheus Alertmanager，取决于你的架构。如果Prometheus已经被你用得滚瓜烂熟、Alertmanager里的路由和抑制规则也都沉淀好了，那就继续沿用外部方案；如果只是单纯用了Grafana做可视化，不想再维护一套Prometheus告警规则，那直接使用Grafana原生告警是最省事的。
2. 告警规则的三个底层要素：查询、条件、评估
2.1 告警查询和仪表盘查询的差异
很多人配置告警的时候第一个动作是去仪表盘的Panel里复制查询语句，直接粘到告警规则里面。这种做法在简单场景下能跑通，但一旦条件复杂就会出现各种奇怪行为。为什么？因为仪表盘查询和告警查询的运行环境完全不同。
仪表盘查询重点关注“展示效果”，它会根据你选的时间范围自动调整$__interval等变量，用来适应不同跨度的图形展示。而告警规则的查询是在后台周期性执行的评估任务，它不关心你在页面上选了多长的时间范围，只关心Evaluate every这个评估周期，以及你在查询里写死或者动态计算的时间窗口。
我见过最典型的问题：有人把仪表盘里的rate(requests_total[5m])原封不动搬到告警规则里，配置的评估周期是1分钟，看起来没问题。但实际上，[5m]这个范围在仪表盘里会被$__interval替代成几秒或几十秒的粒度，在告警评估时却用的是固定5分钟，两者得到的瞬时速率形态完全不一样，阈值自然也不一样。
所以在写告警查询的时候，建议遵守几条原则：
- 尽量显式指定时间窗口，比如
rate(http_requests_total[5m])，不要依赖$__interval。 - 确保查询返回的是一个数值，Prometheus数据源返回单个时间序列是可以的，但如果你想让它变成一个标量条件，需要配合Reduce、Threshold等表达式。
- 先到Explore页面里手动执行一遍查询，看返回的值是什么样的量级，再定阈值。这条建议价值连城，能省掉后面无数个“为什么没触发”的深夜。
2.2 For参数与评估周期怎么选
告警规则里主要有两个时间相关参数：Evaluate every（评估周期）和For（持续判定时间）。这两个参数是新手最容易踩坑的地方，也是告警规则精度和误报之间的平衡杠杆。
Evaluate every表示每隔多久评估一次这条规则。比如填1m，就是每分钟跑一次查询，检查当前值有没有满足触发条件。这个周期不是越短越好——评估本身需要去数据源拉数据，如果数据源是Prometheus，频繁查询会带来额外压力；而且监控数据本身有采集间隔，你搞一个5秒的评估周期，很可能数据还没更新就被评估了，白白增加误报概率。常规做法是评估周期和数据抓取周期保持同一量级，比如Prometheus默认抓取间隔15s，评估周期设置为1m到5m就非常合理。
For参数的含义是：条件满足之后，必须持续满足多长时间才算真正触发。举个例子，For: 5m意味着查询结果连续5分钟都超过阈值，告警状态才会从Pending变成Firing。这个参数存在的意义是过滤掉瞬时毛刺。生产环境里CPU使用率瞬间飙升到95%，很可能是定时任务、服务启动、批量导入造成的，过了几秒就掉下来。如果没有For参数，这种毛刺就会被当成故障推送到你手机上。
我的经验是：
- 对CPU、内存这种波动敏感的指标，
For设置在5~10分钟比较安全，避免毛刺告警。 - 对磁盘空间饱和、证书即将过期这种只要满足就必然出问题的指标，
For可以设短甚至设为0，尽快触发。 - 评估周期和
For要搭配着看：评估周期1m、For 5m，意味着至少需要5次评估持续命中才触发；如果评估周期5m、For 5m，那触发最快要10分钟，因为第一次评估计算出条件满足后还要再等下一轮确认。
2.3 容易翻车的“多序列”告警
一个非常容易被忽略的细节：你的查询到底返回了多少条时间序列？如果查询条件里带了instance、host、pod这类基数较高的标签，而且没有做聚合，那么每个标签组合都会各自生成一个独立的序列，Grafana会对每一个序列分别判断条件和触发告警。
举例来说，你有10台机器，告警查询写的是100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90，并且没有加instance过滤，那么这个查询会返回10条序列，每条对应一台机器的CPU使用率。如果其中3台超过90，就会生成3条独立的告警事件。这个行为本身合理，但容易让没有思想准备的人懵住——“怎么一下子来了一堆告警？”
如果你想得到的是一个整体聚合结果，那就必须显式聚合，比如max()、sum()、avg()。如果你就是想要每台机器独立告警，那也没问题，但要清楚知道这条规则在机器数量增多时会变成多少量的告警。
另外还有一个细节：如果查询返回了多序列，后续接入通知策略时，每条告警都带有各自的标签（比如instance="node01"），这些标签可以作为路由匹配的依据，也能在通知消息里展示具体是哪台机器出了问题。
3. 操作链路：从新建规则到通知触达的完整配置
3.1 新建告警规则：页面上的每个字段怎么填
现在进入正题，一步步看Grafana的告警配置页面。菜单路径是Alerting -> Alert rules -> New alert rule，打开后有三个步骤区域，但也有不少进阶字段隐藏在折叠区域里。我把关键字段逐一拆开讲。
Rule name（规则名称）：建议包含明确的指标和对象，例如“生产环境-API网关-5xx错误率超5%”，而不是“Test1”这种。告警通知里默认会带上规则名，取一个能直接看懂的名字，等于省去后续翻上下文的时间。
Folder（文件夹）：规则必须存放在某个文件夹里。这个文件夹和面板共用一套文件夹体系，建议先建好几个业务用途清晰的文件夹（比如“核心服务告警”“基础设施告警”），避免所有规则堆在一个地方，日后维护会疯掉。
Group（评估组）：Grafana把告警规则按组来调度评估。同一个组里的规则使用统一的评估间隔（在New evaluation group下拉框里可以设置），优点是评估任务可以被批量调度，节省资源。我的建议是：评估周期相同的规则放在同一个组。如果你把所有规则都塞进默认组，但其中一条要改成10秒评估一次，你会发现这个设置是全局的，导致所有规则都被带过去，很尴尬。
Queries and expressions（查询与表达式）：这是规则的数据来源。选好数据源，填查询语句。如果阈值判断需要二次计算，可以在数据源节点后面添加表达式节点，常用的是：
Reduce：把一段时间的多个点聚合成一个值，可选last、mean、max等，告警阈值判断通常用这个。Threshold：在Reduce之后加一个阈值判断，输出0或1来控制条件。这个在新版里更多是作为条件节点使用。Math：做一些简单的加减乘除组合计算。
举个实际配置：要监控某个服务的请求成功率低于95%，查询可以用
sum(rate(http_requests_total{job="api-gateway", status=~"2.."}[5m])) / sum(rate(http_requests_total{job="api-gateway"}[5m]))然后紧跟着一个Reduce选last，再跟一个Threshold设置IS BELOW 0.95。注意这里由于做了除法，返回的值就是0到1的小数，阈值别填成95，很多新手在这里翻车。
Pending period（等待期）：就是前面说的For参数，在规则列表里也能看到。
3.2 配置联系人流程（Contact Point）
告警规则计算出来之后，下一步是通知到人。菜单入口是Alerting -> Contact points。每个Contact Point代表一种通知方式，常见的有Email、Slack、PagerDuty、Webhook、钉钉等。
以邮件为例，第一次配置的时候最容易漏掉的是SMTP。Grafana默认不会发送邮件，必须在配置文件的[smtp]段里填好SMTP服务器信息：
[smtp] enabled = true host = smtp.example.com:465 user = alert@example.com password = your-password from_address = alert@example.com from_name = Grafana Alert修改配置文件后需要重启Grafana服务。这个步骤很多人卡住，点了测试邮件一直报“SMTP not configured”，问题就在这里。
Webhook是一种万能通知方式，尤其适合对接企业内部系统。创建Contact Point时选择Webhook，填写回调URL。默认的payload是Grafana定义的JSON结构，里面包含告警标题、描述、标签、状态、时间等字段。如果你的内部系统只需要收到“标题和摘要”，可以不改默认的JSON结构，直接接。如果对接的是钉钉、企业微信这类封闭消息平台，往往需要配置自定义模板把Grafana的JSON转换成对方要求的格式，这个后面讲进阶的时候详细说。
创建好Contact Point之后，别忘了一个动作：点右边的Test按钮，确认这个消息能够正常发出去。测试是分两步验证：先验证集成本身工作，再验证路由是否把规则投递到这里。
3.3 通知策略：告警消息最终由谁接收
光有Contact Point还不够，还要让告警规则知道“去哪发”。这个对应关系就是Alerting -> Notification policies。
通知策略本质是一个树状结构，最顶层是默认策略（Default policy），下面的子策略通过标签匹配来筛选告警。每个策略决定一组告警如何分组、发送到哪个Contact Point。
可以这样理解：Contact Point是信箱，Notification Policy是分拣员。告警出来之后是一个个带着标签（如severity=critical、service=api）的“包裹”，分拣员根据包裹上的标签决定投递到哪个信箱。
举个例子，我想让critical级别的告警走Webhook，warning级别的告警走邮件，可以这样设计：
- 默认策略：匹配所有告警，投递到邮箱联系人，分组按
grafana_folder字段。 - 子策略A：匹配
severity="critical"，投递到Webhook联系人。 - 子策略B：匹配
severity="warning"，投递到邮件联系人。
配置子策略时，注意匹配规则是标签键值对的完全匹配，比如要匹配多个标签值，可以用正则表达式，但不能写两个相同的标签键。
这里有一个超高频坑：很多人创建了子策略之后，原本规则的标签没配对，导致告警还是按默认策略走，结果该发Webhook的发到邮箱里去了。所以配置完策略，建议先在Alerting -> Alert rules里查看某条规则的“Notifications”标签列，它会告诉你这条规则实际被路由到了哪个策略。
4. 告警不触发、不通知？排查思路比答案更重要
4.1 规则状态正常却一直Pending
告警规则列表里有状态列，状态可以大致看到Normal、Pending、Firing、NoData、Error等。这里有个坑：很多人看到状态是Pending而且持续很久，就开始乱了，以为是规则坏了。
其实Pending恰恰说明条件已经满足了，正在等待For时间期满。如果For设了30m，那在过去30分钟内它一直Pending是完全正常的。等时间一过，应该自动变成Firing。
如果Pending了很久始终不变Firing，按照下面几步排查：
- 点开规则详情，查看最近一次评估的结果，Grafana会把每轮评估生成的具体值列出来。对照一下当前阈值，看看值是不是真的稳定超过了。
- 确认For参数有没有写错。很多人把For填了30m却忘了这会导致触发延迟半小时，以为是Bug。
- 在Explore里手动执行同样的查询，看当前最新值是什么。需要注意的是，告警评估用的是“最后一条样本+窗口计算”，如果数据源最近几分钟没有新样本写入（抓取断了），评估依然在继续但值已经失真。
如果状态是NoData，意思是查询结果为空。造成这个的可能有很多，比如标签写错、时间窗口太短导致窗口内没有数据、数据源被停了。NoData本身也可以被配置成触发告警，在规则里把条件选成“NoData”即可，很多时候服务静默挂掉比尖峰更可怕，我建议核心服务都加一条NoData告警。
4.2 测试通知成功但真实告警不推送
这是群里被问烂了的问题：Contact Point点Test能收到，结果真实告警触发后一条消息都没有。这个问题的核心在于——Test按钮只测试了Contact Point本身的连通性，它不测试进入这条告警的路由策略匹配；而当一条真实告警进入通知策略树时，有可能被其他策略截胡了。
对应排查动作：
- 进入
Alerting -> Notification policies，查看告警规则对应标签在当前策略树中会被谁匹配。把树当成一个路由表，从上往下逐层核对。 - 确认策略里选择的Contact Point和实际测试的是同一个。很多人开了两个邮箱联系人，测试的是A，路由指向的是B，B恰好SMTP密码过期了。
- 检查路由策略里的
Group by字段是否造成了“等待合并而没立即发送”的错觉。如果Group wait设了30m，那么一批新告警会在组里等待30m才发出第一条消息，期间画面看起来就是“没通知”。
4.3 重复通知和静默的坑
告警触发之后，如果一直没恢复，通知会按照策略里的Repeat interval重复发送。默认值可能是4h或更久，这应该符合大部分场景。但有人会把Repeat interval调成5m，然后被自己配置刷屏，这不算Bug。
另外，维护期间往往需要临时屏蔽告警，用的是Alerting -> Silences。静默的本质是标签匹配：
- 创建一条Silence，填开始/结束时间。
- 填入要匹配的标签，比如
instance="node01"，那么所有带这个标签的告警在指定时间内都不会发出通知。 - 注意：如果告警的标签里没有你想匹配的那个键值，或者值不同，静默就不会生效。标签匹配要求完全一致，不是模糊匹配。
所以我的建议是：创建告警规则的时候，从一开始就给规则加上规范的标签，比如team=platform、service=api、severity=critical。标签不仅仅用于路由，还用于静默和后续的聚合分析，这是很多教程没提的事。
5. 让告警不泛滥又不漏报：分组、抑制和告警疲劳
5.1 分组参数到底怎么调不失控
Grafana通知策略里有一组和分组相关的时间参数，分别是Group wait、Group interval、Repeat interval。这三个参数看起来不起眼，实际调优能把体验从“半夜被一百条短信炸醒”变成“一觉醒来清爽地看一条聚合消息”。
- Group wait：一个分组首次产生第一条告警后，等待多长时间才发送第一条通知。设短一点比如30s，可以让同时发生的多条告警先归拢，避免每次只来一条。
- Group interval：在一组告警已经发过通知之后，如果该组又产生了一条新的告警，必须等待多长时间后才再次发送通知。它控制的是“组里新消息”的发送节奏。
- Repeat interval：对于已经发送过的同一组告警，如果它们还没恢复，多久重复发送一次。
举个例子：网关服务挂了，依赖它的5个微服务同时报“连接失败”，这会产生5条不同规则的告警。如果Group by字段里包含service或者直接用默认的grafana_folder，这5条告警可能被分到不同的组里，分别发5次通知。如果把Group by设置成severity，则它们有可能被合到同一个组，Group wait=30s、Group interval=5m，最后变成一条包含多条告警明细的消息发过来。这样体验就好多了。
具体怎么调，我的经验是：
- Group wait默认30s~1m即可，太长了告警延后严重。
- Group interval 5m比较合适，既能及时通知新告警，又不会每几秒就刷一条。
- Repeat interval按业务告警的重要性来：critical可以是10m~30m，warning可以是2h~4h，低优的可以24h都没问题。
5.2 避免告警风暴的三个小手段
告警风暴是监控系统里最破坏信任感的事。喊狼来了喊多了，真出事反而没人看了。要避免这个问题，除了前面说的分组和聚合，还有几个手段值得试一试。
手段一：规则里用聚合查询而不是每台实例独立告警。比如监控Redis集群健康状态，不要针对每台Redis实例单独告警，而是用min()、avg()把集群整体状况拉出来。整体好但单节点有问题时，靠单实例告警；整体掉入危险线，靠集群告警。分两级，而不是一刀切。
手段二：把维护窗口提前纳入静默计划。常见的比如每周日凌晨的备份任务、每月的账单结算任务，会天然导致指标波动。提前在Silences里创建好定时掩码（也可以在Mute timings里配置每天/每周的静默时段），比出了告警再去手动静默靠谱得多。
手段三：对上游和下游告警去重。大多数系统挂了会导致一连串“依赖方报错”，比如数据库挂了，所有连接池都会告警。这种场景下，可以考虑为数据库服务单独建一个告警规则，但是在依赖方侧保持告警规则只做记录不做通知（可以设置静默策略或者路由到不通知的联系人），这样只会收到根因的告警，避免一堆衍生告警同时轰炸。
5.3 一旦遇到“告警疲劳”，先回头审视规则本身
最后说点比较“软”的体会。配置告警这事，最难的从来不是操作流程，而是定力。如果你想给每一个指标都配上告警，最后的结果一定是没人看通知。
我给自己定的一个原则：告警规则必须在“影响用户之前”或“需要人在一定时限内介入”的事件上有意义。比如磁盘使用率告警设在85%，是为了让运维有时间清理，而不是等到100%才通知；接口错误率告警设在1%，是为了能赶在这波流量爆掉之前介入。凡是那种“看起来指标很关键，但实际上发生之后不需要人做什么动作”的情况，就不该设成告警，它可以进面板、进报表，但不要进告警通知。
那么在实际配置时，我会建议你用这样的方式去检查已有的告警规则：
- 列出所有告警规则，对每一条问一个问题：这条告警触发之后，值班的人需要采取什么行动？如果答案是“不知道”，那这条规则要么该删掉，要么说明你根本还没想清楚指标和故障的关联。
- 检查每条规则的通知策略。如果所有规则都走默认策略，等于所有的告警都堆在一起，这时候就算Grafana提供了再好的分组能力，也救不回来。
- 定期去
Alerting -> Alert rules看每一条规则的“Health”列。如果经常出现Error或NoData，说明查询本身可能就存在问题，先修规则再谈优化。
配置Grafana告警本质上是一件需要持续迭代的事，不是配完就一劳永逸。我现在的习惯是每季度重新看一遍整个Alerting结构，把已经不再重要的规则删掉，把新业务的核心指标补上，再根据过去几个月的告警记录调整阈值和路由策略。每一次调整其实都在回答同一个问题：在这个系统下一次出问题之前，我们能不能更早知道一点，更准确地知道一点。
