监控装好了机房拓扑也画得漂漂亮亮的但真正出事那天早上你是被电话叫醒而不是被Zabbix的报警邮件叫醒的——这种尴尬我经历过一次之后就再也没让它发生过。Zabbix配置邮箱报警这件事听起来就是填几个SMTP参数的事但实际落地时会遇到授权码、消息模板、动作触发条件、告警风暴一堆坑。这篇文章我就把从零到一配置邮箱报警的完整过程写出来包括踩过的坑、排查思路和可以直接抄的配置给正在折腾Zabbix报警的同学做个参考。1. 为什么最终选了邮件报警监控通知渠道的选型实录先说结论邮件报警不是最快的通知方式但它是整个监控体系里最值得优先配好的兜底通道。我之前给一个朋友的创业公司搭监控他们当时纠结要不要直接上钉钉机器人。钉钉机器人确实香群里所有人手机弹通知看起来比邮件高级多了。但我问了一句万一你们公司用的办公软件换了怎么办钉钉的Webhook地址失效了怎么办到时候是不是又要重新配一遍他们沉默了。邮件报警的优势恰恰在于它的“无聊”和“稳定”。SMTP协议几十年没大变过邮箱服务商再怎么迭代邮件收发的基本路径永远是通的。而且邮件有天然的事后追溯能力告警发生了、谁处理的、几点恢复的都在邮箱里有记录。对于没有专职运维的小团队来说邮件就是最便宜的告警审计系统。对比一下常见通知渠道的适用场景你就明白我为啥把邮件放在第一位通知渠道实时性依赖条件事后追溯成本适合场景邮件中等通常秒级到分钟级邮箱服务商稳定可用强天然留痕几乎为零全量告警通知、审计、值班记录钉钉/企微群机器人高取决于群成员是否看到第三方办公软件可用一般消息易被刷掉低日常告警群播报短信高短信服务商、资费一般高重要告警、夜间值班电话语音极高语音服务商弱很高P1级故障、半夜宕机所以我的建议是第一优先级把邮件报警配好覆盖所有中低级别告警第二优先级再接钉钉机器人这类即时渠道覆盖需要快速响应的告警短信和电话留给真正的大事。邮件报警的定位是“不漏报、有记录”它不负责“秒级叫醒”那是短信和电话的事儿。如果你现在一套报警都没有别犹豫先把邮件配起来这是性价比最高的第一步。2. 报警链路拆解一条告警从产生到进收件箱要经过哪几道关卡很多新手配置邮箱报警失败不是因为SMTP参数填错而是根本不清楚Zabbix内部那条报警链路是怎么走的。邮件只是在链路最后一步负责把消息送出去前面的环节出任何一个问题邮件都发不出来。一条Zabbix报警消息从产生到进入你的收件箱完整路径是这样的监控项Item采集到某个数据比如CPU负载、磁盘使用率、ping丢包率触发器Trigger对采集到的值做判断表达式成立就产生一个事件Event动作Action匹配到这个事件检查事件是否满足自己设定的条件如果条件满足动作执行操作比如“发送消息给用户组”消息通过用户绑定的报警媒介Media Type发送邮件就是其中一种媒介SMTP服务器把邮件投递到收件人邮箱。这里有一个特别容易忽略的前提整个链路的前置条件是Zabbix Server本身必须正常运行。如果你打开Zabbix前端页面顶部横幅显示“Zabbix server is not running: the information displayed may not be current.”那后面所有配置都白搭——server都没起来哪来的事件哪来的动作执行所以配置邮箱报警之前先确认三件事systemctl status zabbix-server显示服务是active的数据库连接正常Zabbix前端页面能正常展示数据有至少一个监控项和一个触发器在正常工作能产生事件。这个看似废话的检查能帮你省下后面排查时间的一大半。因为很多“邮件发不出去”的案例根因其实是server或数据库挂了。尤其是数据库连接报错——比如热词里提到的“zabbix access denied for user replace_userlocalhost (using password: yes)”——会让整个Zabbix服务处于半瘫痪状态前端能看到页面但server无法正常工作事件产生不了邮件自然不可能发出来。另外还要提醒一句版本差异。Zabbix 5.0之后前端菜单里“报警媒介类型”的位置和名称略有变化但核心配置逻辑一样。我下面的操作以Zabbix 6.0/7.0为例5.0和4.x的界面稍微找一下也能找到对应入口不必担心版本对不上就照搬不了。3. 邮箱端准备SMTP授权码、端口与“先用curl验通”的土办法在Zabbix里填参数之前先把邮箱这一侧准备好。这一步做扎实了后面直接在Zabbix里填就行不用来回折腾。3.1 发件邮箱怎么选从注册到授权码个人项目或者小团队最常见的选择是163邮箱和QQ邮箱。这两个都要求用“授权码”而不是登录密码来发信这是出于安全考虑也意味着你需要在邮箱设置里手动开启SMTP服务并生成授权码。以163邮箱为例登录网页版邮箱进入“设置 → POP3/SMTP/IMAP”开启SMTP服务会要求发一条短信验证之后会给你一串授权码复制保存好。这串授权码就是Zabbix里要填的“密码”。企业邮箱稍微复杂一点。如果你用的是阿里企业邮、腾讯企业邮这类服务后台一般默认开启SMTP有些企业邮箱还需要在后台“客户端设置”里手动勾选“允许SMTP发信”并且可能要求关闭“安全登录”或者单独申请客户端专用密码。这块每个服务商不太一样以你自己企业邮箱后台的实际选项为准。如果是公司自建的Postfix邮件服务器那就更自由了。只要能确认服务器上25端口或者465/587端口对外可达直接用账号密码认证即可。需要留心的是大部分云厂商默认封禁25端口自建邮件服务器想往外发信要么走465/587提交端口要么去云控制台申请解封25端口。3.2 常见邮箱SMTP参数速查把常用的SMTP参数整理成了一张表直接抄就行邮箱服务商SMTP服务器地址SSL端口STARTTLS端口认证方式163邮箱smtp.163.com465587授权码QQ邮箱smtp.qq.com465587授权码Gmailsmtp.gmail.com465587应用专用密码Outlooksmtp.office365.com—587账号密码阿里企业邮smtp.qiye.aliyun.com465587账号密码腾讯企业邮smtp.exmail.qq.com465587客户端专用密码关于SSL和STARTTLS的区别一句话说清楚SSL是马上一上来就建立加密隧道STARTTLS是先走明文连接然后通过命令升级为加密连接。Zabbix的邮件媒介类型里“连接安全”选项有“无”“SSL/TLS”“STARTTLS”三个值照着邮箱服务商的要求选就行。选错的话通常报错是“SSL routines”或者“STARTTLS”相关的握手失败。3.3 先不用Zabbix用curl把SMTP通道验通这是我最想让你养成的一个习惯先在命令行里用curl验证SMTP通道是否通畅再进Zabbix界面配置。因为这样一来出问题的时候你能立刻判断是“网络/邮箱服务商的问题”还是“Zabbix配置的问题”。以163邮箱为例用curl发一封测试邮件的命令长这样curl --url smtps://smtp.163.com:465 \ --ssl-reqd \ --mail-from your_account163.com \ --mail-rcpt recipientexample.com \ --user your_account163.com:你的授权码 \ --upload-file email.txt其中email.txt是邮件内容文件开头按SMTP格式写From: your_account163.com To: recipientexample.com Subject: Zabbix SMTP test This is a test email from curl.如果curl返回“Message accepted”之类的提示说明服务器地址、端口、认证信息全都对了。如果在这里就报错那就没必要去Zabbix界面里折腾了先解决网络或者认证问题。比如常见的“Login denied: authentication failed”就意味着账号或授权码不对跟Zabbix一点关系都没有。另外一个我常用的工具是swaks它是专门用来测试SMTP的小工具比curl更直观swaks --to recipientexample.com \ --from your_account163.com \ --server smtp.163.com:465 \ --auth LOGIN \ --auth-user your_account163.com \ --auth-password 你的授权码 \ --tls看到符号和“250 OK”的返回就算成功。如果没安装yum install swaks或者apt install swaks就能装。4. Zabbix侧配置邮件媒介类型和接收人设置SMTP通道验通了现在可以放心大胆地来配置Zabbix了。这一节把邮件媒介和接收人设置讲透照着操作就行。4.1 配置Email媒介类型在Zabbix前端界面按路径操作“管理Administration→ 报警媒介类型Media types→ 创建报警媒介类型或者直接点击列表里的“Email”进行编辑。关键字段逐一说明名称建议写清楚用途比如“SMTP-163”以后接多个发件邮箱时好区分类型选“Email”如果你要写脚本发邮件也可以选“脚本”后面细说SMTP服务器填smtp.163.com这类地址注意不要加http://前缀SMTP服务器端口465连接安全选SSL/TLS如果邮箱服务商支持STARTTLS就选STARTTLSSSL验证开发环境可以选“不验证”生产环境建议保持默认认证勾选启用用户名填完整的邮箱地址密码填授权码发件人填一个可读的名字比如Zabbix Monitor your_account163.com收件人看到的就是这个名字SMTP helo这个字段容易被忽略。它代表HELO命令里声明的域名某些反垃圾策略会校验这个值和SMTP服务器的IP/域名是否匹配。一般填发件邮箱的域名就行比如163.com。填错的话可能表现为“收件人收到了邮件但被判定为垃圾邮件”或者直接连接被拒启用必须勾选否则白配。填完之后别急着保存先点下方“测试”按钮填一个测试收件人发送测试消息。如果弹出“发送成功”就说明这条链路通了。4.2 给用户绑定邮件收件地址媒介类型配好只是告诉Zabbix“我有这个发信渠道”但系统还得知道“把邮件发给谁”。这一步在用户配置里完成。路径“管理Administration→ 用户Users→ 点击你的用户 → 报警媒介Media标签页 → 添加”。这里要填的字段类型选择刚才配置好的邮件媒介收件人填收件邮箱地址启用时间默认全天即可。如果你们有值班制度可以设置只在工作时间发但说实话监控告警这种事半夜才是更要命的建议全天开启告警级别这里可以按严重级别过滤。默认全选意思是任何级别的告警都往这个邮箱发。如果你希望普通信息不打扰、只在“警告”及以上级别才发就把“信息”“无分类”这些低级别取消掉。关于告警级别Zabbix从低到高依次是未分类、信息、警告、一般严重、严重、灾难。我建议IT信息类告警至少从“警告”开始接收否则一个小波动就刷屏容易让人产生告警疲劳真正的严重告警反而被淹没。配置完用户媒介之后可以在用户列表里点用户名称会看到“报警媒介”下面多了一条记录。到这一步Zabbix已经知道“通过哪个邮箱发信”和“发给谁”了但还缺最后一块拼图——动作Action。没有动作事件产生了也白搭系统不会主动去发邮件。下一节详细说。4.3 关于“脚本”方式的补充如果你对邮件发送有特殊需求比如要通过某个内部邮件网关、或者发件前要加工消息内容可以不选“Email”类型而选“脚本”类型。脚本类型会让你填一个脚本名字和参数列表Zabbix在发送时会调用服务器上对应路径的脚本。我自己的看法是能用内置Email媒介解决的尽量别上脚本。脚本方式引入了额外的维护成本——你要管脚本路径、可执行权限、依赖的Python库、环境变量、日志任何一个环节出问题都够喝一壶的。只有内置方式确实满足不了需求比如要连内网邮件中继但Zabbix服务器上不去外网才考虑脚本。真要用脚本记得把脚本日志写全排错会省事很多。5. 动作Action才是灵魂触发条件、升级策略与模板变量邮件媒介配好了、用户也绑定了邮箱但很多人卡在这一步配置完前面所有内容邮件还是发不出去。为什么因为没配Action。Action才是决定“什么样的事件要发邮件、发给谁、发什么内容”的核心配置。5.1 创建一个触发动作路径“配置Configuration→ 动作Actions→ 右上角‘创建动作’→ 事件源选‘触发器’。进入配置页后从上到下依次设置**“名称”**写清楚这个动作的用途比如“生产环境故障邮件通知”。名字会影响后面在Action log里排查时的辨识度别糊里糊涂写个“动作1”。**“条件Conditions”**是过滤逻辑。默认是“所有触发器事件都匹配”但我们通常要加一些限制常见的条件有触发器严重性Trigger severity大于等于“警告”主机群组Host group包含“生产服务器”触发器名称包含“ERROR”等关键字。条件的匹配类型可以选择“满足所有条件”还是“满足任一条件”。一般选“满足所有条件”逻辑更可控。这里有一个常见误区如果你加了“触发器严重性 ≥ 警告”这个条件那么一个级别为“信息”的触发事件就不会发邮件了。测试时如果用了一个默认级别是“未分类”的临时触发器条件会把事件过滤掉你可能会误以为配置有问题。测试的时候要么建一个够级别的触发器要么临时把条件放宽这点后面在实测环节还会提到。5.2 操作步骤告诉Zabbix“发邮件给谁”“操作Operations”部分是动作的核心默认会有一个初始步骤步骤1。在操作里点击“添加”编辑操作类型选“发送消息”发送给用户选择一个用户或用户组。建议建一个“运维组”用户组把所有该收告警的人拉进去然后操作里直接发给整个组以后加人不用改动作通过何种媒介选中邮件媒介。保存后初始步骤就变成了“在步骤1发送消息给用户组‘运维组’通过‘SMTP-163’”。这里还要说一个非常实用的功能告警升级。Zabbix的动作可以配置多个步骤每个步骤可以设置不同的等待时间。如果你的团队有分级响应制度可以这样配置步骤1立即发送邮件给一线运维组步骤2等待10分钟后如果事件尚未恢复再次发送邮件给一线运维组 二线负责人步骤3等待30分钟后如果事件仍未恢复发送邮件给部门主管。这样配置的好处是普通小故障不会一上来就惊动领导但如果长时间没人处理告警会逐步升级直到有人响应。5.3 消息模板默认模板太简陋建议照抄这份自定义模板Zabbix默认的消息模板只能告诉你“有个触发器出问题了”但具体哪台机器、当前值多少、持续多久全都没有收件人还得登录Zabbix界面去看。把模板变量用好邮件信息量能提升一个档次。在动作编辑页面的“消息模板”区域可以分别设置“问题消息”触发器从正常变异常时发的邮件和“恢复消息”触发器从异常恢复为正常时发的邮件的标题和正文。我实测稳定好用的模板如下可以直接抄问题消息主题[{TRIGGER.STATUS}] {TRIGGER.SEVERITY}: {TRIGGER.NAME}问题消息正文告警主机: {HOST.NAME} 主机地址: {HOST.CONN} 监控项: {ITEM.NAME} 监控键值: {ITEM.KEY} 当前值: {ITEM.LASTVALUE} 告警级别: {TRIGGER.SEVERITY} 告警时间: {EVENT.DATE} {EVENT.TIME} 事件ID: {EVENT.ID} {TRIGGER.DESCRIPTION}恢复消息主题[恢复] {TRIGGER.SEVERITY}: {HOST.NAME} {TRIGGER.NAME}恢复消息正文故障主机: {HOST.NAME} 监控项: {ITEM.NAME} 恢复时间: {EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME} 持续时长: {EVENT.AGE} {TRIGGER.DESCRIPTION}这里面的宏变量是Zabbix内置的发送邮件时会自动替换成实际值。我最常用的几个变量{HOST.NAME}主机名{HOST.CONN}主机的连接地址也就是IP{TRIGGER.NAME}触发器名称{TRIGGER.SEVERITY}告警级别{ITEM.NAME}触发告警的监控项名称{ITEM.LASTVALUE}监控项最新值也就是触发告警时的实测值{EVENT.DATE}和{EVENT.TIME}事件发生日期时间{EVENT.AGE}事件持续时间恢复消息里特别有用。除此之外还要在配置页底部的“恢复操作Recovery operations”里勾选“向所有问题接收人发送恢复消息”。这样故障恢复后收件人会收到一封恢复邮件形成一个完整的闭环。如果不配恢复消息运维人员只能干等着看后续还有没有新告警来判断是否恢复体验差很多。5.4 告警风暴的预防别让你的邮箱被刷爆配好动作之后另一个现实问题是告警风暴——某个监控项异常后触发器每隔一分钟就产生一个新事件邮件一封接一封轰炸。预防告警风暴有几个层面触发器层面在触发器配置里把“允许多重事件允许手动关闭除外”改为“不允许多重事件”这样同一个触发器在第一次事件未恢复前不会反复产生新事件动作层面设置“重复告警间隔”比如30分钟意思是同一事件持续未恢复时最多每30分钟通知一次运维层面告警级别区分对待低级告警只做记录不通知高级告警才发邮件。这三种手段组合起来基本能把弹性云主机偶发CPU飙高导致的邮件轰炸挡住。这个经验是我在真实环境里被轰过之后得出的教训第一版配置没做任何限制结果一台机器磁盘告警一个下午邮箱里多了几百封邮件之后大家看到邮件都麻木了。6. 真刀真枪验证制造一次故障把邮件打出来配置全部完成之后必须实际测试一遍不要只看界面提示“发送成功”就觉得万事大吉。前面说过链路很长界面测试只验证了SMTP通道但事件从产生到触发动作再到真正发信中间还有若干环节必须人为制造一个真实事件来跑一遍完整链路。6.1 创建一个测试触发器找一个已有的监控项来创建临时触发器。以Zabbix Server自带的主机监控项system.cpu.load为例进入**“配置Configuration→ 主机Hosts→ 找到Zabbix server → 触发器Triggers→ 创建触发器**。名称写“TEST-邮件报警测试触发器”严重性选“警告”表达式写last(/Zabbix server/system.cpu.load[avg1])0.01这个表达式表示“CPU平均负载大于0.01就触发”——正常机器的负载远高于0.01所以几乎立刻会触发。这里用0.01这个极低阈值是为了让触发器必然成立从而必然产生事件。测试完成后把这个临时触发器删掉即可不影响正式监控。注意前面提到的条件问题如果你在动作里设置了“严重性 ≥ 警告”的条件这里就要把严重性选为“警告”或更高否则事件会被动作过滤掉邮件不触发。6.2 观察事件产生和动作执行保存触发器后正常情况下几秒钟内就能看到事件状态变化。去**“监测Monitoring→ 问题Problems**页面能看到这条新增的问题记录。然后去**“报表Reports→ 动作日志Action log**这里记录了所有动作的执行情况。如果配置正确日志里应该显示状态已发送Sent消息内容包含你自定义模板里填的那些变量解析后的值接收人你绑定的邮箱地址。如果这里显示“失败Failed”点击详情能查看具体错误信息。动作日志是排查邮件报警问题的第一站比看Zabbix server日志更直接。90%的“为什么没收到邮件”问题在这里几秒钟就能定位到是动作没触发、还是发送失败、还是消息模板解析报错。6.3 验证收件和恢复闭环动作日志显示已发送后去邮箱看邮件。正常情况下一两分钟内就能收到。我遇到过一种情况是动作日志显示“已发送”但邮箱里死活找不到邮件——最后发现在垃圾箱里。原因是发件邮箱域名没有配置SPF和DKIM记录被收件方判定为垃圾邮件。这个问题在自建邮件服务器上尤其常见后面排错章节会细说。验证完告警邮件再把临时触发器改一个永不成立的值比如last(/Zabbix server/system.cpu.load[avg1])1000这样触发器会从异常恢复为正常看恢复邮件能不能收到。收到恢复邮件说明整个闭环是完整的问题产生→通知→恢复→再通知。6.4 测试完成后的清理测试完成后一定记得删掉临时触发器。我之前犯过的错就是留着测试触发器忘了删结果半夜机器负载稍微高了一点“TEST-邮件报警测试触发器”和正式触发器一起触发把值班同事吓一跳。清理动作包括删除临时触发器、删除测试用的临时监控项如果是新建的、确认动作日志里没有异常堆积的测试记录。7. 邮件报警高频报错对照从收不到到登录失败的全排查最后这一部分把配置邮件报警过程中最高频的报错和排查思路整理出来。这些案例基本覆盖了从“收不到邮件”到“登录失败”的各种情况是我在不同环境里实测过的。7.1 动作日志显示“已发送”但收件人没收到邮件这是最隐蔽的一类问题因为Zabbix这边认为自己成功把消息交给了SMTP服务器但实际上邮件没有进到收件箱。排查链路先看垃圾箱这是最常见的原因。发件邮箱域名如果是新注册的、或者没有配置SPF/DKIM记录收件方很可能把邮件判为垃圾邮件。解决方法是在发件域名DNS里加上SPF记录和DKIM记录确认收件地址是否拼写正确用户媒介配置里填的收件人有时候会因为手误写错后缀看发件邮箱的“已发送”记录。如果用163/QQ这类个人邮箱登录网页版能看到发件记录如果显示发送成功说明问题出在收件方如果显示退信退信原因通常写得很明确检查SMTP服务的发送频率限制。163这类邮箱对单日发送量有限制如果Zabbix告警量很大可能出现发送被限流的情况动作日志可能仍然显示已发送但邮件服务商实际并没有把信投出去。7.2 认证失败Login denied / authentication failed这个报错非常直白就是账号或密码不对。但这里有几个容易忽略的点密码必须填授权码不是邮箱登录密码。好多人第一次配163邮箱填了真正的登录密码必然报认证失败账号里的符号在某些配置里需要处理。虽然Zabbix界面里填完整的邮箱地址一般没问题但如果有些内部脚本拼接配置时可能会转义出错授权码是否过期。部分邮箱服务的授权码有有效期过期之后必须重新生成如果之前配置是好的、某一天突然开始报认证失败优先检查授权码是否被重置或吊销。我就遇到过用户以为授权码泄露在邮箱后台重新生成了一串新的但Zabbix里没同步导致报警全部失败。7.3 连接失败Connection refused / timeout / No route to host这类错误说明Zabbix服务器到SMTP服务器的网络不通或者端口不对。排查步骤先在Zabbix服务器上手动测连通性nc -zv smtp.163.com 465看端口是否通如果不通检查本地防火墙firewalld/iptables是否限制出站端口如果用的是云服务器检查安全组是否放行了465/587/25端口。有部分云厂商默认封禁25端口出站即使你用的是465端口最好也确认一下检查SMTP服务器地址是否填错有没有多加空格、多加http://前缀。一个冷知识某些企业内网环境Zabbix服务器访问外网需要走代理而邮件SMTP走的是TCP直连代理环境下一股脑把所有流量都交给代理时SMTP连接就会超时。这种情况要么给Zabbix服务器配置NO_PROXY例外要么改用公司内部的邮件中继服务器。7.4 Zabbix server is not running配置了也白搭开头提到过这个前置问题这里展开说一下。如果Zabbix前端页面顶部有“Zabbix server is not running”的红色警告横幅说明server进程本身没有正常工作。邮件配置得再完美事件产生不了一切白搭。常见原因和对策数据库连接不上。如果数据库账号密码错误会在/var/log/zabbix/zabbix_server.log里看到类似“Access denied for user xxxlocalhost (using password: YES)”的报错。这时候去检查Zabbix配置文件/etc/zabbix/zabbix_server.conf里的DBUser、DBPassword参数如果密码里含特殊字符确保在配置里正确转义或加引号Server进程没起来。执行systemctl status zabbix-server查看状态起不来就看日志里的具体报错数据库表损坏或版本不匹配。升级Zabbix时如果没有正确执行数据库迁移也可能出现server起不来的情况。收到这个骗子信息的时候别在“报警媒介配置”里浪费精力先把server状态恢复了再说。7.5 脚本方式发信失败排查顺序要记牢如果你用的是“脚本”类型媒介报错信息往往不那么直观。排查顺序建议为先在命令行里手动执行一遍脚本确认脚本本身逻辑正常。很多同学一上来就去翻Zabbix日志结果发现脚本在命令行下就抛异常了确认脚本有可执行权限。Zabbix进程运行账号通常叫zabbix必须对该脚本有执行权限而且脚本所在目录要对zabbix用户开放读权限注意环境变量。Zabbix调用脚本时的环境变量很干净不像你手动在shell里执行的终端环境。如果脚本里用了Python、pip安装的第三方库但那个库装在了非系统路径下脚本可能因为找不到模块而失败脚本日志要写全。Zabbix对脚本的标准输出和标准错误处理得比较隐晦靠谱做法是脚本内自己写日志文件出错时直接打开日志看。我在生产环境里维护过几个脚本类型的报警媒介经验是脚本能不用就不用能用内置Email就绝不自己造轮子。这跟你手动配置SMTP的维护成本完全不是一个量级。7.6 时间问题告警时间和实际时间对不上还有一个不算报错但很影响体验的问题邮件里的时间比当前时间晚了8个小时或者差了十几分钟。前者通常是Zabbix服务器时区没设对——检查/etc/zabbix/zabbix_server.conf里的StartAgents相关的时区配置、PHP时区date.timezone以及操作系统时区三者保持一致。后者通常是监控项的数据采集间隔造成的告警时间记录的是采集时刻的数据判定时间不是邮件发送时间这个不用纠结。我个人的习惯是把服务器时区统一设为Asia/ShanghaiZabbix前端和告警邮件的时区都跟着统一就不会出现同一个告警在不同界面显示时间不一致的别扭情况。写在最后邮件报警只是起点不是终点配置好Zabbix邮箱报警只是监控体系里最基础的一步。我个人在实际使用中有几条体会值得分享第一邮件报警建议作为全量告警的兜底渠道但不要让所有告警都只依赖邮件。重要级别高、需要立即响应的告警可以叠加短信、电话或者钉钉/企微机器人。邮件负责“有记录、不遗漏”即时渠道负责“叫得醒、赶得上”。第二动作消息模板里的宏最好自己定制一遍默认模板的信息量太少收件人还要登录界面去看监控项详情非常影响响应速度。第三定期检查发件邮箱的授权码是否过期、邮件是否进了垃圾箱、动作日志里有没有积压的失败记录——这些平时不显眼关键时刻全都会冒出来咬你一口。Zabbix的报警体系远不止邮件这一种玩法动作升级策略、宏定义、结合脚本做自定义通知都有很大的折腾空间。先把邮件这条最基础的路铺好后面接什么都顺手。如果你在配置过程中遇到了这里没覆盖到的报错欢迎留言我帮你一起看。
Zabbix邮件报警配置实战：从SMTP到触发器告警
监控装好了机房拓扑也画得漂漂亮亮的但真正出事那天早上你是被电话叫醒而不是被Zabbix的报警邮件叫醒的——这种尴尬我经历过一次之后就再也没让它发生过。Zabbix配置邮箱报警这件事听起来就是填几个SMTP参数的事但实际落地时会遇到授权码、消息模板、动作触发条件、告警风暴一堆坑。这篇文章我就把从零到一配置邮箱报警的完整过程写出来包括踩过的坑、排查思路和可以直接抄的配置给正在折腾Zabbix报警的同学做个参考。1. 为什么最终选了邮件报警监控通知渠道的选型实录先说结论邮件报警不是最快的通知方式但它是整个监控体系里最值得优先配好的兜底通道。我之前给一个朋友的创业公司搭监控他们当时纠结要不要直接上钉钉机器人。钉钉机器人确实香群里所有人手机弹通知看起来比邮件高级多了。但我问了一句万一你们公司用的办公软件换了怎么办钉钉的Webhook地址失效了怎么办到时候是不是又要重新配一遍他们沉默了。邮件报警的优势恰恰在于它的“无聊”和“稳定”。SMTP协议几十年没大变过邮箱服务商再怎么迭代邮件收发的基本路径永远是通的。而且邮件有天然的事后追溯能力告警发生了、谁处理的、几点恢复的都在邮箱里有记录。对于没有专职运维的小团队来说邮件就是最便宜的告警审计系统。对比一下常见通知渠道的适用场景你就明白我为啥把邮件放在第一位通知渠道实时性依赖条件事后追溯成本适合场景邮件中等通常秒级到分钟级邮箱服务商稳定可用强天然留痕几乎为零全量告警通知、审计、值班记录钉钉/企微群机器人高取决于群成员是否看到第三方办公软件可用一般消息易被刷掉低日常告警群播报短信高短信服务商、资费一般高重要告警、夜间值班电话语音极高语音服务商弱很高P1级故障、半夜宕机所以我的建议是第一优先级把邮件报警配好覆盖所有中低级别告警第二优先级再接钉钉机器人这类即时渠道覆盖需要快速响应的告警短信和电话留给真正的大事。邮件报警的定位是“不漏报、有记录”它不负责“秒级叫醒”那是短信和电话的事儿。如果你现在一套报警都没有别犹豫先把邮件配起来这是性价比最高的第一步。2. 报警链路拆解一条告警从产生到进收件箱要经过哪几道关卡很多新手配置邮箱报警失败不是因为SMTP参数填错而是根本不清楚Zabbix内部那条报警链路是怎么走的。邮件只是在链路最后一步负责把消息送出去前面的环节出任何一个问题邮件都发不出来。一条Zabbix报警消息从产生到进入你的收件箱完整路径是这样的监控项Item采集到某个数据比如CPU负载、磁盘使用率、ping丢包率触发器Trigger对采集到的值做判断表达式成立就产生一个事件Event动作Action匹配到这个事件检查事件是否满足自己设定的条件如果条件满足动作执行操作比如“发送消息给用户组”消息通过用户绑定的报警媒介Media Type发送邮件就是其中一种媒介SMTP服务器把邮件投递到收件人邮箱。这里有一个特别容易忽略的前提整个链路的前置条件是Zabbix Server本身必须正常运行。如果你打开Zabbix前端页面顶部横幅显示“Zabbix server is not running: the information displayed may not be current.”那后面所有配置都白搭——server都没起来哪来的事件哪来的动作执行所以配置邮箱报警之前先确认三件事systemctl status zabbix-server显示服务是active的数据库连接正常Zabbix前端页面能正常展示数据有至少一个监控项和一个触发器在正常工作能产生事件。这个看似废话的检查能帮你省下后面排查时间的一大半。因为很多“邮件发不出去”的案例根因其实是server或数据库挂了。尤其是数据库连接报错——比如热词里提到的“zabbix access denied for user replace_userlocalhost (using password: yes)”——会让整个Zabbix服务处于半瘫痪状态前端能看到页面但server无法正常工作事件产生不了邮件自然不可能发出来。另外还要提醒一句版本差异。Zabbix 5.0之后前端菜单里“报警媒介类型”的位置和名称略有变化但核心配置逻辑一样。我下面的操作以Zabbix 6.0/7.0为例5.0和4.x的界面稍微找一下也能找到对应入口不必担心版本对不上就照搬不了。3. 邮箱端准备SMTP授权码、端口与“先用curl验通”的土办法在Zabbix里填参数之前先把邮箱这一侧准备好。这一步做扎实了后面直接在Zabbix里填就行不用来回折腾。3.1 发件邮箱怎么选从注册到授权码个人项目或者小团队最常见的选择是163邮箱和QQ邮箱。这两个都要求用“授权码”而不是登录密码来发信这是出于安全考虑也意味着你需要在邮箱设置里手动开启SMTP服务并生成授权码。以163邮箱为例登录网页版邮箱进入“设置 → POP3/SMTP/IMAP”开启SMTP服务会要求发一条短信验证之后会给你一串授权码复制保存好。这串授权码就是Zabbix里要填的“密码”。企业邮箱稍微复杂一点。如果你用的是阿里企业邮、腾讯企业邮这类服务后台一般默认开启SMTP有些企业邮箱还需要在后台“客户端设置”里手动勾选“允许SMTP发信”并且可能要求关闭“安全登录”或者单独申请客户端专用密码。这块每个服务商不太一样以你自己企业邮箱后台的实际选项为准。如果是公司自建的Postfix邮件服务器那就更自由了。只要能确认服务器上25端口或者465/587端口对外可达直接用账号密码认证即可。需要留心的是大部分云厂商默认封禁25端口自建邮件服务器想往外发信要么走465/587提交端口要么去云控制台申请解封25端口。3.2 常见邮箱SMTP参数速查把常用的SMTP参数整理成了一张表直接抄就行邮箱服务商SMTP服务器地址SSL端口STARTTLS端口认证方式163邮箱smtp.163.com465587授权码QQ邮箱smtp.qq.com465587授权码Gmailsmtp.gmail.com465587应用专用密码Outlooksmtp.office365.com—587账号密码阿里企业邮smtp.qiye.aliyun.com465587账号密码腾讯企业邮smtp.exmail.qq.com465587客户端专用密码关于SSL和STARTTLS的区别一句话说清楚SSL是马上一上来就建立加密隧道STARTTLS是先走明文连接然后通过命令升级为加密连接。Zabbix的邮件媒介类型里“连接安全”选项有“无”“SSL/TLS”“STARTTLS”三个值照着邮箱服务商的要求选就行。选错的话通常报错是“SSL routines”或者“STARTTLS”相关的握手失败。3.3 先不用Zabbix用curl把SMTP通道验通这是我最想让你养成的一个习惯先在命令行里用curl验证SMTP通道是否通畅再进Zabbix界面配置。因为这样一来出问题的时候你能立刻判断是“网络/邮箱服务商的问题”还是“Zabbix配置的问题”。以163邮箱为例用curl发一封测试邮件的命令长这样curl --url smtps://smtp.163.com:465 \ --ssl-reqd \ --mail-from your_account163.com \ --mail-rcpt recipientexample.com \ --user your_account163.com:你的授权码 \ --upload-file email.txt其中email.txt是邮件内容文件开头按SMTP格式写From: your_account163.com To: recipientexample.com Subject: Zabbix SMTP test This is a test email from curl.如果curl返回“Message accepted”之类的提示说明服务器地址、端口、认证信息全都对了。如果在这里就报错那就没必要去Zabbix界面里折腾了先解决网络或者认证问题。比如常见的“Login denied: authentication failed”就意味着账号或授权码不对跟Zabbix一点关系都没有。另外一个我常用的工具是swaks它是专门用来测试SMTP的小工具比curl更直观swaks --to recipientexample.com \ --from your_account163.com \ --server smtp.163.com:465 \ --auth LOGIN \ --auth-user your_account163.com \ --auth-password 你的授权码 \ --tls看到符号和“250 OK”的返回就算成功。如果没安装yum install swaks或者apt install swaks就能装。4. Zabbix侧配置邮件媒介类型和接收人设置SMTP通道验通了现在可以放心大胆地来配置Zabbix了。这一节把邮件媒介和接收人设置讲透照着操作就行。4.1 配置Email媒介类型在Zabbix前端界面按路径操作“管理Administration→ 报警媒介类型Media types→ 创建报警媒介类型或者直接点击列表里的“Email”进行编辑。关键字段逐一说明名称建议写清楚用途比如“SMTP-163”以后接多个发件邮箱时好区分类型选“Email”如果你要写脚本发邮件也可以选“脚本”后面细说SMTP服务器填smtp.163.com这类地址注意不要加http://前缀SMTP服务器端口465连接安全选SSL/TLS如果邮箱服务商支持STARTTLS就选STARTTLSSSL验证开发环境可以选“不验证”生产环境建议保持默认认证勾选启用用户名填完整的邮箱地址密码填授权码发件人填一个可读的名字比如Zabbix Monitor your_account163.com收件人看到的就是这个名字SMTP helo这个字段容易被忽略。它代表HELO命令里声明的域名某些反垃圾策略会校验这个值和SMTP服务器的IP/域名是否匹配。一般填发件邮箱的域名就行比如163.com。填错的话可能表现为“收件人收到了邮件但被判定为垃圾邮件”或者直接连接被拒启用必须勾选否则白配。填完之后别急着保存先点下方“测试”按钮填一个测试收件人发送测试消息。如果弹出“发送成功”就说明这条链路通了。4.2 给用户绑定邮件收件地址媒介类型配好只是告诉Zabbix“我有这个发信渠道”但系统还得知道“把邮件发给谁”。这一步在用户配置里完成。路径“管理Administration→ 用户Users→ 点击你的用户 → 报警媒介Media标签页 → 添加”。这里要填的字段类型选择刚才配置好的邮件媒介收件人填收件邮箱地址启用时间默认全天即可。如果你们有值班制度可以设置只在工作时间发但说实话监控告警这种事半夜才是更要命的建议全天开启告警级别这里可以按严重级别过滤。默认全选意思是任何级别的告警都往这个邮箱发。如果你希望普通信息不打扰、只在“警告”及以上级别才发就把“信息”“无分类”这些低级别取消掉。关于告警级别Zabbix从低到高依次是未分类、信息、警告、一般严重、严重、灾难。我建议IT信息类告警至少从“警告”开始接收否则一个小波动就刷屏容易让人产生告警疲劳真正的严重告警反而被淹没。配置完用户媒介之后可以在用户列表里点用户名称会看到“报警媒介”下面多了一条记录。到这一步Zabbix已经知道“通过哪个邮箱发信”和“发给谁”了但还缺最后一块拼图——动作Action。没有动作事件产生了也白搭系统不会主动去发邮件。下一节详细说。4.3 关于“脚本”方式的补充如果你对邮件发送有特殊需求比如要通过某个内部邮件网关、或者发件前要加工消息内容可以不选“Email”类型而选“脚本”类型。脚本类型会让你填一个脚本名字和参数列表Zabbix在发送时会调用服务器上对应路径的脚本。我自己的看法是能用内置Email媒介解决的尽量别上脚本。脚本方式引入了额外的维护成本——你要管脚本路径、可执行权限、依赖的Python库、环境变量、日志任何一个环节出问题都够喝一壶的。只有内置方式确实满足不了需求比如要连内网邮件中继但Zabbix服务器上不去外网才考虑脚本。真要用脚本记得把脚本日志写全排错会省事很多。5. 动作Action才是灵魂触发条件、升级策略与模板变量邮件媒介配好了、用户也绑定了邮箱但很多人卡在这一步配置完前面所有内容邮件还是发不出去。为什么因为没配Action。Action才是决定“什么样的事件要发邮件、发给谁、发什么内容”的核心配置。5.1 创建一个触发动作路径“配置Configuration→ 动作Actions→ 右上角‘创建动作’→ 事件源选‘触发器’。进入配置页后从上到下依次设置**“名称”**写清楚这个动作的用途比如“生产环境故障邮件通知”。名字会影响后面在Action log里排查时的辨识度别糊里糊涂写个“动作1”。**“条件Conditions”**是过滤逻辑。默认是“所有触发器事件都匹配”但我们通常要加一些限制常见的条件有触发器严重性Trigger severity大于等于“警告”主机群组Host group包含“生产服务器”触发器名称包含“ERROR”等关键字。条件的匹配类型可以选择“满足所有条件”还是“满足任一条件”。一般选“满足所有条件”逻辑更可控。这里有一个常见误区如果你加了“触发器严重性 ≥ 警告”这个条件那么一个级别为“信息”的触发事件就不会发邮件了。测试时如果用了一个默认级别是“未分类”的临时触发器条件会把事件过滤掉你可能会误以为配置有问题。测试的时候要么建一个够级别的触发器要么临时把条件放宽这点后面在实测环节还会提到。5.2 操作步骤告诉Zabbix“发邮件给谁”“操作Operations”部分是动作的核心默认会有一个初始步骤步骤1。在操作里点击“添加”编辑操作类型选“发送消息”发送给用户选择一个用户或用户组。建议建一个“运维组”用户组把所有该收告警的人拉进去然后操作里直接发给整个组以后加人不用改动作通过何种媒介选中邮件媒介。保存后初始步骤就变成了“在步骤1发送消息给用户组‘运维组’通过‘SMTP-163’”。这里还要说一个非常实用的功能告警升级。Zabbix的动作可以配置多个步骤每个步骤可以设置不同的等待时间。如果你的团队有分级响应制度可以这样配置步骤1立即发送邮件给一线运维组步骤2等待10分钟后如果事件尚未恢复再次发送邮件给一线运维组 二线负责人步骤3等待30分钟后如果事件仍未恢复发送邮件给部门主管。这样配置的好处是普通小故障不会一上来就惊动领导但如果长时间没人处理告警会逐步升级直到有人响应。5.3 消息模板默认模板太简陋建议照抄这份自定义模板Zabbix默认的消息模板只能告诉你“有个触发器出问题了”但具体哪台机器、当前值多少、持续多久全都没有收件人还得登录Zabbix界面去看。把模板变量用好邮件信息量能提升一个档次。在动作编辑页面的“消息模板”区域可以分别设置“问题消息”触发器从正常变异常时发的邮件和“恢复消息”触发器从异常恢复为正常时发的邮件的标题和正文。我实测稳定好用的模板如下可以直接抄问题消息主题[{TRIGGER.STATUS}] {TRIGGER.SEVERITY}: {TRIGGER.NAME}问题消息正文告警主机: {HOST.NAME} 主机地址: {HOST.CONN} 监控项: {ITEM.NAME} 监控键值: {ITEM.KEY} 当前值: {ITEM.LASTVALUE} 告警级别: {TRIGGER.SEVERITY} 告警时间: {EVENT.DATE} {EVENT.TIME} 事件ID: {EVENT.ID} {TRIGGER.DESCRIPTION}恢复消息主题[恢复] {TRIGGER.SEVERITY}: {HOST.NAME} {TRIGGER.NAME}恢复消息正文故障主机: {HOST.NAME} 监控项: {ITEM.NAME} 恢复时间: {EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME} 持续时长: {EVENT.AGE} {TRIGGER.DESCRIPTION}这里面的宏变量是Zabbix内置的发送邮件时会自动替换成实际值。我最常用的几个变量{HOST.NAME}主机名{HOST.CONN}主机的连接地址也就是IP{TRIGGER.NAME}触发器名称{TRIGGER.SEVERITY}告警级别{ITEM.NAME}触发告警的监控项名称{ITEM.LASTVALUE}监控项最新值也就是触发告警时的实测值{EVENT.DATE}和{EVENT.TIME}事件发生日期时间{EVENT.AGE}事件持续时间恢复消息里特别有用。除此之外还要在配置页底部的“恢复操作Recovery operations”里勾选“向所有问题接收人发送恢复消息”。这样故障恢复后收件人会收到一封恢复邮件形成一个完整的闭环。如果不配恢复消息运维人员只能干等着看后续还有没有新告警来判断是否恢复体验差很多。5.4 告警风暴的预防别让你的邮箱被刷爆配好动作之后另一个现实问题是告警风暴——某个监控项异常后触发器每隔一分钟就产生一个新事件邮件一封接一封轰炸。预防告警风暴有几个层面触发器层面在触发器配置里把“允许多重事件允许手动关闭除外”改为“不允许多重事件”这样同一个触发器在第一次事件未恢复前不会反复产生新事件动作层面设置“重复告警间隔”比如30分钟意思是同一事件持续未恢复时最多每30分钟通知一次运维层面告警级别区分对待低级告警只做记录不通知高级告警才发邮件。这三种手段组合起来基本能把弹性云主机偶发CPU飙高导致的邮件轰炸挡住。这个经验是我在真实环境里被轰过之后得出的教训第一版配置没做任何限制结果一台机器磁盘告警一个下午邮箱里多了几百封邮件之后大家看到邮件都麻木了。6. 真刀真枪验证制造一次故障把邮件打出来配置全部完成之后必须实际测试一遍不要只看界面提示“发送成功”就觉得万事大吉。前面说过链路很长界面测试只验证了SMTP通道但事件从产生到触发动作再到真正发信中间还有若干环节必须人为制造一个真实事件来跑一遍完整链路。6.1 创建一个测试触发器找一个已有的监控项来创建临时触发器。以Zabbix Server自带的主机监控项system.cpu.load为例进入**“配置Configuration→ 主机Hosts→ 找到Zabbix server → 触发器Triggers→ 创建触发器**。名称写“TEST-邮件报警测试触发器”严重性选“警告”表达式写last(/Zabbix server/system.cpu.load[avg1])0.01这个表达式表示“CPU平均负载大于0.01就触发”——正常机器的负载远高于0.01所以几乎立刻会触发。这里用0.01这个极低阈值是为了让触发器必然成立从而必然产生事件。测试完成后把这个临时触发器删掉即可不影响正式监控。注意前面提到的条件问题如果你在动作里设置了“严重性 ≥ 警告”的条件这里就要把严重性选为“警告”或更高否则事件会被动作过滤掉邮件不触发。6.2 观察事件产生和动作执行保存触发器后正常情况下几秒钟内就能看到事件状态变化。去**“监测Monitoring→ 问题Problems**页面能看到这条新增的问题记录。然后去**“报表Reports→ 动作日志Action log**这里记录了所有动作的执行情况。如果配置正确日志里应该显示状态已发送Sent消息内容包含你自定义模板里填的那些变量解析后的值接收人你绑定的邮箱地址。如果这里显示“失败Failed”点击详情能查看具体错误信息。动作日志是排查邮件报警问题的第一站比看Zabbix server日志更直接。90%的“为什么没收到邮件”问题在这里几秒钟就能定位到是动作没触发、还是发送失败、还是消息模板解析报错。6.3 验证收件和恢复闭环动作日志显示已发送后去邮箱看邮件。正常情况下一两分钟内就能收到。我遇到过一种情况是动作日志显示“已发送”但邮箱里死活找不到邮件——最后发现在垃圾箱里。原因是发件邮箱域名没有配置SPF和DKIM记录被收件方判定为垃圾邮件。这个问题在自建邮件服务器上尤其常见后面排错章节会细说。验证完告警邮件再把临时触发器改一个永不成立的值比如last(/Zabbix server/system.cpu.load[avg1])1000这样触发器会从异常恢复为正常看恢复邮件能不能收到。收到恢复邮件说明整个闭环是完整的问题产生→通知→恢复→再通知。6.4 测试完成后的清理测试完成后一定记得删掉临时触发器。我之前犯过的错就是留着测试触发器忘了删结果半夜机器负载稍微高了一点“TEST-邮件报警测试触发器”和正式触发器一起触发把值班同事吓一跳。清理动作包括删除临时触发器、删除测试用的临时监控项如果是新建的、确认动作日志里没有异常堆积的测试记录。7. 邮件报警高频报错对照从收不到到登录失败的全排查最后这一部分把配置邮件报警过程中最高频的报错和排查思路整理出来。这些案例基本覆盖了从“收不到邮件”到“登录失败”的各种情况是我在不同环境里实测过的。7.1 动作日志显示“已发送”但收件人没收到邮件这是最隐蔽的一类问题因为Zabbix这边认为自己成功把消息交给了SMTP服务器但实际上邮件没有进到收件箱。排查链路先看垃圾箱这是最常见的原因。发件邮箱域名如果是新注册的、或者没有配置SPF/DKIM记录收件方很可能把邮件判为垃圾邮件。解决方法是在发件域名DNS里加上SPF记录和DKIM记录确认收件地址是否拼写正确用户媒介配置里填的收件人有时候会因为手误写错后缀看发件邮箱的“已发送”记录。如果用163/QQ这类个人邮箱登录网页版能看到发件记录如果显示发送成功说明问题出在收件方如果显示退信退信原因通常写得很明确检查SMTP服务的发送频率限制。163这类邮箱对单日发送量有限制如果Zabbix告警量很大可能出现发送被限流的情况动作日志可能仍然显示已发送但邮件服务商实际并没有把信投出去。7.2 认证失败Login denied / authentication failed这个报错非常直白就是账号或密码不对。但这里有几个容易忽略的点密码必须填授权码不是邮箱登录密码。好多人第一次配163邮箱填了真正的登录密码必然报认证失败账号里的符号在某些配置里需要处理。虽然Zabbix界面里填完整的邮箱地址一般没问题但如果有些内部脚本拼接配置时可能会转义出错授权码是否过期。部分邮箱服务的授权码有有效期过期之后必须重新生成如果之前配置是好的、某一天突然开始报认证失败优先检查授权码是否被重置或吊销。我就遇到过用户以为授权码泄露在邮箱后台重新生成了一串新的但Zabbix里没同步导致报警全部失败。7.3 连接失败Connection refused / timeout / No route to host这类错误说明Zabbix服务器到SMTP服务器的网络不通或者端口不对。排查步骤先在Zabbix服务器上手动测连通性nc -zv smtp.163.com 465看端口是否通如果不通检查本地防火墙firewalld/iptables是否限制出站端口如果用的是云服务器检查安全组是否放行了465/587/25端口。有部分云厂商默认封禁25端口出站即使你用的是465端口最好也确认一下检查SMTP服务器地址是否填错有没有多加空格、多加http://前缀。一个冷知识某些企业内网环境Zabbix服务器访问外网需要走代理而邮件SMTP走的是TCP直连代理环境下一股脑把所有流量都交给代理时SMTP连接就会超时。这种情况要么给Zabbix服务器配置NO_PROXY例外要么改用公司内部的邮件中继服务器。7.4 Zabbix server is not running配置了也白搭开头提到过这个前置问题这里展开说一下。如果Zabbix前端页面顶部有“Zabbix server is not running”的红色警告横幅说明server进程本身没有正常工作。邮件配置得再完美事件产生不了一切白搭。常见原因和对策数据库连接不上。如果数据库账号密码错误会在/var/log/zabbix/zabbix_server.log里看到类似“Access denied for user xxxlocalhost (using password: YES)”的报错。这时候去检查Zabbix配置文件/etc/zabbix/zabbix_server.conf里的DBUser、DBPassword参数如果密码里含特殊字符确保在配置里正确转义或加引号Server进程没起来。执行systemctl status zabbix-server查看状态起不来就看日志里的具体报错数据库表损坏或版本不匹配。升级Zabbix时如果没有正确执行数据库迁移也可能出现server起不来的情况。收到这个骗子信息的时候别在“报警媒介配置”里浪费精力先把server状态恢复了再说。7.5 脚本方式发信失败排查顺序要记牢如果你用的是“脚本”类型媒介报错信息往往不那么直观。排查顺序建议为先在命令行里手动执行一遍脚本确认脚本本身逻辑正常。很多同学一上来就去翻Zabbix日志结果发现脚本在命令行下就抛异常了确认脚本有可执行权限。Zabbix进程运行账号通常叫zabbix必须对该脚本有执行权限而且脚本所在目录要对zabbix用户开放读权限注意环境变量。Zabbix调用脚本时的环境变量很干净不像你手动在shell里执行的终端环境。如果脚本里用了Python、pip安装的第三方库但那个库装在了非系统路径下脚本可能因为找不到模块而失败脚本日志要写全。Zabbix对脚本的标准输出和标准错误处理得比较隐晦靠谱做法是脚本内自己写日志文件出错时直接打开日志看。我在生产环境里维护过几个脚本类型的报警媒介经验是脚本能不用就不用能用内置Email就绝不自己造轮子。这跟你手动配置SMTP的维护成本完全不是一个量级。7.6 时间问题告警时间和实际时间对不上还有一个不算报错但很影响体验的问题邮件里的时间比当前时间晚了8个小时或者差了十几分钟。前者通常是Zabbix服务器时区没设对——检查/etc/zabbix/zabbix_server.conf里的StartAgents相关的时区配置、PHP时区date.timezone以及操作系统时区三者保持一致。后者通常是监控项的数据采集间隔造成的告警时间记录的是采集时刻的数据判定时间不是邮件发送时间这个不用纠结。我个人的习惯是把服务器时区统一设为Asia/ShanghaiZabbix前端和告警邮件的时区都跟着统一就不会出现同一个告警在不同界面显示时间不一致的别扭情况。写在最后邮件报警只是起点不是终点配置好Zabbix邮箱报警只是监控体系里最基础的一步。我个人在实际使用中有几条体会值得分享第一邮件报警建议作为全量告警的兜底渠道但不要让所有告警都只依赖邮件。重要级别高、需要立即响应的告警可以叠加短信、电话或者钉钉/企微机器人。邮件负责“有记录、不遗漏”即时渠道负责“叫得醒、赶得上”。第二动作消息模板里的宏最好自己定制一遍默认模板的信息量太少收件人还要登录界面去看监控项详情非常影响响应速度。第三定期检查发件邮箱的授权码是否过期、邮件是否进了垃圾箱、动作日志里有没有积压的失败记录——这些平时不显眼关键时刻全都会冒出来咬你一口。Zabbix的报警体系远不止邮件这一种玩法动作升级策略、宏定义、结合脚本做自定义通知都有很大的折腾空间。先把邮件这条最基础的路铺好后面接什么都顺手。如果你在配置过程中遇到了这里没覆盖到的报错欢迎留言我帮你一起看。
