前两周有个运维同事跑来找我说自己 Grafana 面板做得挺漂亮CPU 阈值画到了 85可机器负载到 95% 半天了手机上一个告警都没收到。我过去看了一眼就发现问题了他把 Dashboard 面板里的阈值线当成了告警开关以为阈值到了 Grafana 就会自动通知。这是很多人配置 Grafana 告警时的第一个误区——可视化面板和告警体系是两套逻辑。真正想实现“页面告警”也就是直接在 Grafana 页面里完成告警规则的创建、通知渠道的绑定和策略的编排需要走完整的新版统一告警流程。这篇文章我就以在 Grafana 页面上配置告警为主线从新版统一告警的核心概念讲起到数据源、联系人点、告警规则、通知策略的完整配置实操最后把我在实际环境里踩过的坑、排查过的典型问题一起整理出来。内容不依赖外部 Alertmanager直接在 Grafana 页面内搞定适合已经用 Grafana 做可视化、想快速给核心指标加告警的团队参考。1. 页面告警的本质一套从评估到送达的完整链路很多人第一次打开 Grafana 的 Alerting 菜单会懵因为里面并不是一个简单的“打开告警”开关而是一组相互配合的模块。要想在 Grafana 页面里配置出真正能用的告警第一步是先把这套体系跑通。1.1 面板上的阈值线不等于告警规则旧版 Grafana8.0 之前确实支持直接在面板上创建告警配置写在面板 JSON 里面板在页面上展示什么告警就按什么逻辑判断。那个年代的玩法相对简单但也问题不少一个面板改动查询告警跟着变经常误伤面板删了告警也没了通知渠道还只有 email、slack 等少数几种。从 Grafana 8.0 开始官方推出了统一告警Unified Alerting把告警从面板里拆了出来彻底独立成一套系统。你可以通过 Dashboard 面板的 Alert 页签快速创建一条绑定到该面板的规则但这只是创建入口规则本身存储在告警系统里不再和面板查询强绑定。也就是说页面告警里的“页面”更像是一个操作入口而不是告警的运行载体。刚开始不习惯但用久了你会发现这套设计是对的面板负责展示告警负责判活和通知两者解耦之后规则可以独立修改、独立测试、独立路由不会因为谁动了一下仪表盘就导致报警逻辑失控。1.2 五个核心组件先记住它们的分工在页面里配置告警我习惯先在心里过一遍这五个组件顺序正好也是告警从产生到到达你手机的完整链路数据源Data Source告警要查询的监控数据来源比如 Prometheus、Loki、MySQL、CloudWatch 等。告警规则执行的查询都基于数据源。告警规则Alert Rule定义“什么时候算异常”。包括查询表达式、判断阈值、评估频率、等待时长以及告警要携带的标签和说明。联系人点Contact Point定义“告警发给谁”。它是一个接收器比如一个企业微信群机器人、一个邮箱地址、一个 Webhook URL也可以同时挂多个渠道。通知策略Notification Policy定义“这批告警怎么路由、怎么分组、怎么重复”。我们根据告警上的标签决定它走哪个联系人点就像快递分拣中心根据地址分拣包裹。静默与抑制Silences / Mute Timings临时关闭某些告警通知的“静音开关”比如发布窗口期不想被打扰就可以按标签做一段时间的静默。很多新手上来就直奔“创建告警规则”忽略了联系人点和通知策略结果告警状态明明已经 Firing人却什么都收不到问题往往就出在通知链路没打通。所以后面我会把规则和通知策略放在同等重要的位置去讲。1.3 什么场景适合直接用 Grafana 页面告警Grafana 页面告警不是万能的但它对中小团队特别友好。如果你的监控体量在几十台到几百台规模指标主要来自 Prometheus、Loki、云监控这些数据源又不想额外维护一套 Alertmanager 集群那 Grafana 内置告警就是最省事的方案。直接在页面上配置规则查询 PromQL绑定企业微信或钉钉机器人整个流程基本没有额外的开发成本。如果你的规模已经上千台告警规则上千条确实要考虑更专业的告警编排比如把 Grafana 告警接到现有 Alertmanager 再做二次路由。但我个人建议团队刚起步阶段不用一上来就搭特别重的告警体系先用 Grafana 页面把核心告警跑起来规则多了再逐步演进到多层架构。少一个环节就少一个故障点。2. 动手之前先确认数据源和通知渠道配置告警规则之前有两项准备工作必须做否则后面一定会卡壳数据源是否支持告警查询以及通知能不能真正送达。2.1 检查数据源是否具备告警能力不是所有数据源都能直接用于告警。Grafana 统一告警要求数据源实现查询后端Backend能力通俗点说就是数据源能够在 Grafana 服务端主动执行查询而不是依赖浏览器前端。目前常用的 Prometheus、Loki、Graphite、CloudWatch、InfluxDB、MySQL 等主流数据源都支持但具体到某个数据源版本可能还要在数据源设置里打开“Alerting”相关的开关。检查方法很直接打开一个数据源页面看配置项里有没有“Alerting”相关区域。比如 Prometheus 数据源有一个“Enable alerting”的开关默认是开着的如果你用老版本或某些自定义数据源可能根本没有这个选项那它在告警规则里就用不了。还有一点容易被忽略Grafana 页面告警执行查询时用的是数据源配置里的“保存的”连接和你当前浏览器登录 Grafana 用的账号无关。如果数据源配置时填了只读账号要确保这个账号有足够的查询权限否则规则会一直报查询错误。2.2 先把通知渠道建好企业微信群机器人 Webhook通知渠道我在实际项目里用得最多的不是邮件而是企业微信群机器人。因为大多数运维值班现在都在群里机器人直接推消息比邮件更及时。Grafana 联系人点支持很多集成Webhook 是兼容性最好的一个可以对接企业微信、钉钉、飞书、Slack 的机器人。以企业微信群机器人举例配置步骤打开企业微信群点击右上角群设置找到“群机器人”添加一个机器人复制它的 Webhook 地址。在 Grafana 中进入 Alerting → Contact points点击 “Add contact point”。名称填 wecom比如 “wecom-ops-group”。集成类型选择 Webhook。URL 填企业微信机器人的 Webhook 地址。关键步骤Webhook 的 Body 不能直接用 Grafana 默认格式企业微信要求固定的 JSON 结构。在可选设置里把 HTTP Method 设为 POSTBody 写成这样{ msgtype: text, text: { content: {{ range .alerts }}{{ .annotations.summary }}\n{{ end }} } }这一步是很多人踩坑的重灾区。Grafana 默认 Webhook 发送的是自己的告警 JSON企业微信机器人会直接拒绝或者不识别必须手动把发送内容改造成企业微信要求的格式。保存后点 “Test”如果群里能收到机器人消息说明渠道通了。注意企业微信机器人的 Webhook 地址需要妥善保管它可以往群里发消息相当于群的一个入口权限泄露了会导致垃圾消息频繁轰炸。2.3 邮件通知渠道配置 grafana.ini 的 SMTP如果你所在的团队还是习惯邮件收告警那 Grafana 的邮件通知也得配好。邮件通知依赖 Grafana 服务端自己去发信所以要配置 SMTP。以最常见的 /etc/grafana/grafana.ini 为例在 [smtp] 段配置[smtp] enabled true host smtp.example.com:465 user alertexample.com password your_password from_address alertexample.com from_name Grafana Alert如果是 Docker 方式部署建议直接用环境变量省得挂载文件GF_SMTP_ENABLEDtrue GF_SMTP_HOSTsmtp.example.com:465 GF_SMTP_USERalertexample.com GF_SMTP_PASSWORDyour_password GF_SMTP_FROM_ADDRESSalertexample.com GF_SMTP_FROM_NAMEGrafana Alert改完配置需要重启 Grafana 服务。然后在联系人点里添加“Email”类型的集成填上收件地址点 Test 发一封测试邮件确认能收到再往下走。我一直强调“先测邮件再写规则”因为很多运维环境里 SMTP 服务器的 25 端口被封或者用 465 端口时没有配置 SSL 参数等到规则触发时才想起测邮箱就太被动。3. 在 Grafana 页面里创建第一条告警规则准备工作做完终于到核心环节创建告警规则。这一节我会给出两条路径一条是从面板快速进入一条是直接新建同时把规则里的几个关键参数讲透。3.1 最顺手的方式从面板的 Alert 页签进入如果你已经在某个 Dashboard 上画好了指标面板想基于当前查询加一条告警最快的方式是进入面板编辑模式切到 Alert 页签。操作路径打开 Dashboard进入某个 Panel 的编辑界面鼠标悬停在标题上选择 Edit或者直接按 e在右侧面板设置里找到 Alert 页签点击“New alert rule”。从面板创建规则有一个好处面板当前的查询表达式会自动带过来不用重新写一遍。比如你在面板上画的是一条 CPU 使用率曲线点击创建后告警规则里已经带上了这条 PromQL。但如果后续你在面板上改了查询已创建的告警规则不会自动同步——这是新版统一告警和旧版面板告警最大的区别。规则创建后就是独立实体面板只是当时给了你一个快捷入口。同样如果面板被删除规则不会马上被物理删除旧版会但会变成失效状态。我见过有人在 rework dashboard 的时候删了一堆旧面板结果某条告警突然不报警了查了半天才发现是面板被删导致规则失效。所以告警规则命名和组织要规范别让它跟某个“临时面板”绑定得那么随意。3.2 把查询、Reduce、Threshold 三步配明白不管从哪个入口创建规则核心的规则配置区都是一样的。以一个 Prometheus 数据源的 CPU 使用率告警为例新版告警规则默认是 A、B、C 三个子查询节点结构A 查询取原始指标比如100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这一步算出来的是每台机器的 CPU 使用率。B ReduceGrafana 告警需要一个“当前值”来做阈值判断但查询返回的是一个时间序列所以先用 Reduce 把序列聚合到一个数值。Reduce 函数通常用 Last即取最新一个点的值。C Threshold这才是真正的“报警条件”比如设置为 85如果 Reduce 出来的值大于 85条件成立规则就会进入待触发状态。如果查询本身是布尔表达式比如up 0那么 A 查询返回的数据本身就是“异常”的可以不用再套 Threshold。这种情况下 Grafana 会对每个返回的序列分别做判断只要查询有数据就认为条件成立。实际配置中容易翻车的地方在于对多实例环境A 查询会返回多条序列B 的 Reduce 要对所有序列做计算。如果你在 Reduce 里选了 Mean就会把所有机器的 CPU 合并成一个“平均使用率”某一台机器跑到 99% 反而被其他机器拉低平均值导致告警漏报。正确做法是保留 instance 维度Reduce 用 Last每条序列单独判断这样任何一台机器超过阈值都会触发告警。提示告警规则里的“查询表达式”和面板查询虽然长得一样但最好不要共用一份复杂的 PromQL。面板查询可以为了展示做各种聚合告警查询要尽量简单明确优先保证判断逻辑的可读性。3.3 理解 Pending 和 For别把瞬间抖动当故障规则创建页面里最容易被忽视的一组参数就是评估频率Evaluate every和等待时长For。Evaluate every多久评估一次生产环境一般设置 30s 或 1m不建议低于 30s因为评估会产生真实的数据源查询压力Prometheus 扛得住不代表 Grafana 自身没有开销。For条件满足之后需要持续多久才真正触发告警。比如设置 For 5m那么 CPU 使用率超过 85% 后需要连续保持 5 分钟规则才从 Pending 变成 Firing才真正发送通知。这个 For 太重要了。我见过有团队把 For 设成 0s某台机器 CPU 瞬时飙一下比如编译一个小程序告警就分钟级轰炸值班同学半夜被骚扰得想骂人。反过来也有团队把 For 设成 30m结果故障老半天了手机还没动静。我的建议是核心可用性指标用 1m 左右避免无谓抖动容量类指标比如磁盘使用率可以用 5m-10m因为这类指标不会瞬间恶化允许它多观察一会减少误报。配置完成后你可以看到状态变化链路Normal正常→ 条件满足后进入 Pending等待观察→ For 时间到后进入 Firing真正触发→ 条件恢复后回到 Normal并发送 Resolved恢复通知。这条链路里Pending 是一个中间状态很多人看到规则一直黄色 Pending 就以为坏了其实它只是在等 For 时间走完这正是保护机制在工作。3.4 给规则加标签和说明后面路由全靠它们创建规则时有一块“Labels” 和 “Annotations”区域很多人直接跳过这是大忌。有了标签通知策略才能做路由有了说明告警消息里才能展示“哪台机器、什么指标、什么原因”。标签建议统一规范比如severitycritical、warning、infoteaminfra、app、dbservicegateway、order、user这样一条告警规则打上了severitycritical, teaminfra后面通知策略就可以配置凡是 severitycritical 的告警直接推到核心值班群并重复通知凡是 teamapp 的告警推到应用开发群由开发自处理。Annotations 里常用 summary 和 description。summary 是指示栏标题description 是详细内容里面可以用模板语法引用查询出来的标签值比如实例 {{ $labels.instance }} 的 CPU 使用率超过 85%当前值 {{ $values.C | humanize }}%这样告警到群里就能直接看完整个上下文不用再打开 Grafana 查是哪台机器。这一步骤看起来只是写文案实际是在降低值班同学的响应成本非常值得花几分钟设计好。4. 联系人点和通知策略让告警送对地方规则创建好了不等于告警能送到正确的人。Grafana 把“发给谁”和“怎么发”拆成了两个独立概念联系人点负责定义渠道通知策略负责定义路由规则。我见过很多团队规则一大堆联系人点也建了好几个但通知策略还是默认的根策略所有告警一股脑全发到默认联系人值班同学每天被大量无关告警淹没。要改变这种情况重点在通知策略。4.1 创建联系人点一个联系人点可以挂多个渠道进入 Alerting → Contact points点击“Add contact point”。给联系人点起一个容易认的名字例如 critical-wecom、warning-email、ops-all。同一联系人点可以添加多个集成也就是同时支持多个渠道。举个例子我给“critical-wecom”这个联系人点挂了两个集成企业微信群机器人 Webhook 和 Email。这样有一条 critical 告警产生群机器人立刻在群里播报同时邮件抄送一份给技术负责人存档。两个渠道同时触发谁也不会漏掉而且配置成本很低。在联系人点列表里每一条都有一个“Test”按钮建议创建完就测试一遍。测试通过只代表该联系人点能发消息但具体某条告警能不能走到这个联系人点还得看通知策略。4.2 用通知策略做路由标签就是告警的“地址”通知策略的运作方式和路由器很像。根策略Default policy会匹配所有未被其他策略匹配的告警通常我们不会把根策略直接设成某个联系人点而是搭一层子路由。比如这样设计根策略默认走 wecom-ops运维值班群兜底子路由 1匹配severitycritical走 critical-wecom核心群 邮件子路由 2匹配teamapp走 app-dev应用开发群在页面上配置时“匹配”用的是 PromQL 风格的标签匹配语法比如severitycritical teamapp一个告警的标签如果同时匹配多个子路由Grafana 会采用最具体最长匹配的规则。这个规则有点绕但好处是灵活性极高。比如你可以先配置一条severitycritical再配置一条severitycritical, teamorder那么订单服务的 critical 告警会走更具体的第二条其他 critical 告警走第一条通用规则。4.3 分组、重复通知和静默配置一次就省心通知策略里还有几个分组参数新手容易忽视但实际值班体验全看它们Group by按哪些标签聚合告警。比如按alertname分组同一类告警会合并成一条消息推送不会因为 50 台机器同时 down 就刷 50 条。Group wait新一组告警产生后等待多久再发送默认 30s目的是把几秒内产生的同类告警合并到一条消息里。Group interval同一组告警里如果有新告警进来至少等待多久再发下一条默认 5m避免短时间大量刷屏。Repeat interval同一条告警通知的重复间隔默认 4h意思是如果告警一直不恢复每 4 小时提醒你一次而不是无限刷屏。这些参数一定要按团队实际值班习惯调。我自己的习惯是 critical 告警 Repeat interval 设短一点比如 1hwarning 告警设成 6h 甚至 12h让不同等级的告警有完全不同的打扰程度。静默Silences和抑制Mute Timings这个功能适合在发布窗口期用。比如每天凌晨 00:00 到 06:00 是定时任务窗口可以配置一个 Mute Timing在这时间段内不发送某些标签的告警。但要小心静默只是不发送通知告警规则本身仍在评估和记录所以不会出现“静默期间发生故障、恢复后完全不知道”的情况你可以在事后复盘时查看这段时间的规则状态这个设计非常贴心。5. 告警配置过程中的问题排查与避坑这一节把我在实际项目中踩过的坑整理一遍按出现的频率从高到低排列。如果你照着前面配置完了还是在页面里看不到告警或者收到了异常提示大概率能在下面找到原因。5.1 规则已触发人却没收到消息按这条链路排查告警链路涉及环节多一旦没收到消息我建议按“规则状态 → 标签匹配 → 联系人点 → 渠道端”的顺序逐个排查不要瞎猜。看规则状态。打开 Alerting → Alert rules找到目标规则确认状态是否变成 Firing。如果还是 Normal说明查询或阈值条件没成立先调整查询如果一直是 Pending大概率是 For 设置太长或者查询结果在抖。看评估日志。点进规则详情可以查看每次评估的历史记录。如果评估结果有 Error 或 NoData那问题出在数据源或者查询上。比如 PromQL 写错、数据源断连都会在这里显示得非常清楚。看标签和路由。确认这条规则产生的标签是否真的能匹配到某条有联系人点的通知策略。很多人在这里翻车子路由匹配条件写反了或者根策略联系人点没设置导致告警虽产生但无处可去。看联系人点测试。在 Contact points 里点 Test 发一条测试消息确认渠道本身通不通。如果测试成功但真实告警没发问题基本出在路由而不是渠道。这里要特别提醒Grafana 的联系人点测试默认发送的是一条固定格式的测试消息它不会走完整通知策略只验证该联系人点的渠道配置。所以测试通过千万不要以为整套链路已经验证完了。5.2 页面提示 failed to upgrade legacy queries datasource was not found这个错误是从哪些老版本升级上来之后很常见的。我遇到过几次现象是打开某个 Dashboard 面板时页面直接提示类似failed to upgrade legacy queries datasource xxxxxx was not found整个面板查询失效告警评估也跟着报错。原因通常是面板 JSON 里保存的数据源引用还是旧的 UID升级后 Grafana 在迁移老查询时找不到对应的数据源。处理思路并不复杂进入面板编辑模式看查询编辑器的数据源选择框如果显示为空或提示找不到数据源就重新选择当前实例里实际存在的数据源。如果面板是通过 Provisioning 方式管理的检查 provisioning 文件里的数据源 UID 是否与目标数据源一致。比如datasource字段填的应该是数据源的 UID而不是名称。修复后保存面板再进入 Alert rules 里找到关联的规则重新评估一次。正常情况错误提示会消失。这个报错对告警的影响必须重视老面板如果带了旧查询升级后可能整体迁移失败导致规则评估一直处于异常状态而你在“规则状态”页看到的只是长时间的 NoData 或 Error。所以大版本升级 Grafana 之后第一件事就是抽查几个绑定了告警规则的面板确认查询还能跑通。5.3 多实例聚合引发的漏报与误报前面讲 Reduce 的时候提到过平均值的问题这里再展开说一个典型场景。某个业务服务有多台实例你写了一条查询统计请求错误率然后直接在规则里用了类似avg by (service) (rate(http_requests_total{code500}[5m]))的表达式想观察整个服务的平均错误率。问题来了如果只有一台实例故障平均错误率可能只上升了几个百分点远达不到设置的阈值于是故障被平均掩盖了。正确的做法是保留实例维度对所有实例分别判断比如rate(http_requests_total{code500}[5m]) 0.05这样任何一台实例的错误率异常都会触发。告警是给值班人看“哪里坏了”的不是给老板看“整体健康度”的聚合维度一定不能为了美观而牺牲可观测性。5.4 其他高频问题速查表现象常见原因处理建议规则一直是 Pending不转 FiringFor 设置太长或查询结果间歇性不满足临时把 For 设为 0s/5s 观察是否符合预期再调回测试联系人点成功实际告警收不到通知策略路由没匹配到目标联系人点检查规则标签与子路由匹配表达式告警刷屏同样的消息一直发Repeat interval 设置太短调大 repeat_interval比如 4h收到告警但恢复Resolved消息没来规则条件恢复不了或数据源无数据查看评估日志确认查询结果最终回到了 Normal面板出现 failed to upgrade legacy queries数据源 UID 在升级后失效重新选择数据源并保存面板告警消息里没有机器名等关键信息规则的 annotations 模板没写完整在 summary/description 里用$labels.instance等模板字段有人可能会问Resolved 通知到底是什么时候发的这里补充一句当规则状态从 Firing 变回 Normal 时Grafana 会附带发送一条恢复通知。你可以在联系点集成里关闭“发送恢复通知”的选项但建议保持开启——故障恢复不通知值班人就要一直悬着心不知道平台啥时候恢复。5.5 关于时区和静默窗口的提醒最后说一个偏冷门但容易影响判断的坑时区。Grafana 告警的评估时间是按系统时区处理的但通知模板里展示的时间戳通常带时区信息如果你的告警规则是跨国或跨地域团队共用静默时间窗口很容易踩到“我以为不是工作时间其实国外团队正在上班”的雷。我建议在配置 Mute Timing 或静默窗口前先确认 Grafana 系统时区和业务所在时区再完成配置。如果涉及跨时区值班最好在告警消息模板里显式带上 UTC 时间和本地时间两个字段避免大家在不同时区对不上时间线。最后再分享一个实用的小技巧是我在新建每组告警规则时都会做的不要直接在生产环境上边配边等触发。先在测试面板上把 For 设为 5s故意把阈值调到肯定触发的值做完一条通知验证再慢慢把阈值和等待时长调回真实值。这套流程跑通后把规则打上team和severity标签后续维护就非常轻松了。Grafana 页面告警看着只是点点点真正花心思的地方其实在标签设计和路由语义上这个做好以后值班手机才能真正安静下来。