1. 监控不是目的报警才是闭环很多人搭好Zabbix看着Web界面里五颜六色的图表以为监控工作就算完成了。实际上监控只是前半段真正让Zabbix发挥价值的是告警通知这一环。服务器CPU飙到99%了、磁盘只剩5%空间了、交换机的某个端口Down了如果没人第一时间知道那这些监控数据就只是事后复盘用的历史素材而不是救火用的情报。Zabbix的邮箱报警就是把监控系统中发生的事件通过邮件实时推送到运维人员手里的那根“神经”。你不需要一直盯着大屏也不需要隔几分钟刷一次Dashboard只要邮件能及时到达你就有机会在用户发现故障之前把问题处理掉。这也是为什么“Zabbix 配置邮箱报警”这个词会被这么频繁地搜索——它不是一个可选项而是一个上线必备项。这篇文章从我的实操经验出发把Zabbix邮箱报警从原理到配置、从排错到优化完整过一遍。不管你是刚装好Zabbix还没配报警的新手还是配完了但邮件一直收不到的倒霉蛋这篇文章应该都能给你一些参考。2. 动手之前先理解整套告警链路2.1 从监控项到邮件通知的五层结构配置邮箱报警之前先花两分钟理解Zabbix的告警链路否则你很可能陷入“明明设置了动作却一直不触发”的困惑。Zabbix从采集数据到发出邮件完整经过五层监控项Item负责采集数据比如CPU使用率、内存余量、端口状态。触发器Trigger对监控项的数值做判断比如“CPU使用率连续3分钟大于90%”就触发一个“问题Problem”。动作Action监听触发器产生的事件判断这个事件要不要处理、怎么处理。媒介Media Type定义通知渠道比如SMTP邮件、脚本、Webhook等。用户媒介User Media把媒介绑定到具体用户或者用户组确定邮件发到哪个邮箱。用一句话串起来就是监控项采集数据触发器判断异常动作匹配事件后调用媒介媒介把消息发到绑定了该媒介的用户邮箱。这五层缺一环都不行。实际排错中最常见的现象是Issues页面里明明有红色的Problem但邮件就是没出来这时候就要按这个链路一层一层排查问题基本都出在动作匹配或者用户媒介绑定上。2.2 为什么邮件报警被用得最多现在Zabbix能接的通知方式很多钉钉Webhook、企业微信、飞书机器人、Telegram、Slack……但绝大部分运维团队至少在初期都会选择邮箱报警。原因很简单配置简单不需要开发能力在Web界面填几个参数就能跑起来。邮箱是公司内部的基础设施邮件留痕方便日后追溯。一次配置全团队共享不需要每台手机都装App。后续把邮箱接到钉钉/企微的“邮件群组”里相当于免费获得了一个消息聚合入口。当然邮件报警也有短板比如无法确认送达、可能存在延迟、邮件容易被丢进垃圾箱等。不过对于绝大多数监控场景来说邮件的可靠性和易用性已经足够。2.3 这次配置的实验环境说明一下我这次演示的环境方便你对照Zabbix版本6.0 LTS7.0也适用界面基本一致操作系统CentOS 7.9Zabbix Server与Zabbix Web装在同一台数据库MySQL 5.7版本不影响邮件配置被监控对象一台Linux服务器和一台可SNMP的交换机如果你用的是Zabbix 5.0或6.4界面菜单名称稍微有点差异但核心配置项的位置和逻辑是一样的。我会在关键步骤里标注版本差异。3. 四步完成Zabbix邮箱报警配置3.1 第一步配置SMTP媒介类型先说什么是“媒介类型”。在Zabbix里媒介类型就是通知渠道的模板。系统自带了一个叫“Email”的默认邮件媒介我们要做的就是把它的SMTP参数填对。操作路径在Web界面点左上角“齿轮”图标Administration进入Media types媒介类型在列表里点击“Email”进入编辑页。需要填写的关键字段如下NameEmail保持默认即可SMTP serversmtp.qq.com以QQ邮箱为例用163的就把这个换成smtp.163.comSMTP server port465QQ和163的SMTP SSL端口都是465如果SMTP服务商支持STARTTLS且用587端口那这里就填587Connection securitySSL/TLS465端口选这个如果填587且要用STARTTLS选“STARTTLS”Authentication勾上“Enabled”表示启用认证Username发件邮箱完整地址比如 notifyqq.comPassword邮箱的SMTP授权码注意不是邮箱登录密码Verify SSL certificate建议保持勾选除非你自建的邮件服务器证书有问题填完之后先别急着保存去配后面的步骤点下面的“Send test message”发送测试消息按钮。这时候会出现一个收件人输入框填一个你能收到邮件的邮箱地址点“Send”。如果这一步显示发送成功且你的手机或邮箱客户端收到一封来自Zabbix的测试邮件说明SMTP媒介已经通了。如果提示报错先检查端口和认证方式这两个地方最容易出问题。注意QQ邮箱和163邮箱都需要先在网页端开启SMTP服务并生成授权码。QQ邮箱在“设置-账号-开启SMTP服务”里开启后会生成一串16位授权码复制出来填到Password字段。这里有一个识别坑有些同学把登录密码填进去结果一直提示认证失败因为邮件服务商早就禁用了明文密码登录。3.2 第二步给用户绑定收件邮箱SMTP媒介配好之后接下来要决定邮件发给谁。Zabbix的用户在Administration → Users里管理。操作路径Administration → Users → 点击你的用户名比如Admin进入编辑页切换到“Media”标签页点击“Add”。这里需要填Type选择“Email”就是我们刚才配置的媒介类型Send to收件邮箱地址填你希望接收告警的邮箱When active默认是1-7,00:00-24:00即全天候都接收通知这里一般不用动Use if severity默认所有严重级别都勾上了保持默认Enabled勾选启用保存时注意如果这个用户是Zabbix内置的Admin默认就已经绑定了一个邮箱通常是你安装时填的那个。如果你要改成自己的邮箱直接编辑原有的媒介条目不要新增一个导致重复发送。这里还有个团队协作的小技巧建议在Zabbix里创建一个告警组比如“运维告警组”把团队成员的账号都拉进去然后给每个人单独绑定邮箱。后续配置动作的时候通知对象直接选这个组新同事入职只需要加组并绑邮箱不需要改动动作。3.3 第三步创建告警动作媒介和用户都到位了最后一步是配置动作Action。动作的作用是告诉Zabbix当某个事件发生时要用哪种媒介、联系谁、发什么内容。操作路径Configuration → Actions默认在“Trigger actions”页签下6.0里的路径是Alerts → Actions注意一下版本差异点击右上角“Create action”。这里有几个关键配置部分第一部分Action选项卡Name建议起得清晰一点比如“服务器故障-邮件通知”ConditionA这里设置触发条件。默认有一个条件通常是“Trigger severity is greater than or equals Warning”(触发器严重性大于等于警告)。你可以按需调整比如希望“严重级别及以上”才发邮件就把条件改成大于等于High。第二部分Operations操作选项卡New operation condition默认显示“Send message to user groups”(向用户组发送消息)也可以改成Send to users向指定用户发送。User groups/user选择第二步里的告警组或用户。Send only to选择发送的媒介渠道必须选“Email”。关键点来了Operations下面有一个“Steps”设置默认是“1 - 1”表示第1步到第1步也就是只发1次。如果你希望报障之后如果没有恢复每隔一段时间再提醒一次就把Steps改成“1 - 0”然后在下面“Step duration”里填300单位是秒300秒5分钟意思是第1分钟发一次之后每5分钟重复提醒一次直到问题恢复或达到最大值。恢复操作Recovery operations是单独一个页签建议把“Default message”勾上这样故障恢复后相关人员也能收到“已恢复”的通知一个告警闭环才算完整。3.4 第四步测试整个告警链路动作配好以后一定要做一次端到端的验证而不是干等着真实故障发生。我的习惯做法是找一台测试机手动停掉它的agent服务或者在一个监控项上手动设置一个肯定会触发报警的值。比如可以执行下面几个步骤到被监控的Linux主机上执行service zabbix-agent stop或者systemctl stop zabbix-agent。回到Zabbix Web的Monitoring → Latest data找到这台主机的“Agent ping”监控项很快就能看到值变成0。等几分钟取决于更新间隔和触发器表达式到Monitoring → Problems问题页面应该能看到这台主机出现了“Zabbix agent is unreachable”这类问题。打开Reports → Action log动作日志查看刚才那个动作是否被触发执行结果是否“Sent”。去邮箱检查是否收到报警邮件标题和正文是否符合预期。到这一步邮箱报警的基础链路就算通了。但千万别高兴太早接下来还有一些经常坑人的细节需要注意。4. 告警消息模板把邮件写成看得懂的样子4.1 默认模板能发但不一定好用Zabbix动作里默认的消息内容是这样Problem started at {EVENT.TIME} on {EVENT.DATE} Problem name: {TRIGGER.NAME} Host: {HOST.NAME} Severity: {TRIGGER.SEVERITY} Original problem ID: {EVENT.ID}说实话这段内容信息量够了但干巴巴的不太直观。尤其当你同时管几十台机器、每天收几十封告警邮件时一眼扫过去抓不到重点很耽误事儿。我的建议是在动作的“Message”里把模板改得更直白一些。4.2 推荐一份生产环境可用的模板先说默认的告警消息模板我习惯改成类似这样报警信息{TRIGGER.NAME} 主机名称{HOST.NAME} 主机地址{HOST.IP} 严重级别{TRIGGER.SEVERITY} 当前状态{TRIGGER.STATUS} 触发时间{EVENT.DATE} {EVENT.TIME} 当前值{ITEM.LASTVALUE} 监控项目{ITEM.NAME} 详情请登录Zabbix查看对应的恢复消息模板恢复信息{TRIGGER.NAME} 主机名称{HOST.NAME} 主机地址{HOST.IP} 恢复时间{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME} 持续时长{EVENT.AGE} 当前状态{TRIGGER.STATUS}这些大括号里的变量都是Zabbix内建宏邮件发送时会被替换成实际值。宏用得好邮件就有信息密度宏用错了邮件里就全是原文大括号。4.3 常用宏对照表这里整理一份我经常用的宏记一下很有用宏含义示例{HOST.NAME}主机名称web-01{HOST.IP}主机IP地址192.168.1.10{TRIGGER.NAME}触发器名称CPU负载过高{TRIGGER.STATUS}触发器状态PROBLEM / OK{TRIGGER.SEVERITY}严重级别Average / High{ITEM.NAME}监控项名称CPU utilization{ITEM.LASTVALUE}监控项最近值97.5%{EVENT.DATE}事件日期2025.01.15{EVENT.TIME}事件时间14:33:22{EVENT.AGE}事件存活时长2h 15m{EVENT.RECOVERY.DATE}恢复日期2025.01.15{EVENT.RECOVERY.TIME}恢复时间15:01:08{TRIGGER.URL}触发器关联的URL可自定义跳转链接需要说明的是不同Zabbix版本对宏的支持有细微差别。6.0以后的版本里{EVENT.RECOVERY.DATE}这类宏在“恢复消息”中才有效在“报警消息”里是空的。如果你在测试时发现邮件里某个宏没被替换先确认宏的适用范围。4.4 更新操作Update operations的实用场景除了报警和恢复动作里还提供了一个“更新操作”的选项。这个功能的场景是报警发出后某位同事接手处理在Zabbix里给问题添加了备注或者修改了状态就会触发一次更新通知把处理进展同步给整个告警组。这算是一个很多团队没用起来但实际很香的功能。我在给客户做方案时通常会建议开启告警邮件命中A同事认领并在工单里回复了处理思路其他同事也收到一封“有人处理了”的邮件大家就不用反复确认“这个故障谁在看”了。更新消息模板可以这样设计问题更新{TRIGGER.NAME} 主机名称{HOST.NAME} 当前状态{TRIGGER.STATUS} 更新人{USER.FULLNAME} 更新时间{DATE} {TIME} 更新内容{MESSAGE}5. 常见问题与排错实录5.1 页面提示 zabbix server is not running这个错误应该很多人在装完Zabbix后遇到过。页面顶部直接一行红字“Zabbix server is not running: the information displayed may not be current.”出现这个提示意味着Web前端连不上Zabbix Server进程或者Server进程启动了但异常。排查步骤按顺序来确认进程是否在跑ps -ef | grep zabbix_server如果没输出先启动服务systemctl start zabbix-server。看日志tail -f /var/log/zabbix/zabbix_server.log这是最重要的排查入口。常见的日志信息包括数据库连接失败、配置参数错误等。确认数据库服务正常systemctl status mariadb或mysqld如果数据库没有起来Zabbix Server连不上库这里的提示也会出现。检查防火墙和SELinuxCentOS 7上如果防火墙开着需要放行10051端口SELinux如果没有关闭或配置放行规则也可能导致Server无法启动。还有一个不太起眼但常见的问题磁盘满了。Zabbix Server启动时如果无法写临时文件或者历史数据表写入失败进程会反复重启甚至直接退出。df -h看一下如果/或者数据盘使用率100%先清出空间再说。5.2 access denied for user replace_userlocalhost这个报错看起来像SQL语法错误其实是Zabbix Server连数据库时用的账号密码不对。replace_user这个用户名看着就很蹊跷但确实有一批文档和自动部署脚本里数据库初始化时没有替换占位用户名导致Zabbix Server拿着这个印在示例里的用户名去连库。排查方法打开Zabbix Server配置文件/etc/zabbix/zabbix_server.conf找到DBUser、DBPassword这几行。检查配置里写的用户名和密码是否和MySQL里实际创建的用户一致。手动测试一下在命令行执行mysql -u你的用户 -p你的密码 -h localhost zabbix看看能不能连上。连不上就去MySQL里重建用户并授权。给一个标准的数据库授权命令做参考mysql -uroot -p CREATE USER zabbixlocalhost IDENTIFIED BY 你的强密码; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; FLUSH PRIVILEGES;改完配置文件后重启Zabbix Server然后重新加载页面这个问题一般就能解决。5.3 配置都对了邮件还是收不到这是邮箱报警最让人抓狂的问题——测试邮件能发出去动作也显示Sent但收件箱里就是没有。我遇到过好几种情况逐一说明第一种发往企业邮箱被拦截。Zabbix发出来的邮件一般发件人地址是个快速注册的QQ邮箱或163邮箱私有邮件服务器有反垃圾策略会直接拒收或者丢进垃圾箱。排查方法很简单去垃圾箱里翻一翻。如果确实在垃圾箱里把发件人加入白名单。第二种邮件发到了Zabbix默认的Admin用户绑定邮箱里而不是你自己绑定的邮箱。装了Zabbix之后Admin用户的邮箱默认是配置Web界面时填的那个。如果你在动作里选择的是“发送给Admin用户”但Admin用户恰好绑定了其他邮箱那自然就收不到。这种情况记得修改Admin用户的媒介邮箱。第三种端口不通或者被防火墙拦截。虽然测试邮件发成功了但有些网络环境下Zabbix Server到SMTP服务器的465端口是通的到某些被监控机的端口却被限制了这会导致邮件发送队列堆积。在Zabbix Server上执行telnet smtp.qq.com 465能连上说明网络通畅否则就要检查出口规则。第四种动作的Steps设置导致只发一次且间隔太长。比如Steps设置成了1-5Step duration是600秒那第一封邮件发出后第二封要等10分钟。如果问题恰好在10分钟内恢复了看起来就好像只发了一封。注意区分“没发”和“只发了一次”。5.4 中文乱码与主题冗余邮件内容出现中文乱码大多是因为Zabbix Web界面用的字符集和SMTP服务商的编码设置不一致。虽然Zabbix 6.0默认带上了UTF-8的邮件头但个别邮件服务商对非标准头处理得不友好。我实测下来把消息模板里的大段中文描述换成“简短中文标题宏变量”的组合出问题的概率会下降不少。还有一个小细节默认的邮件主题是Problem: {TRIGGER.NAME}建议改成[{TRIGGER.STATUS}][{TRIGGER.SEVERITY}] {HOST.NAME} - {TRIGGER.NAME}这样邮件列表页里不用点开就能看到严重级别和主机名尤其是同时收到多封告警时可以快速按主题排序确定处理优先级。5.5 告警风暴与重复通知另一个在真实环境里很常见的现象是“告警风暴”。某个基础设施故障导致几十台主机同时触发同一条触发器于是邮箱在几分钟内被几十封邮件塞满。这时你真正想做的不是重复收几十封邮件而是合并消息。Zabbix的触发器表达式中可以加上时间延迟来抑制抖动。比如把表达式写成min(/Linux/CPU utilization?[CPU utilization],5m){$CPU.THRESHOLD.MAX}意思是连续5分钟内CPU使用率都超过阈值才触发而不是瞬时值超了就告警。这种做法能大量过滤掉瞬时抖动带来的无效告警。同时在动作层面可以把“Steps”从“1-1”改为“1-0”并在Step duration中设置重复间隔。但要注意如果问题持续数小时重复发送的频率太高同样会产生大量邮件。我一般不会让步骤无限重复而是设置3-5步之后就不再发了核心目的是让值班人员知道问题还在但没必要反复轰炸。6. 从邮箱报警到告警治理的一些心得6.1 别让告警成为新的噪音最后聊聊比配置更重要的事——告警治理。邮箱报警配好之后一开始团队的体验往往是“哇太及时了”但运行几周后就会变成“怎么又是邮件”。告警的本质是信号如果信号里大量包含无效信息那就是噪音。噪音多了真正的故障邮件反而容易被忽略。这是一个很危险的信号。我的经验是每个季度至少做一次告警复盘翻一翻动作日志统计哪些告警触发了但没有实际意义哪些触发频率过高但从未导致服务不可用。对这些告警该调阈值调阈值该加抑制加抑制该删触发器就删触发器。好的告警体系应该是安静而敏锐的——平时不打扰你真正有事的时候一而再、再而三地提醒你。6.2 值班机制与升级策略邮件报警解决了“有人知道”的问题但没有解决“有人处理”的问题。在团队协作中建议把告警动作与值班机制结合起来。在Zabbix里可以针对同一个动作配置多个用户组并利用Steps的间隔设置做升级比如第1封邮件发给一线值班组如果5分钟后问题还没恢复第2封邮件自动升级发给二线负责人。这种升级策略不需要额外开发全靠动作里的Steps和Step duration迭代实现。每次运行到新的Step时可以用“Default message”里的不同变量来标示这是第几级提醒。Zabbix里有个宏 {ACTION.ID} 可以用来区分动作如果需要在不同步骤发送不同的收件人需要创建多个动作用条件“触发器严重性”加“问题时间”来区分这个思路相对复杂一些但确实能在不写脚本的情况下实现分级告警。6.3 后续还值得做的事情如果你已经完成了邮箱报警下一步我会建议你加一个Webhook媒介类型。比如在Zabbix里配置钉钉或企业微信的Webhook让告警同时推到移动端群聊里。邮件适合留痕IM适合即时响应两者配合监控通知的体验才算完整。再往后还可以考虑把告警数据接到工单系统或者做一个简单的可视化大屏。Zabbix本身自带了一些报表和展示能力配合Grafana可以做出很漂亮的监控大屏。但这些都是后话前提是先把邮件报警这条主链路跑通、跑稳。我在实际项目中反复被问过同一个问题“为什么我按照网上的教程配了邮件就是不响”其实大多数时候问题都出在那几个最不起眼的位置——SMTP端口选错了、授权码复制漏了一位、动作里忘记选用户组、或者触发器压根没触发。你按顺序把这篇文章里的配置项一项项核对一遍基本都能解决。做这个功能不需要高深的技术靠的是细心和一套完整的检查思路。
1. 监控不是目的报警才是闭环很多人搭好Zabbix看着Web界面里五颜六色的图表以为监控工作就算完成了。实际上监控只是前半段真正让Zabbix发挥价值的是告警通知这一环。服务器CPU飙到99%了、磁盘只剩5%空间了、交换机的某个端口Down了如果没人第一时间知道那这些监控数据就只是事后复盘用的历史素材而不是救火用的情报。Zabbix的邮箱报警就是把监控系统中发生的事件通过邮件实时推送到运维人员手里的那根“神经”。你不需要一直盯着大屏也不需要隔几分钟刷一次Dashboard只要邮件能及时到达你就有机会在用户发现故障之前把问题处理掉。这也是为什么“Zabbix 配置邮箱报警”这个词会被这么频繁地搜索——它不是一个可选项而是一个上线必备项。这篇文章从我的实操经验出发把Zabbix邮箱报警从原理到配置、从排错到优化完整过一遍。不管你是刚装好Zabbix还没配报警的新手还是配完了但邮件一直收不到的倒霉蛋这篇文章应该都能给你一些参考。2. 动手之前先理解整套告警链路2.1 从监控项到邮件通知的五层结构配置邮箱报警之前先花两分钟理解Zabbix的告警链路否则你很可能陷入“明明设置了动作却一直不触发”的困惑。Zabbix从采集数据到发出邮件完整经过五层监控项Item负责采集数据比如CPU使用率、内存余量、端口状态。触发器Trigger对监控项的数值做判断比如“CPU使用率连续3分钟大于90%”就触发一个“问题Problem”。动作Action监听触发器产生的事件判断这个事件要不要处理、怎么处理。媒介Media Type定义通知渠道比如SMTP邮件、脚本、Webhook等。用户媒介User Media把媒介绑定到具体用户或者用户组确定邮件发到哪个邮箱。用一句话串起来就是监控项采集数据触发器判断异常动作匹配事件后调用媒介媒介把消息发到绑定了该媒介的用户邮箱。这五层缺一环都不行。实际排错中最常见的现象是Issues页面里明明有红色的Problem但邮件就是没出来这时候就要按这个链路一层一层排查问题基本都出在动作匹配或者用户媒介绑定上。2.2 为什么邮件报警被用得最多现在Zabbix能接的通知方式很多钉钉Webhook、企业微信、飞书机器人、Telegram、Slack……但绝大部分运维团队至少在初期都会选择邮箱报警。原因很简单配置简单不需要开发能力在Web界面填几个参数就能跑起来。邮箱是公司内部的基础设施邮件留痕方便日后追溯。一次配置全团队共享不需要每台手机都装App。后续把邮箱接到钉钉/企微的“邮件群组”里相当于免费获得了一个消息聚合入口。当然邮件报警也有短板比如无法确认送达、可能存在延迟、邮件容易被丢进垃圾箱等。不过对于绝大多数监控场景来说邮件的可靠性和易用性已经足够。2.3 这次配置的实验环境说明一下我这次演示的环境方便你对照Zabbix版本6.0 LTS7.0也适用界面基本一致操作系统CentOS 7.9Zabbix Server与Zabbix Web装在同一台数据库MySQL 5.7版本不影响邮件配置被监控对象一台Linux服务器和一台可SNMP的交换机如果你用的是Zabbix 5.0或6.4界面菜单名称稍微有点差异但核心配置项的位置和逻辑是一样的。我会在关键步骤里标注版本差异。3. 四步完成Zabbix邮箱报警配置3.1 第一步配置SMTP媒介类型先说什么是“媒介类型”。在Zabbix里媒介类型就是通知渠道的模板。系统自带了一个叫“Email”的默认邮件媒介我们要做的就是把它的SMTP参数填对。操作路径在Web界面点左上角“齿轮”图标Administration进入Media types媒介类型在列表里点击“Email”进入编辑页。需要填写的关键字段如下NameEmail保持默认即可SMTP serversmtp.qq.com以QQ邮箱为例用163的就把这个换成smtp.163.comSMTP server port465QQ和163的SMTP SSL端口都是465如果SMTP服务商支持STARTTLS且用587端口那这里就填587Connection securitySSL/TLS465端口选这个如果填587且要用STARTTLS选“STARTTLS”Authentication勾上“Enabled”表示启用认证Username发件邮箱完整地址比如 notifyqq.comPassword邮箱的SMTP授权码注意不是邮箱登录密码Verify SSL certificate建议保持勾选除非你自建的邮件服务器证书有问题填完之后先别急着保存去配后面的步骤点下面的“Send test message”发送测试消息按钮。这时候会出现一个收件人输入框填一个你能收到邮件的邮箱地址点“Send”。如果这一步显示发送成功且你的手机或邮箱客户端收到一封来自Zabbix的测试邮件说明SMTP媒介已经通了。如果提示报错先检查端口和认证方式这两个地方最容易出问题。注意QQ邮箱和163邮箱都需要先在网页端开启SMTP服务并生成授权码。QQ邮箱在“设置-账号-开启SMTP服务”里开启后会生成一串16位授权码复制出来填到Password字段。这里有一个识别坑有些同学把登录密码填进去结果一直提示认证失败因为邮件服务商早就禁用了明文密码登录。3.2 第二步给用户绑定收件邮箱SMTP媒介配好之后接下来要决定邮件发给谁。Zabbix的用户在Administration → Users里管理。操作路径Administration → Users → 点击你的用户名比如Admin进入编辑页切换到“Media”标签页点击“Add”。这里需要填Type选择“Email”就是我们刚才配置的媒介类型Send to收件邮箱地址填你希望接收告警的邮箱When active默认是1-7,00:00-24:00即全天候都接收通知这里一般不用动Use if severity默认所有严重级别都勾上了保持默认Enabled勾选启用保存时注意如果这个用户是Zabbix内置的Admin默认就已经绑定了一个邮箱通常是你安装时填的那个。如果你要改成自己的邮箱直接编辑原有的媒介条目不要新增一个导致重复发送。这里还有个团队协作的小技巧建议在Zabbix里创建一个告警组比如“运维告警组”把团队成员的账号都拉进去然后给每个人单独绑定邮箱。后续配置动作的时候通知对象直接选这个组新同事入职只需要加组并绑邮箱不需要改动动作。3.3 第三步创建告警动作媒介和用户都到位了最后一步是配置动作Action。动作的作用是告诉Zabbix当某个事件发生时要用哪种媒介、联系谁、发什么内容。操作路径Configuration → Actions默认在“Trigger actions”页签下6.0里的路径是Alerts → Actions注意一下版本差异点击右上角“Create action”。这里有几个关键配置部分第一部分Action选项卡Name建议起得清晰一点比如“服务器故障-邮件通知”ConditionA这里设置触发条件。默认有一个条件通常是“Trigger severity is greater than or equals Warning”(触发器严重性大于等于警告)。你可以按需调整比如希望“严重级别及以上”才发邮件就把条件改成大于等于High。第二部分Operations操作选项卡New operation condition默认显示“Send message to user groups”(向用户组发送消息)也可以改成Send to users向指定用户发送。User groups/user选择第二步里的告警组或用户。Send only to选择发送的媒介渠道必须选“Email”。关键点来了Operations下面有一个“Steps”设置默认是“1 - 1”表示第1步到第1步也就是只发1次。如果你希望报障之后如果没有恢复每隔一段时间再提醒一次就把Steps改成“1 - 0”然后在下面“Step duration”里填300单位是秒300秒5分钟意思是第1分钟发一次之后每5分钟重复提醒一次直到问题恢复或达到最大值。恢复操作Recovery operations是单独一个页签建议把“Default message”勾上这样故障恢复后相关人员也能收到“已恢复”的通知一个告警闭环才算完整。3.4 第四步测试整个告警链路动作配好以后一定要做一次端到端的验证而不是干等着真实故障发生。我的习惯做法是找一台测试机手动停掉它的agent服务或者在一个监控项上手动设置一个肯定会触发报警的值。比如可以执行下面几个步骤到被监控的Linux主机上执行service zabbix-agent stop或者systemctl stop zabbix-agent。回到Zabbix Web的Monitoring → Latest data找到这台主机的“Agent ping”监控项很快就能看到值变成0。等几分钟取决于更新间隔和触发器表达式到Monitoring → Problems问题页面应该能看到这台主机出现了“Zabbix agent is unreachable”这类问题。打开Reports → Action log动作日志查看刚才那个动作是否被触发执行结果是否“Sent”。去邮箱检查是否收到报警邮件标题和正文是否符合预期。到这一步邮箱报警的基础链路就算通了。但千万别高兴太早接下来还有一些经常坑人的细节需要注意。4. 告警消息模板把邮件写成看得懂的样子4.1 默认模板能发但不一定好用Zabbix动作里默认的消息内容是这样Problem started at {EVENT.TIME} on {EVENT.DATE} Problem name: {TRIGGER.NAME} Host: {HOST.NAME} Severity: {TRIGGER.SEVERITY} Original problem ID: {EVENT.ID}说实话这段内容信息量够了但干巴巴的不太直观。尤其当你同时管几十台机器、每天收几十封告警邮件时一眼扫过去抓不到重点很耽误事儿。我的建议是在动作的“Message”里把模板改得更直白一些。4.2 推荐一份生产环境可用的模板先说默认的告警消息模板我习惯改成类似这样报警信息{TRIGGER.NAME} 主机名称{HOST.NAME} 主机地址{HOST.IP} 严重级别{TRIGGER.SEVERITY} 当前状态{TRIGGER.STATUS} 触发时间{EVENT.DATE} {EVENT.TIME} 当前值{ITEM.LASTVALUE} 监控项目{ITEM.NAME} 详情请登录Zabbix查看对应的恢复消息模板恢复信息{TRIGGER.NAME} 主机名称{HOST.NAME} 主机地址{HOST.IP} 恢复时间{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME} 持续时长{EVENT.AGE} 当前状态{TRIGGER.STATUS}这些大括号里的变量都是Zabbix内建宏邮件发送时会被替换成实际值。宏用得好邮件就有信息密度宏用错了邮件里就全是原文大括号。4.3 常用宏对照表这里整理一份我经常用的宏记一下很有用宏含义示例{HOST.NAME}主机名称web-01{HOST.IP}主机IP地址192.168.1.10{TRIGGER.NAME}触发器名称CPU负载过高{TRIGGER.STATUS}触发器状态PROBLEM / OK{TRIGGER.SEVERITY}严重级别Average / High{ITEM.NAME}监控项名称CPU utilization{ITEM.LASTVALUE}监控项最近值97.5%{EVENT.DATE}事件日期2025.01.15{EVENT.TIME}事件时间14:33:22{EVENT.AGE}事件存活时长2h 15m{EVENT.RECOVERY.DATE}恢复日期2025.01.15{EVENT.RECOVERY.TIME}恢复时间15:01:08{TRIGGER.URL}触发器关联的URL可自定义跳转链接需要说明的是不同Zabbix版本对宏的支持有细微差别。6.0以后的版本里{EVENT.RECOVERY.DATE}这类宏在“恢复消息”中才有效在“报警消息”里是空的。如果你在测试时发现邮件里某个宏没被替换先确认宏的适用范围。4.4 更新操作Update operations的实用场景除了报警和恢复动作里还提供了一个“更新操作”的选项。这个功能的场景是报警发出后某位同事接手处理在Zabbix里给问题添加了备注或者修改了状态就会触发一次更新通知把处理进展同步给整个告警组。这算是一个很多团队没用起来但实际很香的功能。我在给客户做方案时通常会建议开启告警邮件命中A同事认领并在工单里回复了处理思路其他同事也收到一封“有人处理了”的邮件大家就不用反复确认“这个故障谁在看”了。更新消息模板可以这样设计问题更新{TRIGGER.NAME} 主机名称{HOST.NAME} 当前状态{TRIGGER.STATUS} 更新人{USER.FULLNAME} 更新时间{DATE} {TIME} 更新内容{MESSAGE}5. 常见问题与排错实录5.1 页面提示 zabbix server is not running这个错误应该很多人在装完Zabbix后遇到过。页面顶部直接一行红字“Zabbix server is not running: the information displayed may not be current.”出现这个提示意味着Web前端连不上Zabbix Server进程或者Server进程启动了但异常。排查步骤按顺序来确认进程是否在跑ps -ef | grep zabbix_server如果没输出先启动服务systemctl start zabbix-server。看日志tail -f /var/log/zabbix/zabbix_server.log这是最重要的排查入口。常见的日志信息包括数据库连接失败、配置参数错误等。确认数据库服务正常systemctl status mariadb或mysqld如果数据库没有起来Zabbix Server连不上库这里的提示也会出现。检查防火墙和SELinuxCentOS 7上如果防火墙开着需要放行10051端口SELinux如果没有关闭或配置放行规则也可能导致Server无法启动。还有一个不太起眼但常见的问题磁盘满了。Zabbix Server启动时如果无法写临时文件或者历史数据表写入失败进程会反复重启甚至直接退出。df -h看一下如果/或者数据盘使用率100%先清出空间再说。5.2 access denied for user replace_userlocalhost这个报错看起来像SQL语法错误其实是Zabbix Server连数据库时用的账号密码不对。replace_user这个用户名看着就很蹊跷但确实有一批文档和自动部署脚本里数据库初始化时没有替换占位用户名导致Zabbix Server拿着这个印在示例里的用户名去连库。排查方法打开Zabbix Server配置文件/etc/zabbix/zabbix_server.conf找到DBUser、DBPassword这几行。检查配置里写的用户名和密码是否和MySQL里实际创建的用户一致。手动测试一下在命令行执行mysql -u你的用户 -p你的密码 -h localhost zabbix看看能不能连上。连不上就去MySQL里重建用户并授权。给一个标准的数据库授权命令做参考mysql -uroot -p CREATE USER zabbixlocalhost IDENTIFIED BY 你的强密码; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; FLUSH PRIVILEGES;改完配置文件后重启Zabbix Server然后重新加载页面这个问题一般就能解决。5.3 配置都对了邮件还是收不到这是邮箱报警最让人抓狂的问题——测试邮件能发出去动作也显示Sent但收件箱里就是没有。我遇到过好几种情况逐一说明第一种发往企业邮箱被拦截。Zabbix发出来的邮件一般发件人地址是个快速注册的QQ邮箱或163邮箱私有邮件服务器有反垃圾策略会直接拒收或者丢进垃圾箱。排查方法很简单去垃圾箱里翻一翻。如果确实在垃圾箱里把发件人加入白名单。第二种邮件发到了Zabbix默认的Admin用户绑定邮箱里而不是你自己绑定的邮箱。装了Zabbix之后Admin用户的邮箱默认是配置Web界面时填的那个。如果你在动作里选择的是“发送给Admin用户”但Admin用户恰好绑定了其他邮箱那自然就收不到。这种情况记得修改Admin用户的媒介邮箱。第三种端口不通或者被防火墙拦截。虽然测试邮件发成功了但有些网络环境下Zabbix Server到SMTP服务器的465端口是通的到某些被监控机的端口却被限制了这会导致邮件发送队列堆积。在Zabbix Server上执行telnet smtp.qq.com 465能连上说明网络通畅否则就要检查出口规则。第四种动作的Steps设置导致只发一次且间隔太长。比如Steps设置成了1-5Step duration是600秒那第一封邮件发出后第二封要等10分钟。如果问题恰好在10分钟内恢复了看起来就好像只发了一封。注意区分“没发”和“只发了一次”。5.4 中文乱码与主题冗余邮件内容出现中文乱码大多是因为Zabbix Web界面用的字符集和SMTP服务商的编码设置不一致。虽然Zabbix 6.0默认带上了UTF-8的邮件头但个别邮件服务商对非标准头处理得不友好。我实测下来把消息模板里的大段中文描述换成“简短中文标题宏变量”的组合出问题的概率会下降不少。还有一个小细节默认的邮件主题是Problem: {TRIGGER.NAME}建议改成[{TRIGGER.STATUS}][{TRIGGER.SEVERITY}] {HOST.NAME} - {TRIGGER.NAME}这样邮件列表页里不用点开就能看到严重级别和主机名尤其是同时收到多封告警时可以快速按主题排序确定处理优先级。5.5 告警风暴与重复通知另一个在真实环境里很常见的现象是“告警风暴”。某个基础设施故障导致几十台主机同时触发同一条触发器于是邮箱在几分钟内被几十封邮件塞满。这时你真正想做的不是重复收几十封邮件而是合并消息。Zabbix的触发器表达式中可以加上时间延迟来抑制抖动。比如把表达式写成min(/Linux/CPU utilization?[CPU utilization],5m){$CPU.THRESHOLD.MAX}意思是连续5分钟内CPU使用率都超过阈值才触发而不是瞬时值超了就告警。这种做法能大量过滤掉瞬时抖动带来的无效告警。同时在动作层面可以把“Steps”从“1-1”改为“1-0”并在Step duration中设置重复间隔。但要注意如果问题持续数小时重复发送的频率太高同样会产生大量邮件。我一般不会让步骤无限重复而是设置3-5步之后就不再发了核心目的是让值班人员知道问题还在但没必要反复轰炸。6. 从邮箱报警到告警治理的一些心得6.1 别让告警成为新的噪音最后聊聊比配置更重要的事——告警治理。邮箱报警配好之后一开始团队的体验往往是“哇太及时了”但运行几周后就会变成“怎么又是邮件”。告警的本质是信号如果信号里大量包含无效信息那就是噪音。噪音多了真正的故障邮件反而容易被忽略。这是一个很危险的信号。我的经验是每个季度至少做一次告警复盘翻一翻动作日志统计哪些告警触发了但没有实际意义哪些触发频率过高但从未导致服务不可用。对这些告警该调阈值调阈值该加抑制加抑制该删触发器就删触发器。好的告警体系应该是安静而敏锐的——平时不打扰你真正有事的时候一而再、再而三地提醒你。6.2 值班机制与升级策略邮件报警解决了“有人知道”的问题但没有解决“有人处理”的问题。在团队协作中建议把告警动作与值班机制结合起来。在Zabbix里可以针对同一个动作配置多个用户组并利用Steps的间隔设置做升级比如第1封邮件发给一线值班组如果5分钟后问题还没恢复第2封邮件自动升级发给二线负责人。这种升级策略不需要额外开发全靠动作里的Steps和Step duration迭代实现。每次运行到新的Step时可以用“Default message”里的不同变量来标示这是第几级提醒。Zabbix里有个宏 {ACTION.ID} 可以用来区分动作如果需要在不同步骤发送不同的收件人需要创建多个动作用条件“触发器严重性”加“问题时间”来区分这个思路相对复杂一些但确实能在不写脚本的情况下实现分级告警。6.3 后续还值得做的事情如果你已经完成了邮箱报警下一步我会建议你加一个Webhook媒介类型。比如在Zabbix里配置钉钉或企业微信的Webhook让告警同时推到移动端群聊里。邮件适合留痕IM适合即时响应两者配合监控通知的体验才算完整。再往后还可以考虑把告警数据接到工单系统或者做一个简单的可视化大屏。Zabbix本身自带了一些报表和展示能力配合Grafana可以做出很漂亮的监控大屏。但这些都是后话前提是先把邮件报警这条主链路跑通、跑稳。我在实际项目中反复被问过同一个问题“为什么我按照网上的教程配了邮件就是不响”其实大多数时候问题都出在那几个最不起眼的位置——SMTP端口选错了、授权码复制漏了一位、动作里忘记选用户组、或者触发器压根没触发。你按顺序把这篇文章里的配置项一项项核对一遍基本都能解决。做这个功能不需要高深的技术靠的是细心和一套完整的检查思路。
