做运维这行监控搭起来只是第一步真正让人半夜从床上弹起来的永远是那条没发出去的报警。我见过太多环境Zabbix 的图做得漂漂亮亮触发器写得严丝合缝结果主机真挂了收件箱里一篇寂静——问题不在监控在邮件发送设置这一环断了。这套东西看着简单无非是填个服务器地址、填个账号密码但真正落地的时候授权码、端口、连接加密方式、动作条件、用户媒介的严重性过滤、前端 URL任何一处写错报警就静默失联。这篇是我在 Zabbix 系列里专门讲邮件发送设置的第十篇把从发件账号准备、媒介类型配置、用户绑定、动作编排到脚本媒介直连、排错和降噪这一整条链路拆开讲清楚适合刚把 Zabbix 跑起来的新手也适合用了两三年但一直被报警没收到折磨的老手。1. 邮件报警这条链路先把它拆成四段很多人配邮件失败不是因为某一步操作错了而是脑子里没有一张完整的地图不知道数据在哪个环节被丢掉了。我习惯在动手之前先把这条链路画在纸上一共四段第一段是触发器判定事件生成第二段是动作Action做条件匹配决定这个事件要不要发、发给谁、分几步发第三段是用户媒介Media把这个人和这个通道和这个邮箱地址绑在一起第四段才是媒介类型Media type真正拿 SMTP 去投递。四段里任何一段断了你在邮箱里都看不到东西但排查的位置完全不同。1.1 一条报警邮件从触发器到收件箱的旅程先说这条旅程的细节。某个监控项采集到一个值触发器表达式成立Zabbix 在 events 表里生成一条事件严重性标记为 Warning 或 Disaster。事件生成之后Zabbix Server 会去扫描启用的触发器动作逐条比对条件主机属于哪个主机组、触发器名字里有没有包含关键字、事件的严重性是否达到阈值。条件全部匹配这个动作才算认领了这个事件。接着动作去查它配置的操作Operations操作里通常写的是发送消息给某个用户组或发送消息给某个用户这里的用户最终会解析成用户身上挂的所有媒介。关键就在这里如果这个用户名下没有配置任何媒介或者配了媒介但媒介的启用时间和严重性过滤把这个事件挡掉了那么动作执行到这一步会直接跳过日志里连报错都没有你会以为动作没生效其实是用户没接收。最后一步媒介类型拿着收件地址去投递走内置 Email 媒介就是 Zabbix Server 直接跟 SMTP 服务器对话走脚本媒介就是 Server 调用你放在 AlertScriptsPath 下面的脚本由脚本自己去发信。这条链路我之所以反复强调是因为它决定了一个排查顺序。收到没报警的反馈我会按从后往前的顺序查先看邮箱有没有进垃圾箱再看 Server 日志里 alerts 相关的记录再看用户媒介有没有被严重性筛掉最后才回头看动作条件。反过来查往往在动作里折腾半天结果问题是用户身上根本没挂邮箱。1.2 为什么我建议先用内置 Email 媒介而不是一上来就写脚本网上教程一搜一大把很多人上来就教你写一个 Python 脚本挂在媒介类型里。我不反对这个做法但我建议先把内置的 Email 媒介跑通。原因有三点。一是内置媒介的配置全部在数据库和前端界面里改参数不用登服务器不用重启出问题也好回滚二是内置媒介由 Zabbix Server 进程直接投递没有脚本解释器、文件权限、路径这些额外的变量排错面窄三是内置媒介支持 SSL/TLS 和用户名密码认证主流的邮箱服务都能直连绝大多数场景根本不需要脚本。那什么时候必须用脚本我总结了几种情况需要抄送多个收件人但不想建多个用户需要按告警级别动态改收件人需要把邮件发到某个内部系统而不是真正的邮箱需要做复杂的正文拼装比如把多个监控项的值拼成一张表或者老版本的 Zabbix 内置媒介只支持本地 sendmail而你的环境又必须走外部 SMTP 认证。这些场景下脚本媒介才有价值。先把简单的路走通再上复杂的方案这是我在生产环境里养成的习惯。注意无论用哪种方式先把能让一封测试邮件从 Zabbix 发到自己邮箱这件事做成再去配业务动作。顺序反了你会同时面对两个未知变量。2. 发件账号怎么选授权码、发信量与企业邮箱的边界发件账号是整个链路里最容易被低估的一环。很多人随手拿一个私人邮箱当发件人跑测试没问题一上生产就被退信或者被对方的反垃圾策略拦掉。报警邮件的特点很鲜明突发流量大、内容格式高度重复、发件频率不稳定这几条几乎每一条都踩在反垃圾策略的敏感点上。所以选发件源不能只看能不能发出去要看高峰期能不能稳定发出去。2.1 三类常见发件源的优缺点对比我把常见的发件源分成三类用表格对比更直观发件源类型优点主要限制适用场景公共邮箱个人免费邮箱开通零成本SMTP 地址固定认证简单有每日发信量限制突发大量发信易被限流或封禁发件人信誉低测试环境、小规模环境、个人学习企业邮箱有独立域名发件人可信度较高发信量配额相对宽松需要管理员开通 SMTP 权限部分服务默认关闭该功能中小型生产环境几十到几百台主机自建邮件服务完全自主可控无第三方配额需要自己做域名解析、发件人验证、IP 信誉维护运维成本高大型环境、有专职邮件运维的团队大部分中小团队我的建议是走企业邮箱。它介于两者之间开通成本低发件人带企业域名收件方的反垃圾系统对它的容忍度明显高于免费邮箱。自建邮件服务听着很酷但那是另一个专业领域域名验证、反向解析、IP 预热这些活儿足够再写十篇文章监控团队没必要把精力砸在这上面。2.2 授权码不是登录密码这一步错了后面全白搭这是新手最容易栽的坑也是最不值得栽的坑。现在几乎所有主流邮箱服务在第三方客户端登录时都不再接受账号的登录密码而是要求你单独生成一个授权码或应用专用密码。这个码通常是一串随机字符生成位置在邮箱网页版的设置里一般叫客户端授权应用密码IMAP/SMTP 服务之类。你拿登录密码去填 Zabbix 的密码字段结果一定是认证失败。我这里给出一个通用的排查思路。认证失败时先确认是不是用了授权码确认之后再看这个邮箱服务有没有单独开关 SMTP 功能有些服务默认只开了网页收发SMTP 需要手动打开打开之后注意授权码生成后是否只显示一次如果没记下来就得重新生成。还有一点容易被忽略部分邮箱服务在异地或新设备登录时会触发安全验证第一次用 Zabbix 发信可能被临时拦截需要去邮箱的登录记录里确认一下把这个新登录标记为可信。注意授权码属于敏感凭据配置完之后建议定期轮换。Zabbix 数据库里存的是明文媒介类型参数不是加密字段所以数据库的访问权限要控制好。3. Zabbix 端邮件媒介配置全流程发件账号准备好接下来才是 Zabbix 这边的活儿。整个配置我按检查基础条件、配媒介类型、绑用户媒介三步走。顺序不要换因为媒介类型配错了绑用户那一步测出来也是失败的反而多绕一圈。3.1 先确认服务端具备的基础条件动手之前有几个前置条件要确认。第一Zabbix Server 到 SMTP 服务器的网络要通包括端口方向。SSL/TLS 通常用 465 端口STARTTLS 通常用 587明文用 25这三个端口很多企业网络默认是封的需要提前开通。检查方法很土但很有效直接在 Server 上用 telnet 或 nc 去连一下目标端口能建立连接说明网络层没问题。第二确认 Zabbix Server 的版本。内置 Email 媒介支持直接填 SMTP 服务器、连接加密方式、用户名密码认证这些能力是在较新的版本上才完整的如果你手上是比较老的版本内置媒介可能只支持调用本机 sendmail那就得走脚本或者装本地邮件服务。具体看界面里媒介类型有没有SMTP serverConnection securityAuthentication这几项有就说明可以直接配没有就得换方案。第三确认 AlertScriptsPath 的位置如果你打算用脚本媒介的话。这个路径在 Server 配置里定义默认在安装目录下的 alertscripts 子目录。用grep AlertScriptsPath /etc/zabbix/zabbix_server.conf就能看到或者直接去 Server 启动日志里翻启动时会把实际生效的路径打出来。这个路径搞错脚本媒介会一直报脚本不存在。3.2 内置 Email 媒介参数逐项拆解进入前端菜单在 Alerts告警下面的 Media types媒介类型找到默认的 Email 那一条点进去改。这里的参数我逐项说每项都告诉你为什么这么填SMTP server填发件邮箱服务商给你的 SMTP 地址不要填网页版的域名也不要带 http 前缀。填错会出现连接超时或域名解析失败。SMTP server port跟连接加密方式必须配套。选 SSL/TLS 就填 465选 STARTTLS 就填 587选 NONE 就填 25。这三个搭配错一个表现就是连接被重置或者握手失败。我遇到过把 465 配成 STARTTLS 的情况日志里报的是 TLS 握手异常跟网络不通的报错完全不一样靠报错内容就能区分。SMTP helo这个参数是给 SMTP 服务器打招呼用的域名。很多服务不校验但有些严格的服务会检查它跟发件域名是否一致不一致直接拒收。我的习惯是填发件邮箱的域名部分比如发件人是 opsexample.com这里就填 example.com。SMTP email发件人地址必须跟认证用的账号保持一致。不一致的话部分服务会报发件人与认证账号不符这是很典型的一种退信原因。Connection security三选一就是上面说的 NONE、STARTTLS、SSL/TLS。没有特殊要求就选 SSL/TLS省心。Authentication选 Normal username and password然后填账号和授权码。老版本可能只有 NONE那说明这个版本不支持认证得换方案。Message format选 HTML 的话正文可以带格式化内容选 Plain text 就是纯文本。我一般选 HTML因为可以把多个监控项的值排成表格读起来清爽很多但要注意有些内部邮件网关会剥掉 HTML 部分那就退回纯文本。Enabled这个勾一定要打上。我见过不止一次参数填得完美无缺就是忘了勾启用然后花一个小时查网络。配完之后界面右上角一般有个 Test 按钮可以直接填收件人地址测一发。这个测试走的是 Server 的真实投递路径比你在服务器上手敲命令更接近生产情况强烈建议先点它。3.3 用户媒介Media绑定与严重性过滤媒介类型配好不代表任何人能收到邮件还得去用户身上挂。路径是 Users用户→ 选中具体用户 → Media 标签页 → Add。这里要填三项一是Type选刚才那个 Email二是Send to填收件邮箱地址多个地址用逗号分隔三是When active这是接收时间段格式是 天-时:分-时:分。默认 1-7,00:00-24:00 表示全天全周接收。如果你的值班是轮班制这里可以精确控制比如只让某个人在工作时间收信夜间的报警交给另一个人。还有一个特别容易被忽略的开关就是Enabled。新增媒介之后列表里有个 Enabled 列默认是勾上的但如果你是从别的地方复制过来的要确认一下。另外Use if severity这一排勾选框才是真正的分水岭。它会按事件的严重性过滤没勾的级别不会发到这个邮箱。默认情况下高优先级基本都是勾上的但如果你手动取消过或者从别的模板继承过来一个奇怪的配置就会出现某些级别收不到的诡异现象。我个人的习惯是分两个邮箱一个平时用的邮箱只勾 High 以上避免日常噪音一个团队公共邮箱勾全级别做归档和审计用。这样既保证关键报警一定有人看见又不会让每个人都被 Info 级别的信息淹没。注意Send to 字段里如果填了多个地址实际上是一条邮件带多个收件人。有些服务对单封邮件的收件人数量有限制超过会被拒。需要发给很多人时更好的做法是建一个用户组让动作发给用户组由多个人各自接收。4. 动作Action配置决定谁在什么条件下收到什么媒介和用户都配好最后一环是动作。这一环是报警发不发得出去的总闸门也是最容易被默认配置坑到的地方。新版 Zabbix 里系统自带的那个给管理员报告故障的动作默认是关闭状态的。也就是说你前面所有配置都完美只要这个动作没启用一封邮件都不会发。这个设定很多人第一次碰到会懵我当年也是盯着日志看了半天才反应过来。4.1 触发器动作的条件组合动作的核心是条件Conditions。条件决定这个动作认领哪些事件条件写得太严会导致漏报写得太松会导致误报泛滥。常用的条件类型有几种Host group限定主机组。这是最常用的把某个业务组的主机单独配置报警策略。Trigger severity限定严重性下限。比如只处理 Warning 及以上忽略 Information。Trigger name或Trigger按触发器名字做匹配或精确指定。适合给某几个核心触发器单独定制通知方式。Event type区分问题事件、恢复事件、更新事件。Tag新版里非常推荐的方式给触发器打标签动作按标签匹配。这个方式的好处是解耦——触发器升级改名字不会影响动作运维分类也更清晰。条件的逻辑关系有两种AND 和 OR。默认是 AND意味着全部满足才匹配。实际使用中我建议条件控制在三到四条以内条件越多排查起来越痛苦而且不同条件之间的交互很容易出现你没预料到的结果。用标签来组织是更现代的思路我现在的环境基本都用标签做主维度。4.2 故障、恢复、更新三类操作分别写什么动作里的操作分三个区域很多人只配了第一个结果只有故障邮件、没有恢复邮件运维同事只能靠猜这事儿到底好了没。Operations操作是故障发生时执行的动作。典型配置是发送消息给用户组消息内容用变量拼装。默认的模板大概是故障开始时间 {EVENT.TIME}、故障名称 {EVENT.NAME}、主机 {HOST.NAME}、严重性 {EVENT.SEVERITY}、事件 ID {EVENT.ID}。这些变量在发送时会被替换成实际值所以你不用管具体内容只要把模板写好就行。Recovery operations恢复操作是故障恢复时执行的动作。这里的变量前缀会变成 EVENT.RECOVERY比如 {EVENT.RECOVERY.TIME}、{EVENT.DURATION}故障持续时长。我强烈建议把持续时长加上因为运维复盘的时候这个故障持续了多久往往比什么时候开始更重要。Update operations更新操作是事件状态变化时执行的动作比如有人确认了故障、有人手动关闭了故障、故障级别被手动调整了。这类操作默认是空的如果你的团队有确认即通知的协作习惯可以打开它让相关人知道已经有人在处理了避免重复排查。注意恢复操作和更新操作是独立的开关不是从操作里自动继承的。只配了操作没配恢复操作是非常常见的半成品配置。4.3 升级Escalation让告警真正被看见单发一封邮件的问题在于它假设收件人一定会看。现实中凌晨三点的邮件大概率躺在收件箱里没人管。升级机制解决的就是这个问题。在操作里你可以配置多个步骤Step每个步骤指定不同的发送目标并设置步骤之间的间隔。比如第一步立即发给值班工程师第二步在 15 分钟后如果故障还在发给值班工程师的主管第三步在 30 分钟后发给团队公共邮箱。配置升级的时候有几个细节要注意。第一步骤的编号和持续时间要算清楚比如步骤 1 立即执行步骤 2 从第 15 分钟开始这里的 15 分钟是相对于故障开始时间的不是相对于上一步的。第二升级间隔不要太密太密会把所有人的邮箱炸掉反而降低大家对报警的敏感度。第三升级的最后一环一定要有人兜底否则升级到了无人接收的终点等于没升级。我的经验值是一般业务系统第一步立即发值班第二步 20 分钟发主管第三步 45 分钟发公共组这个节奏比较合理。核心系统可以压缩到 3 分钟、10 分钟、20 分钟但一定要配上故障自动恢复的拦截逻辑避免已经恢复的故障还在继续升级。5. 进阶玩法自定义脚本媒介直连 SMTP内置媒介解决不了所有问题这时候就需要脚本媒介出场。脚本媒介的本质很简单Zabbix Server 在需要发通知的时候按照你定义的参数顺序去调用 AlertScriptsPath 目录下的一个可执行文件把参数传进去脚本自己去完成发信。5.1 脚本媒介的适用场景哪些情况值得上脚本我列几个真实遇到的需要一封邮件同时发给多个收件人并且每个收件人看到的内容略有不同需要在邮件里附上最近的几张趋势图链接需要根据告警级别动态决定抄送谁需要把告警同时推到内部工单系统需要在发信前做一次内容过滤把某些敏感信息屏蔽掉。这些需求内置媒介都做不到脚本媒介就顺手了。反过来如果你的需求只是把告警发到我的邮箱那真的没必要写脚本。脚本媒介多引入了解释器版本、依赖库、执行权限、路径、超时这一堆变量每多一个变量就多一个故障点。我见过太多环境原本内置媒介能干的活儿被硬生生改成了脚本结果三不五时挂一次根因还特别难查。5.2 Python 发信脚本完整实现下面这个脚本是我在自己环境里长期用的逻辑简单依赖只有 Python 标准库#!/usr/bin/env python3 # -*- coding: utf-8 -*- import smtplib import sys from email.mime.text import MIMEText from email.header import Header from email.utils import formataddr # Zabbix 会按媒介类型里定义的参数顺序传入 sendto sys.argv[1] subject sys.argv[2] body sys.argv[3] smtp_host smtp.example.com smtp_port 465 # SSL/TLS 用 465STARTTLS 用 587 smtp_user opsexample.com smtp_pass 你的授权码 mail_from opsexample.com msg MIMEText(body, plain, utf-8) msg[Subject] Header(subject, utf-8) msg[From] formataddr((Zabbix Monitor, mail_from)) msg[To] sendto try: if smtp_port 465: server smtplib.SMTP_SSL(smtp_host, smtp_port, timeout30) else: server smtplib.SMTP(smtp_host, smtp_port, timeout30) server.starttls() server.login(smtp_user, smtp_pass) server.sendmail(mail_from, sendto.split(,), msg.as_string()) server.quit() sys.exit(0) except Exception as e: # 错误输出到 stderrZabbix 会记进 Server 日志 print(send mail failed: %s % e, filesys.stderr) sys.exit(1)这段代码有几个地方是刻意这么写的。第一用标准库不用第三方库避免服务器上装依赖第二脚本的退出码很关键成功返回 0失败返回非 0Zabbix 靠这个判断发送结果返回 0 但实际没发出去日志里就是一片太平问题永远不会被发现第三异常信息打印到标准错误Zabbix 会把这段内容写进 Server 日志排查时直接搜日志就能看到真实的失败原因比只留一个脚本执行失败有用得多第四超时设了 30 秒避免 SMTP 服务器无响应时脚本一直挂着把 Server 的进程池占满。5.3 参数传递与权限设置脚本写完放到 AlertScriptsPath 目录下然后三件事必须做一是加可执行权限chmod x二是把属主和属组改成 Zabbix Server 运行的用户通常是 zabbixchown zabbix:zabbix三是确认脚本所在目录的每一项父目录都有可执行权限这个坑很深目录没有 x 权限里面的文件权限再对也执行不了报的错是权限被拒绝会让人以为是文件权限的问题。然后到前端新建媒介类型Type 选 Script脚本名称填文件名参数按顺序填三个 Zabbix 内置宏参数顺序宏含义1{ALERT.SENDTO}收件地址来自用户媒介的 Send to2{ALERT.SUBJECT}主题来自动作里配置的消息主题3{ALERT.MESSAGE}正文来自动作里配置的消息内容这三个宏的顺序必须和脚本里 sys.argv 的读取顺序一致顺序反了正文和收件人就会互换位置报错信息会很奇怪。配置好之后同样用 Test 按钮测一发测试时可以手动填参数值比等真实告警触发快得多。注意脚本里的凭据是明文写死的建议单独设一个专用发件账号权限收紧脚本文件权限设成 700只允许 zabbix 用户读取。同时脚本目录不要对外开放访问。6. 测试与排错从没收到到收到了但不对邮件发送的排查一半靠日志一半靠分层验证。我总结了几个高频故障做成了速查表遇到问题先对照一遍能省下大量时间。6.1 三层验证法我排查没收到邮件的问题固定走三层。第一层验证 SMTP 通道本身。在 Zabbix Server 上用命令行直接连 SMTP 服务器做一次完整的会话能收到信说明通道没问题问题在 Zabbix 侧收不到说明通道有问题去查网络、端口、账号、授权码。这一层的目的是把问题范围一刀切成两半非常高效。第二层验证 Zabbix 的投递能力。用媒介类型界面的 Test 按钮填一个真实收件人测一发。这一层走的是 Server 的真实投递流程能过说明媒介类型配置没问题。过不了就看 Server 日志里的错误详情那里通常有 SMTP 服务器的原始响应。第三层验证动作和用户链路。造一个真实事件比如临时把某个触发器的阈值调低让它触发观察动作有没有执行、用户有没有收到、恢复时有没有发恢复邮件。这一层验证的是整条链路的编排也是最容易漏配的地方。6.2 常见报错速查表现象/报错关键词大概率原因处理方向认证失败、用户名密码错误用了登录密码而非授权码或账号与发件人不一致重新生成授权码确认账号与 SMTP email 一致连接超时、拒绝连接端口被封、SMTP 地址填错、连接加密方式与端口不匹配用 nc/telnet 验证端口核对加密方式与端口搭配TLS 握手失败加密方式选错或服务端不支持所选方式SSL/TLS 与 STARTTLS 互换测试邮件被退回提示垃圾邮件发件频率过高、内容特征触发反垃圾、发件域名信誉低控制频率改用企业邮箱优化主题措辞日志里有脚本未找到AlertScriptsPath 路径不对、文件名不匹配从 Server 启动日志确认实际路径日志里有权限被拒绝脚本或父目录权限不足检查脚本及所有父目录的权限和属主脚本执行成功但没有邮件脚本返回 0 但内部异常被吞掉在脚本里显式捕获异常并返回非 0某些级别收不到用户媒介的严重性过滤勾选不全检查 Use if severity 一栏全都没收到动作未启用、条件不匹配、用户无媒介依次检查动作启用状态、条件、用户媒介列表恢复邮件收不到未配置恢复操作在动作里补上 Recovery operations邮件里的链接点不开Frontend URL 未配置在全局设置里补上前端访问地址正文中文乱码字符集设置问题脚本里显式指定 utf-8或媒介格式改纯文本6.3 踩坑记录与独家经验表格之外还有几条是真正从生产环境的坑里爬出来才总结到的。第一条Zabbix 数据库里的 alerts 表会随着告警量持续增长。邮件通知的每一次尝试都会在 alerts 表里留一条记录量大的环境这张表几个月就能涨到几十 GB进而拖慢整个数据库。定期清理历史告警数据是必须做的运维动作Housekeeper 的保留周期要按实际告警量调整别用默认值放着不管。第二条邮件正文里的变量不是所有位置都能用。消息模板里能用的宏是有限集合比如 {ITEM.VALUE} 依赖具体监控项在触发器中未关联监控项的场景下会取到空值。写完模板后一定要用 Test 看一遍实际渲染结果别凭想象。我见过模板里写了 {HOST.IP} 结果渲染出来是空字符串的情况因为那个宏在某些事件类型下不可用。第三条新版界面里菜单名字改过。老版本的Administration → Media types在新版里挪到了 Alerts 菜单下用户媒介还在用户编辑页的同一个标签页里但动作的入口和内部布局变化不小。跟着老教程找不到入口不是你的问题是版本差异先确认自己的版本号再对照对应版本的界面结构。第四条测试邮件发多了也会被限流。我见过同事为了验证连着发了二十几封测试邮件结果发件账号被临时限流接下来半小时所有真实告警全部发不出去。测一两发确认链路通了就够了剩下的验证用造事件的方式做别拿发件账号做压力测试。第五条注意 Server 进程池被脚本拖垮。脚本媒介的执行是同步的如果 SMTP 服务器响应很慢脚本会一直占用 Server 的进程。进程被占满之后不只是邮件发不出去整个 Zabbix 的采集和处理都会受影响。所以脚本里必须设超时Server 的整体进程数也要留出冗余。7. 告警降噪别让收件箱变成垃圾场邮件通道打通之后下一个问题马上就来邮件太多了。我见过最夸张的环境一个下午收到三百多封告警邮件最后全组人把 Zabbix 发件地址加进了过滤规则等于整个监控体系彻底失效。告警不是一个发出去就完事的动作发得太多和发不出去效果是一样的。7.1 分级发送策略降噪最有效的手段是分级。我现在的做法是把告警分成三档对应三种不同的通知方式但因为这篇主要讲邮件所以这里只讲邮件层面的分级。一档是灾难级和严重级这类告警邮件必须有而且要带升级机制保证有人在规定时间内响应。二档是警告级只发给日常值班邮箱不做升级工作日工作时间发送就行。三档是信息级不发邮件只在界面上展示或者只往团队群里推一条消息做留痕。这个分档不是拍脑袋定的而是根据故障影响范围和响应紧迫性两个维度定出来的。配置上分档主要落在两个地方一个是触发器本身的严重性设置另一个是用户媒介的 Use if severity 勾选。前者决定事件属于哪一档后者决定哪一档能落到这个邮箱。两处配合才能把分档真正落地。7.2 邮件正文模板的工程化写法正文模板不只是为了好看它直接影响响应速度。一封合格的告警邮件应该在扫一眼之内让人知道四件事哪里出问题了、问题是什么、严重到什么程度、我该点哪里去看详情。我常用的模板长这样告警主机{HOST.NAME}{HOST.IP} 业务分组{HOSTGROUP.NAME} 告警名称{EVENT.NAME} 严重程度{EVENT.SEVERITY} 触发时间{EVENT.DATE} {EVENT.TIME} 当前状态{EVENT.STATUS} 触发值{ITEM.LASTVALUE} 事件编号{EVENT.ID} 详情链接{TRIGGER.URL}这个模板有几个考虑。第一行把主机名和 IP 放一起因为排查的时候光有主机名往往不够还需要 IP 去定位。触发值这一项是我特别加的报警时的实际值能让人快速判断是刚好越界还是彻底爆表这两种情况的处理优先级完全不同。事件编号加上是为了后续查日志和做关联分析虽然平时用不上但一旦要做复盘它就很省事。详情链接依赖 Frontend URL 的配置如果没配这一行渲染出来是残缺的一定要在全局设置里把它补上。再补一句关于主题的处理。主题行我建议把主机名和告警名的顺序固定下来比如统一写成[{EVENT.SEVERITY}] {HOST.NAME} - {EVENT.NAME}这样在邮箱里按主题排序时同一个主机的告警会聚在一起同一级别的告警也会连续出现翻起来比乱序强太多了。