干监控这行时间长了你会发现一个挺尴尬的事实指标采集了大屏也做了图也美得不行结果线上出故障的时候第一个发现问题的往往是用户而不是监控系统。问题就出在告警这最后一公里。Grafana作为目前最主流的可视化监控平台之一早就不仅仅是画图工具了它的页面告警功能已经能承担完整的告警闭环规则配置、状态计算、通知触达全都能在网页上点出来这也是这两年我把团队告警入口逐步统一到Grafana的原因。这篇文章就围绕Grafana配置页面告警这件事展开从告警方案选型、规则配置的核心细节、通知渠道打通到实际的排障经验完整过一遍。适合刚接触监控告警的运维、后端开发也适合已经在用Prometheus但想把告警入口统一到Grafana里的团队。1. 告警方案选型为什么要把告警做到Grafana里先解决一个“为什么”的问题。很多人第一次接触监控告警是从Prometheus Alertmanager这套组合入手的这套组合很成熟告警规则用yaml写自带分组、抑制、静默配合Webhook能接到几乎所有通知渠道。那为什么还要用Grafana的页面告警我自己的体会是Prometheus的告警规则写起来不难但维护成本不低尤其是让一个不熟PromQL的同事去改阈值就比较劝退。Grafana的页面告警规则直接基于现有的Panel查询条件去配置先在图上看到数据长什么样再框一个条件流程高度可视化学习成本低很多。1.1 Grafana页面告警和Alertmanager的核心区别先看一张我使用下来整理的功能对比表对比项Grafana页面告警Prometheus Alertmanager规则管理方式页面配置所见即所得随时改文件编写改完要重载配置数据源范围Prometheus、Loki、MySQL、InfluxDB等统一接入主要面向Prometheus指标状态可视化规则和实例状态直接在页面看需要额外部署/配置UI通知路由标签匹配分组策略够用更强力的分组、抑制、静默运维负担随Grafana一起部署即可多一个组件多一份运维适合场景中小团队、混合数据源、快速上线大规模集群、复杂路由、高吞吐这里的核心区别在于架构位置。Grafana的告警引擎跑在Grafana服务内部以一个固定的评估间隔去查询数据源拿到结果后和阈值做对比然后产生状态转换Alertmanager则是接住Prometheus推送过来的alert事件再做后续路由它本身不负责判断阈值只负责“事件来了怎么通知出去”。所以说如果告警条件本身很复杂或者你有MySQL、Loki这些非Prometheus数据源也要一起告警那Grafana页面告警明显更方便一条规则里甚至可以直接写不同数据源的查询。1.2 什么场景适合直接上Grafana告警结合我自己的落地经验下面几类场景很适合直接用Grafana页面告警团队里同时存在Prometheus、Loki、MySQL等多种数据源想用一个平台统一告警入口。监控规则经常调阈值、改条件不想每次改完都去重载配置。需要快速看到告警状态、历史记录、触发曲线页面操作能省不少事。告警规则的量级在几百条以内不需要极大规模的路由树。反过来如果你在管理上万条指标、需要复杂的嵌套路由和动态抑制那还是老老实实用Alertmanager甚至上Thanos、VictoriaMetrics那边做全局告警编排Grafana这种“页面点一点”的模式会有点不够看。选型没有绝对好坏关键看你的规模和团队协作方式。我的建议是中小团队优先从Grafana页面告警起步等规则量真正上去、路由复杂度高到页面撑不住的时候再迁到Alertmanager也不迟Grafana侧导出规则JSON迁移成本是可控的。2. 告警规则配置的核心细节搞懂状态机才能少踩坑在我接手过的几个出问题的告警项目里十有八九不是“规则没配上”而是“配得不明白”。比如有人把触发的持续时间设置为0结果每次指标稍微抖一下就要收一条也有人把no data和error的行为选错数据源一断告警直接失联。要搞清楚这些得先理解Grafana告警的一条规则到底由什么构成。2.1 一条告警规则的组成部分一条Grafana告警规则本质上由四块组成查询条件、评估方式、标签、通知设置。其中最核心的是查询条件页面里通常用A、B、C这样的字母来区分多个表达式。A一般是数据查询比如PromQL写一条100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)用来算CPU使用率B可以对A的结果做数学处理比如累加、取平均C是一个阈值判断表达式写成$B 85就表示CPU使用率大于85%时命中了告警条件。这里要重点提一下表达式的类型。Grafana告警里常用的几个Threshold阈值判断是对前面查询结果做比较比如大于、小于、在区间内。Reduce把一段时间的时序数据折叠成一个值常用的聚合方式有mean、last、max、min。比如你查5分钟的CPU告警条件里拿mean还是max结果差异很大。Math对数字做数学运算也可以用$A $B这种方式组合多个查询。Resample重置时间粒度用得相对少但跨数据源对齐时有用。真实操作时在Alert rule编辑页里通常先添加数据源查询再Add expression选择Reduce或者Math最后再加一个Threshold表达式做最终判断。如果你直接跳过Reduce拿一个区间数据去做ThresholdGrafana会报错或者默认帮你处理但处理结果未必是你想要的。我见过有人配了个5分钟范围的查询阈值判断用大于85结果指标一直不下来查了半天发现Reduce默认取的是mean把瞬时峰值都平均掉了。2.2 告警状态机Normal、Pending、Alerting、NoData、ErrorGrafana的告警规则有一个明确的状态机理解它对排查告警非常重要状态含义Normal正常条件未满足Pending条件已满足但还没达到持续时长要求Alerting条件持续满足已经进入告警NoData查询没有返回数据Error查询或表达式执行出错状态之间是按“评估间隔”一跳一跳变化的。每到一个评估节点Grafana去数据源拉一次数据判断条件然后把状态推进一步。最关键的参数就是for它表示“条件满足后要持续多久才真正告警”。你把它设成5分钟等于告诉系统CPU连续5分钟都超过85%才算真出问题中间偶尔抖一下超过阈值不会触发告警。这个参数是防毛刺的利器生产环境我一般至少给3到5分钟除非是核心业务指标才会压到1分钟以内。NoData和Error这两个状态很容易被忽略。NoData的意思是查询返回空结果这不一定代表“没事”——很多情况下数据源挂了或者采集停了图表上看不到数据告警也没了那才最危险。所以NoData的行为建议显式配置常用做法是当NoData时也发一条告警至少让人知道“我看不到数据了”Error通常表示表达式写错或数据源异常我也建议设置成告警。默认行为有时候是“OK”也就是没数据时不打扰任何人但业务故障往往就藏在这种安静里。2.3 表达式与函数使用中的常见坑单位换算Grafana面板上的单位后缀只是显示用的告警计算时用的是数据源返回的原始值。比如node_exporter的网络流量返回的是bytes/sec你在面板上把单位改成MB/s看得很舒服但告警规则里写阈值时得用bytes/sec的原始数字去比否则会差出好几个数量级。多值返回告警条件期望拿到一个可比较的值。如果PromQL写了一个不带聚合的查询返回了多个seriesGrafana会为每个series分别评估多主机场景下你会看到同一个规则产生了多个告警实例这可能是你想要的也可能不是。建议用by (instance)或者sum先把要关注的维度定清楚。标签透传告警通知里的标签是从查询结果里透传过来的。你查询里保留的instance、job这些标签会出现在告警信息的labels里这对路由很有用所以规则里不要随手去掉标签后面配置通知策略时经常要用到。3. 从零配置一套页面告警联系点、通知策略、规则落地前面把原理讲透了下面进入实际操作。我以Grafana 10为例逐步走一遍配置流程。注意Grafana 8.0到8.x之间的版本用的是老版告警legacy alerting从9.0开始新版告警全面接管现在的版本基本都不用再考虑兼容问题。很多老帖子还在讲“Dashboard - Panel - Alert”的老入口新版位置已经移到左侧菜单的“Alerting”下规则配置界面也完全改了。3.1 前置准备数据源与版本要求配告警之前先把数据源确认好。在左侧菜单进入Connections - Data sources确认你的数据源状态是“Healthy”。如果这里都探测不通后面告警评估肯定也是失败的。另外Grafana告警默认的评估间隔是10秒到1分钟你可以在Alerting - Settings里改但这个值不宜太小评估太频繁会在大规模场景下给数据源造成压力。版本方面我建议至少用Grafana 9.5以上10.x更好。老版本8.x的legacy alerting界面和配置方式完全不同网上查教程的时候注意甄别看到“Dashboard - Panel - Alert”这种入口的文章基本都是老教程别照着配。如果你是从老版本升级上来的有可能会遇到第5章里说的legacy queries升级报错这个后面展开讲。3.2 第一步配置Contact Point联系点告警发到哪里去是通过Contact Point定义的。左边菜单Alerting - Contact points点“New contact point”。以邮件为例需要先配置Grafana的SMTP。在defaults.ini配置文件里找到[smtp]段按你的邮箱服务商填好[smtp] enabled true host smtp.example.com:465 user alertexample.com password your-password from_address alertexample.com from_name Grafana Alert startTLS_policy MandatoryStartTLS改完配置重启Grafana服务。然后在Contact point类型选Email填收件人地址点“Test”可以发一条测试通知。如果你用了钉钉、企业微信或自建系统那就选Webhook类型填一个回调地址Grafana会在告警触发时往这个地址POST一段JSON。Webhook的幂等性要做好——同一告警因为for满足后通知一次但状态从Pending进入Alerting时也会发如果你的回调逻辑不判别状态很容易产生重复消息。我见过不少自建消息服务被Grafana的测试消息或者重复告警刷屏就是因为没在代码里做状态过滤。3.3 第二步配置Notification Policy通知策略Contact Point是“发给谁”Notification Policy是“什么时候发、怎么发”。Grafana的默认策略是把所有告警发给default contact point你可以在Alerting - Notification policies里新建嵌套策略。拿我常用的一个场景举例规则里打了severitycritical标签的告警需要立刻发到值班群severitywarning的告警合并起来延迟一点发。做法是先在根策略下新建一个子策略匹配器写severitycritical联系点选“值班Webhook”再建一个匹配severitywarning的策略联系点选“邮件组”。Grafana的匹配器支持、!、~正则也支持多个标签同时匹配规则会按策略树的顺序从上往下匹配第一个匹配到的生效。如果你的告警没有打severity标签最后会落到默认策略所有告警都走默认联系点这是很多人“明明配了策略却还是发到默认邮箱”的原因——标签根本对不上。3.4 第三步配置告警规则规则配置在Alerting - Alert rules - New alert rule。我以一个node_exporter的CPU使用率告警为例。在步骤1的查询区域A查询写100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)然后Add expression添加一个Reduce表达式选择A查询聚合函数选mean再Add expression选Threshold输入框选B条件选IS ABOVE阈值填85。如果你用的Grafana版本较新表达式也可以用更简洁的写法直接进Threshold的输入框里填85。Folders选择存放规则的分类文件夹这一步别随便选规则权限是按文件夹隔离的团队大了之后这很重要。Evaluation group要指定一个评估组同一个组里的规则共用评估间隔我习惯把业务相关规则放一组这样它们会严格同步评估不至于出现时间差导致的误判。下面有几个关键配置项Pending period (for)刚才说过的持续时间CPU这种抖动量大的指标我一般设5m。No data行为选“Alerting”数据没了一样要通知。Error行为也选“Alerting”表达式执行出错要让人知道。Labels像severitycritical、teamplatform这种一定要打上因为通知策略靠它路由。养成“每条规则至少带severity和team两个标签”的习惯后面省很多事。保存之后规则会在下一个评估周期自动开始计算。3.5 第四步验证告警触发配好不等于结束一定要实测一轮。最快的办法是临时把阈值改低比如CPU阈值从85改成1然后去Alerting - Alert rules页面看规则的当前状态。如果一切正常几秒后会看到状态从Normal变成Pending持续for时间后变成Alerting。同时去Alerting - Instances里能看到具体的告警实例通知也应当在状态变成Alerting时发出去。验证完再把阈值改回去。我习惯用这个流程做每一次上线先看规则状态再看实例状态最后看通知是否到达。三步都在一个页面里很直观。确认没问题后再在通知策略里调整分组和重复频率。4. 告警静默、分组与多数据源实践配置好规则只是第一步真正用起来之后你还会面对“告警风暴”“维护窗口”“多数据源混合告警”这些实际问题。4.1 静默配置维护窗口期别再被打扰凌晨2点升级数据库DBA正在操作结果磁盘告警、连接数告警一个接一个整个值班群都在响——这种场景下静默能力就是刚需。Grafana的静默在Alerting - Silences里配置可以按时间范围和标签匹配器来屏蔽。我一般这样用先创建一条静默匹配器写servicemysql时间范围设为维护窗口的起止时间这样窗口内所有带servicemysql标签的告警都不会对外发送窗口一过自动恢复。静默优先级很高匹配到静默的告警不会进入通知策略所以用的时候要小心别把“匹配所有”写得太宽否则容易掩盖真实故障。4.2 分组和重复通知不被告警风暴淹没告警分组的作用是把同一时间段内、满足同一标签组合的告警合并成一条通知。Grafana默认分组按alertname分但实际使用中我更推荐把severity、team这类维度加进分组依据。举个例子一台机器上跑了20个MySQL实例磁盘满了20条规则同时触发如果不分组值班手机会连续响20次按instance和alertname分组后一次通知里会把这20条合并列出值班人员一眼就知道是这台机器整体出了问题而不是20个独立故障。通知策略里的Group wait和Group interval也值得说下。Group wait是同一组内新告警发通知前等待的时间目的是等更多同组告警聚合到一起我一般设30秒Group interval是同一组告警重复通知的最小间隔默认5分钟如果你觉得告警重复太吵可以拉到15分钟或者更长。真正要紧的核心指标我会单独建策略把Group interval压到1分钟保证每次都能第一时间知道。4.3 多数据源混合告警一条规则里接多个数据源Grafana告警的一个强项是能跨数据源写规则。比如你想判断“订单量下降是不是和数据库慢查询有关”A查询从Prometheus拿订单量B查询从MySQL数据源拿慢查询数C表达式做关联比较。这种混合查询在Prometheus原生规则里没法直接写但在Grafana页面告警里确实可以做。不过我要提醒一下跨数据源意味着跨时区、跨采集周期两边的数据粒度可能不一致Resample表达式在这种场景下会派上用场。同时规则评估时任何一个数据源出错都会影响整条规则所以Error行为一定要设置清楚。我的建议是能用单数据源解决的规则尽量不跨源只有确实难以拆分时才用避免故障时一个数据源抖动引发整套规则误报。5. 常见问题与排查技巧实录最后这部分我整理一下这几年实际遇到过的典型问题每个问题都给排查思路和解决办法基本可以当速查表用。5.1 告警不触发先到Alerting - Alert rules看规则是处于Normal、Pending还是其他状态。如果一直是Normal多半是查询没命中的条件。直接在规则的查询预览里跑一遍查询看返回的值是多少。很多人阈值写85实际值显示85.23就差一点点一直是Normal调整阈值方向就行。如果一直Pending说明for还没到把鼠标停上去能看到已经持续多久。还有一个隐蔽的坑是Reduce的聚合方式5分钟窗口内峰值很高但mean被拉低阈值永远打不到这种情况要改成max或者减少窗口。另外确认查询结果是不是多值返回多台主机时每台主机的值会独立参与判断你以为看的是平均值实际是某台主机的瞬时值这个差异要提前想清楚。5.2 规则状态一直是Error或NoDataError大概率是表达式写错了。比如$B 85引用了不存在的变量或者查询返回了非数值类型先把表达式逐个独立测试看每一步的输出是否符合预期。NoData常见原因是数据源探活失败或者是查询条件写得太严格标签过滤把目标实例过滤掉了。去数据源页面重新做一次测试确认查询有结果再看规则的Labels和查询是否匹配。还有一种情况是评估时间窗口设置得太短刚好落在数据缺口上把窗口稍微拉长一点就能解决。5.3 通知收不到先在Contact point里点Test。如果测试消息到了说明通知链路没问题问题多半在规则标签和通知策略的匹配上。检查告警实例的Labels看有没有多出你没见过的标签比如alertname是自动加上的你在策略里匹配的是alertnameCPU高但实际生成的alertname可能是查询名称对不上就发不出来。SMTP相关的报错去Grafana日志里搜关键词比如mail、smtp。常见原因是startTLS_policy设置不当或者是25端口被网络策略挡了换465或者改用MandatoryStartTLS能解决不少问题。如果用Webhook重点看回调服务的日志和返回码4xx是地址或参数问题5xx是服务端问题Grafana对通知失败会做有限次数的重试不要指望它无限重发。5.4 升级迁移的坑legacy queries报错热搜词里有一条grafana failed to upgrade legacy queries datasource im7_otuvz was not found这其实是从老版本Grafana升级后常见的问题。老版告警里规则保存的是数据源的旧引用方式用UID升级到新版后如果数据源的UID变化了或者规则里引用的数据源在目标实例上不存在升级时就会报“datasource not found”。排查思路是先确认规则引用的数据源UID是否还在Alerting - Contact points和Rules里如果看到失效引用重新选择数据源保存一次。如果规则数量很多建议在升级Grafana前先做一次规则备份方法很直接到Alerting - Alert rules用页面右上角导出规则为JSON文件升级完再导回来。5.5 避坑清单快速过一遍告警阈值和面板显示的单位可能不同计算时用数据源返回的原始值。for一定不要图省事设成0除非你真的需要瞬时告警。所有规则都打上severity和team标签通知策略才能正常路由。静态阈值告警设置NoData和Error的行为别让数据源故障变成“静默失联”。邮件、Webhook绑定的地址和回调一定要先Test别等真出故障了才发现填错了。最后再说一个我自己的使用习惯。告警规则新增时我喜欢在Labels里带上跟业务相关的维度比如apporder-center、envproduction这样后面无论是接通知策略、归档分析还是在页面上搜历史告警都方便得多。还有就是告警规则不是配完就不管了我每隔一段时间会翻一下Alerting - Alert rules看看有没有长期处于NoData或者一直被静默的规则该清理的清理、该调整阈值的调整。监控系统本身也是需要维护的你越早把告警配置当成一套正经的工程来做后面排障的时候就越轻松。 
长河君 · 2026/10/2 8:12:30 · 阅读 1.2k Grafana页面告警配置实战：从规则到通知的完整闭环
干监控这行时间长了你会发现一个挺尴尬的事实指标采集了大屏也做了图也美得不行结果线上出故障的时候第一个发现问题的往往是用户而不是监控系统。问题就出在告警这最后一公里。Grafana作为目前最主流的可视化监控平台之一早就不仅仅是画图工具了它的页面告警功能已经能承担完整的告警闭环规则配置、状态计算、通知触达全都能在网页上点出来这也是这两年我把团队告警入口逐步统一到Grafana的原因。这篇文章就围绕Grafana配置页面告警这件事展开从告警方案选型、规则配置的核心细节、通知渠道打通到实际的排障经验完整过一遍。适合刚接触监控告警的运维、后端开发也适合已经在用Prometheus但想把告警入口统一到Grafana里的团队。1. 告警方案选型为什么要把告警做到Grafana里先解决一个“为什么”的问题。很多人第一次接触监控告警是从Prometheus Alertmanager这套组合入手的这套组合很成熟告警规则用yaml写自带分组、抑制、静默配合Webhook能接到几乎所有通知渠道。那为什么还要用Grafana的页面告警我自己的体会是Prometheus的告警规则写起来不难但维护成本不低尤其是让一个不熟PromQL的同事去改阈值就比较劝退。Grafana的页面告警规则直接基于现有的Panel查询条件去配置先在图上看到数据长什么样再框一个条件流程高度可视化学习成本低很多。1.1 Grafana页面告警和Alertmanager的核心区别先看一张我使用下来整理的功能对比表对比项Grafana页面告警Prometheus Alertmanager规则管理方式页面配置所见即所得随时改文件编写改完要重载配置数据源范围Prometheus、Loki、MySQL、InfluxDB等统一接入主要面向Prometheus指标状态可视化规则和实例状态直接在页面看需要额外部署/配置UI通知路由标签匹配分组策略够用更强力的分组、抑制、静默运维负担随Grafana一起部署即可多一个组件多一份运维适合场景中小团队、混合数据源、快速上线大规模集群、复杂路由、高吞吐这里的核心区别在于架构位置。Grafana的告警引擎跑在Grafana服务内部以一个固定的评估间隔去查询数据源拿到结果后和阈值做对比然后产生状态转换Alertmanager则是接住Prometheus推送过来的alert事件再做后续路由它本身不负责判断阈值只负责“事件来了怎么通知出去”。所以说如果告警条件本身很复杂或者你有MySQL、Loki这些非Prometheus数据源也要一起告警那Grafana页面告警明显更方便一条规则里甚至可以直接写不同数据源的查询。1.2 什么场景适合直接上Grafana告警结合我自己的落地经验下面几类场景很适合直接用Grafana页面告警团队里同时存在Prometheus、Loki、MySQL等多种数据源想用一个平台统一告警入口。监控规则经常调阈值、改条件不想每次改完都去重载配置。需要快速看到告警状态、历史记录、触发曲线页面操作能省不少事。告警规则的量级在几百条以内不需要极大规模的路由树。反过来如果你在管理上万条指标、需要复杂的嵌套路由和动态抑制那还是老老实实用Alertmanager甚至上Thanos、VictoriaMetrics那边做全局告警编排Grafana这种“页面点一点”的模式会有点不够看。选型没有绝对好坏关键看你的规模和团队协作方式。我的建议是中小团队优先从Grafana页面告警起步等规则量真正上去、路由复杂度高到页面撑不住的时候再迁到Alertmanager也不迟Grafana侧导出规则JSON迁移成本是可控的。2. 告警规则配置的核心细节搞懂状态机才能少踩坑在我接手过的几个出问题的告警项目里十有八九不是“规则没配上”而是“配得不明白”。比如有人把触发的持续时间设置为0结果每次指标稍微抖一下就要收一条也有人把no data和error的行为选错数据源一断告警直接失联。要搞清楚这些得先理解Grafana告警的一条规则到底由什么构成。2.1 一条告警规则的组成部分一条Grafana告警规则本质上由四块组成查询条件、评估方式、标签、通知设置。其中最核心的是查询条件页面里通常用A、B、C这样的字母来区分多个表达式。A一般是数据查询比如PromQL写一条100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)用来算CPU使用率B可以对A的结果做数学处理比如累加、取平均C是一个阈值判断表达式写成$B 85就表示CPU使用率大于85%时命中了告警条件。这里要重点提一下表达式的类型。Grafana告警里常用的几个Threshold阈值判断是对前面查询结果做比较比如大于、小于、在区间内。Reduce把一段时间的时序数据折叠成一个值常用的聚合方式有mean、last、max、min。比如你查5分钟的CPU告警条件里拿mean还是max结果差异很大。Math对数字做数学运算也可以用$A $B这种方式组合多个查询。Resample重置时间粒度用得相对少但跨数据源对齐时有用。真实操作时在Alert rule编辑页里通常先添加数据源查询再Add expression选择Reduce或者Math最后再加一个Threshold表达式做最终判断。如果你直接跳过Reduce拿一个区间数据去做ThresholdGrafana会报错或者默认帮你处理但处理结果未必是你想要的。我见过有人配了个5分钟范围的查询阈值判断用大于85结果指标一直不下来查了半天发现Reduce默认取的是mean把瞬时峰值都平均掉了。2.2 告警状态机Normal、Pending、Alerting、NoData、ErrorGrafana的告警规则有一个明确的状态机理解它对排查告警非常重要状态含义Normal正常条件未满足Pending条件已满足但还没达到持续时长要求Alerting条件持续满足已经进入告警NoData查询没有返回数据Error查询或表达式执行出错状态之间是按“评估间隔”一跳一跳变化的。每到一个评估节点Grafana去数据源拉一次数据判断条件然后把状态推进一步。最关键的参数就是for它表示“条件满足后要持续多久才真正告警”。你把它设成5分钟等于告诉系统CPU连续5分钟都超过85%才算真出问题中间偶尔抖一下超过阈值不会触发告警。这个参数是防毛刺的利器生产环境我一般至少给3到5分钟除非是核心业务指标才会压到1分钟以内。NoData和Error这两个状态很容易被忽略。NoData的意思是查询返回空结果这不一定代表“没事”——很多情况下数据源挂了或者采集停了图表上看不到数据告警也没了那才最危险。所以NoData的行为建议显式配置常用做法是当NoData时也发一条告警至少让人知道“我看不到数据了”Error通常表示表达式写错或数据源异常我也建议设置成告警。默认行为有时候是“OK”也就是没数据时不打扰任何人但业务故障往往就藏在这种安静里。2.3 表达式与函数使用中的常见坑单位换算Grafana面板上的单位后缀只是显示用的告警计算时用的是数据源返回的原始值。比如node_exporter的网络流量返回的是bytes/sec你在面板上把单位改成MB/s看得很舒服但告警规则里写阈值时得用bytes/sec的原始数字去比否则会差出好几个数量级。多值返回告警条件期望拿到一个可比较的值。如果PromQL写了一个不带聚合的查询返回了多个seriesGrafana会为每个series分别评估多主机场景下你会看到同一个规则产生了多个告警实例这可能是你想要的也可能不是。建议用by (instance)或者sum先把要关注的维度定清楚。标签透传告警通知里的标签是从查询结果里透传过来的。你查询里保留的instance、job这些标签会出现在告警信息的labels里这对路由很有用所以规则里不要随手去掉标签后面配置通知策略时经常要用到。3. 从零配置一套页面告警联系点、通知策略、规则落地前面把原理讲透了下面进入实际操作。我以Grafana 10为例逐步走一遍配置流程。注意Grafana 8.0到8.x之间的版本用的是老版告警legacy alerting从9.0开始新版告警全面接管现在的版本基本都不用再考虑兼容问题。很多老帖子还在讲“Dashboard - Panel - Alert”的老入口新版位置已经移到左侧菜单的“Alerting”下规则配置界面也完全改了。3.1 前置准备数据源与版本要求配告警之前先把数据源确认好。在左侧菜单进入Connections - Data sources确认你的数据源状态是“Healthy”。如果这里都探测不通后面告警评估肯定也是失败的。另外Grafana告警默认的评估间隔是10秒到1分钟你可以在Alerting - Settings里改但这个值不宜太小评估太频繁会在大规模场景下给数据源造成压力。版本方面我建议至少用Grafana 9.5以上10.x更好。老版本8.x的legacy alerting界面和配置方式完全不同网上查教程的时候注意甄别看到“Dashboard - Panel - Alert”这种入口的文章基本都是老教程别照着配。如果你是从老版本升级上来的有可能会遇到第5章里说的legacy queries升级报错这个后面展开讲。3.2 第一步配置Contact Point联系点告警发到哪里去是通过Contact Point定义的。左边菜单Alerting - Contact points点“New contact point”。以邮件为例需要先配置Grafana的SMTP。在defaults.ini配置文件里找到[smtp]段按你的邮箱服务商填好[smtp] enabled true host smtp.example.com:465 user alertexample.com password your-password from_address alertexample.com from_name Grafana Alert startTLS_policy MandatoryStartTLS改完配置重启Grafana服务。然后在Contact point类型选Email填收件人地址点“Test”可以发一条测试通知。如果你用了钉钉、企业微信或自建系统那就选Webhook类型填一个回调地址Grafana会在告警触发时往这个地址POST一段JSON。Webhook的幂等性要做好——同一告警因为for满足后通知一次但状态从Pending进入Alerting时也会发如果你的回调逻辑不判别状态很容易产生重复消息。我见过不少自建消息服务被Grafana的测试消息或者重复告警刷屏就是因为没在代码里做状态过滤。3.3 第二步配置Notification Policy通知策略Contact Point是“发给谁”Notification Policy是“什么时候发、怎么发”。Grafana的默认策略是把所有告警发给default contact point你可以在Alerting - Notification policies里新建嵌套策略。拿我常用的一个场景举例规则里打了severitycritical标签的告警需要立刻发到值班群severitywarning的告警合并起来延迟一点发。做法是先在根策略下新建一个子策略匹配器写severitycritical联系点选“值班Webhook”再建一个匹配severitywarning的策略联系点选“邮件组”。Grafana的匹配器支持、!、~正则也支持多个标签同时匹配规则会按策略树的顺序从上往下匹配第一个匹配到的生效。如果你的告警没有打severity标签最后会落到默认策略所有告警都走默认联系点这是很多人“明明配了策略却还是发到默认邮箱”的原因——标签根本对不上。3.4 第三步配置告警规则规则配置在Alerting - Alert rules - New alert rule。我以一个node_exporter的CPU使用率告警为例。在步骤1的查询区域A查询写100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)然后Add expression添加一个Reduce表达式选择A查询聚合函数选mean再Add expression选Threshold输入框选B条件选IS ABOVE阈值填85。如果你用的Grafana版本较新表达式也可以用更简洁的写法直接进Threshold的输入框里填85。Folders选择存放规则的分类文件夹这一步别随便选规则权限是按文件夹隔离的团队大了之后这很重要。Evaluation group要指定一个评估组同一个组里的规则共用评估间隔我习惯把业务相关规则放一组这样它们会严格同步评估不至于出现时间差导致的误判。下面有几个关键配置项Pending period (for)刚才说过的持续时间CPU这种抖动量大的指标我一般设5m。No data行为选“Alerting”数据没了一样要通知。Error行为也选“Alerting”表达式执行出错要让人知道。Labels像severitycritical、teamplatform这种一定要打上因为通知策略靠它路由。养成“每条规则至少带severity和team两个标签”的习惯后面省很多事。保存之后规则会在下一个评估周期自动开始计算。3.5 第四步验证告警触发配好不等于结束一定要实测一轮。最快的办法是临时把阈值改低比如CPU阈值从85改成1然后去Alerting - Alert rules页面看规则的当前状态。如果一切正常几秒后会看到状态从Normal变成Pending持续for时间后变成Alerting。同时去Alerting - Instances里能看到具体的告警实例通知也应当在状态变成Alerting时发出去。验证完再把阈值改回去。我习惯用这个流程做每一次上线先看规则状态再看实例状态最后看通知是否到达。三步都在一个页面里很直观。确认没问题后再在通知策略里调整分组和重复频率。4. 告警静默、分组与多数据源实践配置好规则只是第一步真正用起来之后你还会面对“告警风暴”“维护窗口”“多数据源混合告警”这些实际问题。4.1 静默配置维护窗口期别再被打扰凌晨2点升级数据库DBA正在操作结果磁盘告警、连接数告警一个接一个整个值班群都在响——这种场景下静默能力就是刚需。Grafana的静默在Alerting - Silences里配置可以按时间范围和标签匹配器来屏蔽。我一般这样用先创建一条静默匹配器写servicemysql时间范围设为维护窗口的起止时间这样窗口内所有带servicemysql标签的告警都不会对外发送窗口一过自动恢复。静默优先级很高匹配到静默的告警不会进入通知策略所以用的时候要小心别把“匹配所有”写得太宽否则容易掩盖真实故障。4.2 分组和重复通知不被告警风暴淹没告警分组的作用是把同一时间段内、满足同一标签组合的告警合并成一条通知。Grafana默认分组按alertname分但实际使用中我更推荐把severity、team这类维度加进分组依据。举个例子一台机器上跑了20个MySQL实例磁盘满了20条规则同时触发如果不分组值班手机会连续响20次按instance和alertname分组后一次通知里会把这20条合并列出值班人员一眼就知道是这台机器整体出了问题而不是20个独立故障。通知策略里的Group wait和Group interval也值得说下。Group wait是同一组内新告警发通知前等待的时间目的是等更多同组告警聚合到一起我一般设30秒Group interval是同一组告警重复通知的最小间隔默认5分钟如果你觉得告警重复太吵可以拉到15分钟或者更长。真正要紧的核心指标我会单独建策略把Group interval压到1分钟保证每次都能第一时间知道。4.3 多数据源混合告警一条规则里接多个数据源Grafana告警的一个强项是能跨数据源写规则。比如你想判断“订单量下降是不是和数据库慢查询有关”A查询从Prometheus拿订单量B查询从MySQL数据源拿慢查询数C表达式做关联比较。这种混合查询在Prometheus原生规则里没法直接写但在Grafana页面告警里确实可以做。不过我要提醒一下跨数据源意味着跨时区、跨采集周期两边的数据粒度可能不一致Resample表达式在这种场景下会派上用场。同时规则评估时任何一个数据源出错都会影响整条规则所以Error行为一定要设置清楚。我的建议是能用单数据源解决的规则尽量不跨源只有确实难以拆分时才用避免故障时一个数据源抖动引发整套规则误报。5. 常见问题与排查技巧实录最后这部分我整理一下这几年实际遇到过的典型问题每个问题都给排查思路和解决办法基本可以当速查表用。5.1 告警不触发先到Alerting - Alert rules看规则是处于Normal、Pending还是其他状态。如果一直是Normal多半是查询没命中的条件。直接在规则的查询预览里跑一遍查询看返回的值是多少。很多人阈值写85实际值显示85.23就差一点点一直是Normal调整阈值方向就行。如果一直Pending说明for还没到把鼠标停上去能看到已经持续多久。还有一个隐蔽的坑是Reduce的聚合方式5分钟窗口内峰值很高但mean被拉低阈值永远打不到这种情况要改成max或者减少窗口。另外确认查询结果是不是多值返回多台主机时每台主机的值会独立参与判断你以为看的是平均值实际是某台主机的瞬时值这个差异要提前想清楚。5.2 规则状态一直是Error或NoDataError大概率是表达式写错了。比如$B 85引用了不存在的变量或者查询返回了非数值类型先把表达式逐个独立测试看每一步的输出是否符合预期。NoData常见原因是数据源探活失败或者是查询条件写得太严格标签过滤把目标实例过滤掉了。去数据源页面重新做一次测试确认查询有结果再看规则的Labels和查询是否匹配。还有一种情况是评估时间窗口设置得太短刚好落在数据缺口上把窗口稍微拉长一点就能解决。5.3 通知收不到先在Contact point里点Test。如果测试消息到了说明通知链路没问题问题多半在规则标签和通知策略的匹配上。检查告警实例的Labels看有没有多出你没见过的标签比如alertname是自动加上的你在策略里匹配的是alertnameCPU高但实际生成的alertname可能是查询名称对不上就发不出来。SMTP相关的报错去Grafana日志里搜关键词比如mail、smtp。常见原因是startTLS_policy设置不当或者是25端口被网络策略挡了换465或者改用MandatoryStartTLS能解决不少问题。如果用Webhook重点看回调服务的日志和返回码4xx是地址或参数问题5xx是服务端问题Grafana对通知失败会做有限次数的重试不要指望它无限重发。5.4 升级迁移的坑legacy queries报错热搜词里有一条grafana failed to upgrade legacy queries datasource im7_otuvz was not found这其实是从老版本Grafana升级后常见的问题。老版告警里规则保存的是数据源的旧引用方式用UID升级到新版后如果数据源的UID变化了或者规则里引用的数据源在目标实例上不存在升级时就会报“datasource not found”。排查思路是先确认规则引用的数据源UID是否还在Alerting - Contact points和Rules里如果看到失效引用重新选择数据源保存一次。如果规则数量很多建议在升级Grafana前先做一次规则备份方法很直接到Alerting - Alert rules用页面右上角导出规则为JSON文件升级完再导回来。5.5 避坑清单快速过一遍告警阈值和面板显示的单位可能不同计算时用数据源返回的原始值。for一定不要图省事设成0除非你真的需要瞬时告警。所有规则都打上severity和team标签通知策略才能正常路由。静态阈值告警设置NoData和Error的行为别让数据源故障变成“静默失联”。邮件、Webhook绑定的地址和回调一定要先Test别等真出故障了才发现填错了。最后再说一个我自己的使用习惯。告警规则新增时我喜欢在Labels里带上跟业务相关的维度比如apporder-center、envproduction这样后面无论是接通知策略、归档分析还是在页面上搜历史告警都方便得多。还有就是告警规则不是配完就不管了我每隔一段时间会翻一下Alerting - Alert rules看看有没有长期处于NoData或者一直被静默的规则该清理的清理、该调整阈值的调整。监控系统本身也是需要维护的你越早把告警配置当成一套正经的工程来做后面排障的时候就越轻松。