1. 为什么告警这件事值得单独拎出来聊监控系统搭起来只是第一步真正让一套监控产生价值的是告警能不能在故障发生的第一时间准确、清晰地送到该看到它的人手里。我见过太多团队Prometheus 的指标采集做得漂漂亮亮Grafana 面板也画得赏心悦目结果一出问题全靠用户反馈监控形同虚设。问题往往就卡在最后这一公里——告警发不出去或者发出去了没人看或者看的人被淹没在一堆噪音里。Alertmanager 就是 Prometheus 生态里专门负责这最后一公里的组件。它接收 Prometheus 推过来的告警做去重、分组、抑制、静默最后通过邮件、即时通讯工具等渠道发出去。邮件报警是最经典、最通用的一种方式几乎每家公司都有邮件系统不需要额外申请第三方服务配置一次就能长期用。但恰恰因为它看起来简单很多人在配置时踩了坑邮件发不出去、告警重复轰炸、关键告警被淹没、TLS 握手失败等等。这篇内容我会把 Alertmanager 邮件报警从原理到落地完整拆一遍包括配置文件的每一段为什么这么写、参数怎么算、常见故障怎么排查。适合已经搭好 Prometheus 但告警还没跑通的运维和开发同学也适合想把现有告警质量再提一档的老手。整套方案基于常见的开源组件组合不涉及任何特定厂商你可以直接抄作业。2. 告警链路整体设计与核心思路拆解2.1 从指标到邮件中间到底经过了什么很多人配邮件报警时是懵的因为不清楚数据流。我先把这条链路捋清楚后面配置的时候你才知道每一段在干什么。整条链路是这样的Prometheus 按照rule_files里定义的告警规则周期性地对采集到的指标做评估。当某个表达式持续满足条件超过for指定的时长Prometheus 就生成一条告警状态从inactive变成pending再变成firing。处于firing状态的告警会被推送到 Alertmanager。Alertmanager 收到后先做一轮处理相同内容的告警去重合并相关的告警按group_by分组被inhibit_rules命中的告警抑制掉处于静默期的告警丢弃。剩下的告警经过路由树route匹配找到对应的receiver最后通过 receiver 里配置的邮件通道发出去。理解这条链路的意义在于邮件发不出来问题可能出在链路的任何一环。可能是 Prometheus 根本没产生告警可能是 Alertmanager 没收到可能是路由没匹配上也可能是邮件通道本身的问题。排查的时候要顺着链路一段段验证而不是盯着邮件配置死磕。2.2 为什么选邮件以及它的边界在哪邮件报警的优势很明确基础设施现成、成本几乎为零、有天然的存档和检索能力、适合发送需要留痕的告警。对于中小团队或者作为告警的兜底渠道邮件是非常务实的选择。但邮件的短板也要心里有数。第一是时效性邮件从发出到被人看到中间可能隔着几分钟甚至更久不适合对响应速度要求极高的场景。第二是容易被忽略如果告警量大收件箱很快就会被淹没人会产生告警疲劳。第三是移动端体验一般半夜收到邮件爬起来处理体验远不如即时通讯工具。所以我的建议是邮件作为基础渠道和存档渠道保留同时根据团队实际情况叠加即时通讯工具作为快速响应渠道。两者不是替代关系而是互补。这篇内容聚焦邮件但你在设计告警体系时要把这个分层思路考虑进去。2.3 分组、抑制、静默三个让告警不扰民的关键机制Alertmanager 最核心的价值不是发告警而是聪明地发告警。如果只是把 Prometheus 的告警原样转发那要 Alertmanager 干嘛真正让它有价值的是三个机制。分组grouping解决的是告警风暴问题。想象一下数据库挂了依赖它的十几个服务同时报错如果每条告警都单独发一封邮件你的收件箱瞬间爆炸。分组机制把同一类告警合并成一封邮件group_by里指定的标签相同的告警会被归到一组group_wait控制等待多久凑够一批再发group_interval控制同一组后续有新告警时多久发一次repeat_interval控制同一组告警多久重复提醒一次。抑制inhibition解决的是因果告警问题。当一台主机宕机时它上面所有服务的告警其实都是同一个根因导致的没必要全部发出来。抑制规则可以配置成当某条严重告警触发时抑制掉由它引起的其他告警。静默silence解决的是计划内维护问题。你要做一次发布或者迁移期间必然产生告警提前配置静默就能避免误报。静默可以通过 Alertmanager 的 Web 界面临时创建也可以走 API。这三个机制配合好了告警的噪音能降一个数量级。很多人抱怨告警太多其实不是告警本身多而是没用上这些机制。3. 核心配置细节逐段拆解与实操要点3.1 Alertmanager 主配置文件的骨架Alertmanager 的配置文件默认是 YAML 格式启动时通过--config.file指定。整个文件由几个顶层字段组成global、route、inhibit_rules、receivers、templates。我先把骨架列出来然后逐段讲。global: resolve_timeout: 5m smtp_smarthost: smtp.example.com:587 smtp_from: alertmanagerexample.com smtp_auth_username: alertmanagerexample.com smtp_auth_password: your_password_or_token smtp_require_tls: true route: receiver: default-email group_by: [alertname, cluster, service] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: critical-email repeat_interval: 1h receivers: - name: default-email email_configs: - to: ops-teamexample.com send_resolved: true - name: critical-email email_configs: - to: oncallexample.com send_resolved: true inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [alertname, instance]这个骨架已经能跑起来了但每一段都有讲究下面拆开说。3.2 global 段SMTP 参数怎么填才不出错global段里的 SMTP 配置是邮件能否发出去的关键。这里几个参数我逐个说。smtp_smarthost是邮件服务器的地址和端口。这里有个坑端口选 465 还是 587465 是 SMTPS从连接建立就是加密的587 是 SMTP 加 STARTTLS先明文连接再升级为加密。Alertmanager 的smtp_require_tls默认是 true配合 587 端口使用 STARTTLS 是最常见的组合。如果你用 465需要确认 Alertmanager 版本是否支持隐式 TLS老版本可能有问题。我一般推荐 587。smtp_from是发件人地址很多邮件服务器会校验这个地址必须和认证账号一致否则拒收。所以最好和smtp_auth_username保持一致。smtp_auth_password这里要特别注意如果你用的是主流邮件服务商很多已经不支持直接用登录密码做 SMTP 认证了需要单独生成一个授权码或应用专用密码。这个密码通常是一串随机字符和你的登录密码不同。我第一次配的时候就是卡在这里一直报认证失败后来才发现要用授权码。smtp_require_tls建议保持 true。如果内网邮件服务器不支持 TLS才设为 false但生产环境强烈建议用 TLS。还有一个容易被忽略的参数是smtp_hello它指定 EHLO 时发送的主机名。某些严格的邮件服务器会校验这个值如果 Alertmanager 所在主机的主机名不规范可能被拒。遇到奇怪的拒收问题时可以显式设置成你的域名。3.3 route 段路由树是告警分发的指挥中心route段决定了告警往哪发。它是一棵树根节点是默认路由子节点通过match或match_re匹配特定告警。group_by是最影响体验的参数。它决定了哪些告警会被合并到一封邮件里。常见的做法是按alertname、cluster、service、severity这些维度分组。分得太细邮件就多分得太粗一封邮件里塞了几十条不相关的告警读起来费劲。我的经验是alertname必加这样同类告警会合并再加上业务维度比如service或job让不同服务的告警分开。group_wait是首次发送一组告警前的等待时间默认 30 秒。它的作用是给同一批告警一点聚集的时间避免刚发一封又来一封。如果告警产生很密集可以适当调大比如 1 分钟。group_interval是同一组告警在已有通知发出后又有新告警加入时多久发一次更新。默认 5 分钟比较合理。repeat_interval是同一组告警在没有任何变化的情况下多久重复提醒一次。这个参数直接决定了你会不会被骚扰。默认 4 小时对于 critical 告警可以缩短到 1 小时对于 warning 可以拉长到 12 小时甚至 24 小时。我见过有人设成 5 分钟结果一天收到几百封重复邮件直接把邮件渠道废掉了。子路由的匹配用match做精确匹配match_re做正则匹配。注意match是精确相等不是包含。比如severity: critical只会匹配 severity 标签值恰好是 critical 的告警。如果要匹配多个值用match_re配合正则。3.4 receivers 段邮件接收方的细节配置receivers定义了告警最终发到哪里。每个 receiver 有个名字被 route 引用。邮件类型的 receiver 用email_configs配置。to字段是收件人多个收件人用逗号分隔。这里有个实用技巧可以配合headers字段设置Subject让邮件标题更清晰。默认的邮件标题格式是[FIRING:数量] 告警名 (标签)信息量够但不够醒目。你可以自定义成带环境标识的格式方便在收件箱里一眼区分。send_resolved控制告警恢复时是否发送恢复邮件。这个强烈建议设为 true。没有恢复邮件你永远不知道告警是好了还是还在持续只能去 Prometheus 界面查非常低效。html字段可以指定邮件正文用 HTML 模板配合templates段加载自定义模板文件能让邮件排版好看很多。默认的纯文本邮件信息密度低关键信息不突出。花点时间做个 HTML 模板把告警名、严重级别、实例、描述、发生时间用表格排出来阅读效率提升明显。require_tls是 receiver 级别的 TLS 开关一般不用单独设继承 global 即可。3.5 inhibit_rules 段抑制规则怎么写才不误伤抑制规则的核心逻辑是当 source 匹配的告警存在时target 匹配的告警被抑制。equal字段指定哪些标签必须相等才触发抑制。举个典型场景主机宕机告警alertname: HostDownseverity: critical触发时抑制这台主机上所有其他告警。配置如下inhibit_rules: - source_match: alertname: HostDown target_match_re: alertname: . equal: [instance]equal: [instance]保证只有同一台主机的告警被抑制不会误伤其他主机。这里最容易踩的坑是equal标签选错。如果选了alertname那只有同名告警才会被抑制基本没意义。如果选了一个很多告警都没有的标签抑制也不会生效因为标签缺失时视为不相等。所以equal里的标签必须是 source 和 target 都有的且能唯一标识因果关系的维度。另一个坑是抑制规则写得太宽泛把该发的告警也抑制了。比如用severity: critical作为 sourceseverity: warning作为 targetequal只写instance那只要有一个 critical 告警同实例的所有 warning 都被压掉可能掩盖真实问题。抑制规则要保守宁可多发几条也别漏掉关键信息。4. 完整实操流程与关键环节实现4.1 环境准备与版本确认动手之前先确认组件版本不同版本的配置字段有差异。Alertmanager 0.22 之后配置格式基本稳定但一些细节比如smtp_require_tls的默认值、match_re的语法在不同版本间有过调整。用alertmanager --version确认版本对照官方文档核对字段。Prometheus 侧要确认alerting段配置了 Alertmanager 的地址alerting: alertmanagers: - static_configs: - targets: - alertmanager:9093以及rule_files指向了告警规则文件。这两处没配好Alertmanager 根本收不到告警邮件配置再对也没用。4.2 编写告警规则文件告警规则文件是 Prometheus 格式的 YAML用groups组织。每条规则包含alert告警名、exprPromQL 表达式、for持续时间、labels附加标签、annotations描述信息。groups: - name: host-alerts rules: - alert: HostHighCpuLoad expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 5m labels: severity: warning service: host annotations: summary: 主机 CPU 负载过高 (实例 {{ $labels.instance }}) description: CPU 使用率已持续 5 分钟超过 80%当前值 {{ $value }}%。for字段很关键它避免了瞬时抖动触发告警。CPU 偶尔飙一下很正常持续 5 分钟才值得关注。这个值要根据指标特性调整磁盘空间这种缓慢变化的可以设长一点服务存活这种要快速响应的可以设短一点。annotations里的summary和description会出现在邮件正文里写清楚点让收到邮件的人不看面板就知道发生了什么。{{ $labels.xxx }}和{{ $value }}是模板变量会被替换成实际值。4.3 配置 Alertmanager 并启动把前面讲的配置写进alertmanager.yml然后用amtool check-config alertmanager.yml做语法校验。这个命令能提前发现大部分格式错误比启动后看日志快得多。启动命令alertmanager --config.filealertmanager.yml \ --storage.path/var/lib/alertmanager \ --web.listen-address:9093--storage.path指定数据目录Alertmanager 需要持久化静默状态和通知记录这个目录要保证可写且不会被随意清理。启动后访问http://host:9093能看到 Web 界面。在Status页面可以查看当前配置确认加载的是你期望的内容。4.4 端到端验证从触发到收邮件配置完别急着等真实故障主动造一个告警验证链路。最简单的方法是临时写一条必然触发的规则比如expr: vector(1) 0for: 0m。这条规则会立即触发。触发后按顺序检查Prometheus 的Alerts页面确认告警状态是firing。Alertmanager 的 Web 界面确认收到了这条告警。检查邮件是否到达收件箱注意看垃圾邮件文件夹。如果 Prometheus 有告警但 Alertmanager 没有检查alerting段配置和网络连通性。如果 Alertmanager 有告警但邮件没发出看 Alertmanager 日志里的 SMTP 报错信息。4.5 邮件模板定制默认邮件模板信息够用但不够好看。自定义模板需要两步在配置里加templates段指向模板文件在 receiver 里用html字段指定用哪个模板。templates: - /etc/alertmanager/templates/*.tmpl模板文件用 Go template 语法。一个实用的 HTML 模板会把告警按严重级别用不同颜色标注把关键字段用表格列出。这块内容展开能写很多核心思路是让收件人在不点开任何链接的情况下3 秒内判断出这是什么级别的告警、影响什么、要不要马上处理。5. 常见问题与排查技巧实录5.1 邮件发送失败排查速查表现象可能原因排查方法日志报authentication failed密码错误或用了登录密码而非授权码确认是否需要用应用专用密码重新生成日志报connection refused地址或端口错误或防火墙拦截telnet 测试端口连通性日志报TLS handshake failedTLS 配置不匹配尝试调整smtp_require_tls确认端口与加密方式匹配日志报sender address rejected发件人地址不被服务器接受确认smtp_from与认证账号一致邮件进了垃圾箱发件域名缺少 SPF/DKIM 记录联系邮件管理员配置域名认证告警触发但无邮件路由未匹配或 receiver 配置错误用amtool检查路由匹配结果5.2 告警重复轰炸怎么治重复告警基本是repeat_interval设太短或者group_by没配好导致同一问题被拆成多条。先检查repeat_intervalcritical 设 1 小时、warning 设 12 小时是比较舒服的节奏。再看group_by确保同类告警能合并。如果同一台机器的同一个问题因为标签不同被拆成多条检查是不是某个标签值在变化比如instance里带了端口号导致每次都不一样。还有一种情况是告警在 firing 和 resolved 之间反复横跳这叫告警抖动。根源通常是for设太短或者阈值卡在临界值附近。解决办法是加长for或者用avg_over_time之类的函数平滑指标。5.3 关键告警被淹没的处理思路如果 critical 告警经常被 warning 淹没说明路由没分层。正确做法是给 critical 单独配一个 receiver发给专门的 oncall 邮箱和日常 warning 分开。同时用抑制规则让 critical 触发时压掉相关的 warning。另一个技巧是利用邮件客户端的过滤器把来自 Alertmanager 的 critical 邮件自动打标签或标星这样在收件箱里一眼就能看到。这个在客户端侧配置不涉及 Alertmanager但效果立竿见影。5.4 我踩过的几个坑第一个坑是smtp_require_tls和端口不匹配。我用 465 端口配了smtp_require_tls: true结果一直握手失败换成 587 就好了。后来查文档才明白 465 是隐式 TLS和 STARTTLS 是两套机制。第二个坑是group_by里放了instance导致每台机器的告警都单独成组邮件数量爆炸。后来把instance从group_by里去掉只在annotations里展示邮件数量立刻降下来。第三个坑是测试时用vector(1)造告警忘了删结果这条规则一直在触发半夜收到一堆邮件。所以测试规则一定要记得清理或者给它加个明显的标签方便识别。第四个坑是邮件模板里的变量名写错导致邮件正文显示{{ $labels.xxx }}原样输出。模板变量区分大小写$labels和$Labels不一样写的时候要仔细。6. 告警质量持续优化的几个方向配置跑通只是起点告警质量是需要持续打磨的。我分享几个实际用下来有效的方向。第一定期回顾告警。每周花十分钟看看这周发了哪些告警哪些是误报哪些是重复哪些是没人处理的。误报的调整阈值或加长for重复的优化分组没人处理的要么是告警不重要该删要么是流程有问题该改。第二给告警分级。不是所有告警都值得半夜叫人。我一般分三级critical 立即通知 oncallwarning 工作时间通知info 只记录不通知。分级标准要和团队达成共识不能一个人拍脑袋。第三告警描述要写清楚怎么办。很多告警只说了什么坏了没说怎么处理。在annotations里加上处理建议或者排查链接能大幅缩短响应时间。比如磁盘满了直接写上清理命令或者扩容流程的链接。第四定期测试告警链路。邮件服务器会变、密码会过期、网络策略会调整告警链路不是配一次就一劳永逸的。我习惯每月主动触发一次测试告警确认整条链路还通。这个习惯帮我提前发现过好几次密码过期的问题避免了真实故障时告警发不出去的尴尬。第五控制告警总量。有个经验值可以参考一个健康的系统oncall 人员每天收到的告警邮件不应该超过 10 封。超过这个数要么是系统真有问题要么是告警配置太敏感。前者该修系统后者该调告警。告警疲劳是监控体系最大的敌人一旦人对告警麻木了再完善的监控也白搭。这套邮件报警方案我在几个不同规模的团队都用过从几个人的小团队到几十人的运维组核心配置基本一致差别主要在路由分层和告警分级的粒度上。小团队可以简单点一个 receiver 搞定大团队就要把路由树设计得细一些配合值班表做轮转。但不管规模大小先把链路跑通、再逐步优化质量这个路径是通用的。
