企业官网建设流程全解析

做 Zabbix 监控这行的人，多少都有过这样的经历：仪表盘搭得漂漂亮亮，触发器阈值也调得刚刚好，可真到半夜 CPU 打满、磁盘写爆的时候，手机安安静静，什么提示都没有。问题往往不在监控本身，而卡在最后一百米——告警怎么送出去。这套 Zabbix 邮件发送设置，就是专门解决这最后一百米的。它属于 Zabbix 系列实操里比较基础但又特别容易翻车的一环，搞过一遍之后你会发现，真正花时间的不是敲命令，而是把邮箱服务端、服务器网络、Zabbix 权限、告警动作这四段链路一段段对齐。下面的内容适合三类人看：刚把 Zabbix 跑起来、还没配过任何通知渠道的新手；配过但总收不到邮件、想搞清楚到底哪一步断了的运维；以及想把告警做成一套能长期稳定跑下去、不想天天救火的老手。全程按我自己的实操顺序讲，中间踩过的坑会单独拎出来说。

1. 先搞清楚 Zabbix 告警这条链路上到底有几个环节

1.1 一封告警邮件从触发到进你收件箱要经过谁

很多人配邮件失败，不是因为某一步做错了，而是脑子里根本没有这条链路的完整图景，出问题就到处乱试。Zabbix 的告警其实是一条单向流水线，顺序大概是：监控项采集到数据 → 触发器表达式判定为 Problem → 事件产生 → 动作（Action）匹配条件后决定要不要发 → 动作的操作（Operation）指定发给谁、用什么渠道 → 用户媒介（Media）里配置的收件地址 → 媒体类型（Media type）决定用哪种方式发出去 → Zabbix Server 调用对应通道 → 邮件到达收件箱。

这条链上任何一环没接上，结果都是"没有邮件"，但原因天差地别。触发器和动作没匹配，是逻辑问题；用户没绑媒介，是配置漏项；媒体类型配错，是通道问题；服务器出不了外网或者被对端拒收，是网络和认证问题。我见过太多人一收不到邮件就去翻脚本代码，其实问题可能压根就在"这个用户没勾选媒介"这么简单的地方。

所以第一件事，建议你在纸上或者脑子里把这条链画出来，后面排查时按顺序一段段查，比盲目试错快得多。

1.2 为什么要用"用户媒介"而不是直接在动作里写邮箱

Zabbix 这套设计有个很实用的分层：动作只管"什么条件下发给哪个用户组/用户"，具体这个用户用什么邮箱、什么手机号，统一放在用户档案的媒介里。好处是当某个同事换邮箱时，你只需要改他个人的媒介配置，不用去动已经写了十几条规则的动作。这就是典型的"关注点分离"，配置量大的时候能省下大量返工。

理解这一点还有个副作用：你会知道同一个用户完全可以绑多个媒介，邮箱、脚本通道、其他通知方式可以并存，动作里勾选哪几个就发哪几个。后面讲抑制告警风暴的时候，这个特性会派上大用场。

1.3 邮件通道在当下还值不值得花力气配

有人会说，现在都流行往群里推告警了，邮件是不是过时了。我的看法是，即时消息适合"立刻要有人响应"的场景，而邮件适合"留下完整记录、便于事后追溯、附件和长文本友好"的场景。两者不是替代关系。尤其是巡检报告、每日汇总、需要附上图表快照的告警，邮件依然是最省事的载体。而且邮件通道不依赖任何第三方机器人接口的稳定性，链路更短，出问题时排查面更窄。所以把邮件配好，是打底的一件事，不是可有可无。

2. 两条主流技术路线怎么选，别一上来就纠结

2.1 路线一：内置 Email 媒体类型直接走 SMTP

Zabbix 自带一个 Email 类型的媒体类型，本质上是 Zabbix Server 进程自己作为 SMTP 客户端去连接邮件服务器发信，不需要你写任何脚本。它的配置项很直观：SMTP 服务器地址、端口、发件人地址、认证方式、用户名密码、加密方式（SSL/TLS/STARTTLS）。

这条路线的优点非常明显：零代码、配置即用、出问题日志直接写在 server 日志里。缺点也很实在：认证方式和加密选项在不同版本的界面上略有差异，遇到一些对认证要求比较特殊的邮箱服务商时，可调参数不够灵活，比如想自定义邮件头、想加附件、想用代理中转（这里指的是企业内部 SMTP 中转服务，不是别的意思），就比较受限。

如果你只是想让告警能发出去，收件箱能看到，那这条路足够，别折腾。

2.2 路线二：脚本媒体类型调用外部程序发信

脚本路线是 Zabbix 把收件人、标题、正文三个参数传给一个可执行脚本，脚本自己负责把邮件发出去。脚本可以是你用 Python、Shell、Perl 写的任何东西，内部用标准库或者外部命令行工具（msmtp、sendmail 之类）发信都行。

这条路线的价值在于完全可控：邮件头随便写、正文想拼 HTML 就拼 HTML、想同时写本地日志就写日志、想失败重试就加重试。代价是你得自己维护这段代码，脚本有 bug、权限不对、依赖缺失，都会变成告警失败的源头。我个人的习惯是，只要不是极端简单的场景，都用脚本路线，因为一旦要定制内容格式，内置类型很快就顶不住了。

下面这张表可以帮你快速决断：

2.3 我为什么最终选了脚本路线

说个真实理由：内置类型发出去的邮件，正文排版在部分客户端里会挤成一坨，而我又特别在意邮件里能不能一眼看清主机名、触发器名、当前值和发生时间。脚本路线可以自己控制正文结构，甚至做两栏纯文本对齐，阅读体验完全不同。另外脚本能把每次发送的结果写到独立日志文件，出问题时不用去几万行的 server 日志里翻，直接 tail 自己的日志就行。这点在告警量大以后特别省事。

需要提醒的是，两条路线不冲突，你可以都配上。比如内置类型做粗粒度通知，脚本类型做重点主机的详细告警，动作里分别选择即可。

3. 动手之前，这些前置环节必须先打通

3.1 邮箱那一侧的准备比 Zabbix 这侧更容易出错

这是我最想强调的一点。现在绝大多数邮箱服务商都不允许用登录密码去做第三方 SMTP 认证，必须开一个专门的授权码。这个码通常要在邮箱网页版的设置里，找到类似"客户端授权""安全设置"的入口，开启服务后生成一串一次性显示的口令。这个口令只显示一次，务必当场复制下来存好，关掉页面就只能重新生成。

另一个高频坑是发件人地址必须和认证账号一致。有些服务商会校验 From 头，如果你的脚本里写了一个别名或者分配组地址，而认证用的是另一个账号，就会被拒。稳妥的做法是：认证账号和 From 地址完全一致，需要展示友好名称，就改显示名而不是改地址。

还有一点容易被忽略：先别急着接 Zabbix，先用一个最简单的命令行工具手动测试一次 SMTP 连通和认证。这一步过了，后面 Zabbix 的配置就只是"把已经跑通的东西搬进去"，难度骤降。这个测试方法我在后面第 4 章会具体写。

3.2 Zabbix Server 侧的网络和 DNS 自检

告警发不出去，很大比例是服务器根本连不上邮件服务商的 SMTP 地址。先确认三件事：DNS 能不能解析出目标域名、目标端口通不通、有没有被本机防火墙拦。可以用简单的命令验证：

# 解析域名 getent hosts smtp.example.com # 测试 465 端口连通性（TLS 加密常用端口） timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/465' && echo "port 465 ok" || echo "port 465 blocked" # 测试 587 端口（STARTTLS 常用端口） timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587' && echo "port 587 ok" || echo "port 587 blocked"

注意：不少云主机和机房默认会限制出方向的 25 端口，这是服务商的反滥用策略，不是你配置错了。遇到 25 端口不通，直接换 465 或 587，不要在这上面浪费时间。

如果上面两条命令都返回 ok，说明网络层没问题，可以往下走了。如果解析失败，检查/etc/resolv.conf里的 DNS 配置；如果端口不通，先确认是不是机房策略，再确认本机 iptables 或 firewalld 有没有出向规则。

3.3 脚本运行身份和目录权限，这是最隐蔽的坑

Zabbix Server 执行告警脚本时，用的是运行 Zabbix Server 进程的那个系统账号，通常是zabbix用户，不是你登录用的 root，也不是前端里你登录的那个用户名。这一点如果不清楚，会掉进一个很典型的坑：你手动用 root 跑脚本一切正常，Zabbix 一调就失败，因为 zabbix 用户没有目录写权限、没有读取配置的权限，或者脚本文件本身没有可执行位。

脚本要放在 Zabbix Server 配置里指定的告警脚本目录，这个目录由zabbix_server.conf里的AlertScriptsPath参数决定，默认常见路径是/usr/lib/zabbix/alertscripts。你可以这样确认和设置权限：

# 查看当前配置的脚本目录 grep -i AlertScriptsPath /etc/zabbix/zabbix_server.conf # 假设目录是 /usr/lib/zabbix/alertscripts ls -ld /usr/lib/zabbix/alertscripts # 脚本必须可执行，且属主能让 zabbix 用户读取 chown root:zabbix /usr/lib/zabbix/alertscripts/sendmail.py chmod 750 /usr/lib/zabbix/alertscripts/sendmail.py

提示：如果你在脚本里要写日志文件，日志目录的属主也要给到 zabbix 用户，否则会出现"邮件发出去了但日志写不进去"这种次生问题，排查时容易误判。

4. 脚本路线完整实操：从写脚本到收到第一封告警

4.1 目录规划和文件命名

先把东西归置好，后面维护省心。我在/usr/lib/zabbix/alertscripts下建脚本本体，在/var/log/zabbix下建一个独立的告警日志，配置和凭据则从脚本里抽出来放在同目录的一个配置文件中，便于改密码时不碰代码：

• 脚本本体：/usr/lib/zabbix/alertscripts/zbx_mail.py
• 凭据配置：/usr/lib/zabbix/alertscripts/zbx_mail.conf
• 运行日志：/var/log/zabbix/zbx_mail.log

凭据文件和代码分离这一点，是我被"改了密码忘了改脚本、结果告警静默三天"教育之后的习惯。配置文件权限设成 640，属主 root、属组 zabbix，既不让其他人看到密码，又能让 zabbix 用户读到。

4.2 完整脚本代码和逐行说明

下面这段是我现在实际在用、也推荐给同事的版本，用 Python 标准库实现，不依赖任何第三方包，部署到新机器上只要 Python 3 在就能跑。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- import os import sys import ssl import smtplib import logging from email.mime.text import MIMEText from email.header import Header from email.utils import formataddr CONF_PATH = '/usr/lib/zabbix/alertscripts/zbx_mail.conf' LOG_PATH = '/var/log/zabbix/zbx_mail.log' def load_conf(path): conf = {} with open(path, 'r', encoding='utf-8') as f: for line in f: line = line.strip() if not line or line.startswith('#'): continue k, _, v = line.partition('=') conf[k.strip()] = v.strip() return conf def setup_logger(): logger = logging.getLogger('zbx_mail') logger.setLevel(logging.INFO) handler = logging.FileHandler(LOG_PATH, encoding='utf-8') handler.setFormatter(logging.Formatter('%(asctime)s %(levelname)s %(message)s')) logger.addHandler(handler) return logger def build_message(conf, to_addr, subject, body): msg = MIMEText(body, 'plain', 'utf-8') msg['From'] = formataddr((str(Header(conf.get('from_name', 'Zabbix Alert'), 'utf-8')), conf['mail_from'])) msg['To'] = to_addr msg['Subject'] = Header(subject, 'utf-8') return msg def send(conf, msg, to_addr): port = int(conf.get('smtp_port', 465)) timeout = int(conf.get('smtp_timeout', 15)) if port == 465: server = smtplib.SMTP_SSL(conf['smtp_host'], port, timeout=timeout, context=ssl.create_default_context()) else: server = smtplib.SMTP(conf['smtp_host'], port, timeout=timeout) server.ehlo() server.starttls(context=ssl.create_default_context()) server.ehlo() server.login(conf['smtp_user'], conf['smtp_pass']) server.sendmail(conf['mail_from'], [to_addr], msg.as_string()) server.quit() def main(): logger = setup_logger() if len(sys.argv) < 4: logger.error('arguments missing: need <to> <subject> <message>') sys.exit(1) to_addr, subject, body = sys.argv[1], sys.argv[2], sys.argv[3] try: conf = load_conf(CONF_PATH) msg = build_message(conf, to_addr, subject, body) send(conf, msg, to_addr) logger.info('sent to=%s subject=%s', to_addr, subject) print('OK') except Exception as e: logger.error('send failed to=%s error=%s', to_addr, repr(e)) print('ERROR: %s' % e) sys.exit(1) if __name__ == '__main__': main()

几个关键点单独说一下。第一，脚本必须接收三个位置参数，顺序是收件人、主题、正文，这是 Zabbix 脚本媒体类型传参的固定约定，少一个都不行。第二，端口是 465 时用SMTP_SSL直接上 TLS，是 587 时先明文连接再starttls，这两种握手方式不能混，弄反了会卡住直到超时。第三，所有异常都写进独立日志并且以非零状态码退出，这样 Zabbix 前端能看到失败，便于发现"静默失败"。第四，脚本最后打印的OK或ERROR会进入 Zabbix 的告警历史，排查时在前端就能看到脚本的原始输出。

对应的配置文件长这样：

smtp_host=smtp.example.com smtp_port=465 smtp_user=alert@example.com smtp_pass=这里填邮箱生成的授权码 mail_from=alert@example.com from_name=Zabbix Alert smtp_timeout=15

4.3 手动验证脚本，别跳过这一步

写完之后，一定先用 zabbix 用户的身份手动跑一次，这一步能提前暴露 90% 的权限和环境问题：

sudo -u zabbix /usr/lib/zabbix/alertscripts/zbx_mail.py your_name@example.com "test subject" "test body from cli"

如果收件箱收到了，说明脚本、凭据、网络、认证全都通了，剩下的只是把它接进 Zabbix。如果报错，错误信息会同时打到标准输出和/var/log/zabbix/zbx_mail.log，照着错误往下查就行。常见的几类和对应原因我在第 6 章整理成表了。

注意：用sudo -u zabbix验证，不要用 root。用 root 验证通过不代表 Zabbix 能跑通，因为权限主体不同，这个差异是最容易被误判的地方。

4.4 在媒体类型里把脚本接上

进入前端，路径是"管理 → 媒体类型 → 创建媒体类型"，类型选 Script（脚本），名称自己起一个能看懂的名字，比如"邮件告警-脚本版"。脚本名称填文件名zbx_mail.py，不需要填完整路径，因为 Zabbix 会在AlertScriptsPath目录下找它。脚本参数按顺序填三个，用宏占位：

{ALERT.SENDTO} {ALERT.SUBJECT} {ALERT.MESSAGE}

这三个宏的含义分别是收件人地址、主题、正文，它们的值最终来自用户媒介和告警消息模板。填完之后，建议先别急着配用户，界面里一般有个测试按钮，输入一个收件地址和一段正文，点测试，直接看结果。测试的好处是不用真造一个故障就知道通道通不通。

4.5 绑定用户媒介并串起告警动作

脚本通道本身只是一个"能力"，要真正发出去还得把它挂到人身上。进入"管理 → 用户"，选一个用户，在"媒介"标签页里新增一条：类型选刚才建的那个脚本媒体类型，收件人填这个人的邮箱，启用状态设为已启用，严重性等级按需要勾选（决定哪些级别的告警会发给他）。如果你希望不同严重级别走不同渠道，可以在这里多绑几条，比如一般故障只走邮件，严重故障同时走即时消息通道。

然后是动作。进入"配置 → 动作 → 触发器动作"，创建一个动作或者沿用默认的Report problems to Zabbix administrators。动作里有几个地方要确认：条件（Conditions）决定哪些触发器事件会进来；操作（Operations）里要指定发送给哪个用户或者用户组，并且在"仅送到"里勾选那个脚本媒体类型。很多人的邮件发不出来，就是操作里勾了用户，但没勾具体媒介类型，Zabbix 不知道要用哪条通道发。这个细节后面第 6 章还会再提。

4.6 造一个真实告警，验证整条链路

配置全齐之后，别等真出事才验证。我最常用的方法是把某个测试主机的文件系统触发器临时改成一个一定能触发的表达式，比如把磁盘空间告警阈值改到 101%，或者直接在一个空目录上挂一个会触发的表达式。等事件产生、状态变成 Problem 之后，去"报表 → 动作日志"里看记录，那里会明确写出这次动作有没有执行、发给谁、发送结果是什么。

如果动作日志显示已发送但收件箱没有，去翻脚本自己的日志；如果日志显示发了但也收到了，说明链路完全通了，赶紧把测试阈值改回去。这个"造一次假故障"的习惯非常划算，它把"出事时才发现收不到告警"的风险提前消化掉了。

5. 内置 Email 媒体类型的极简配置法

5.1 参数怎么填不容易翻车

如果你不想写脚本，内置 Email 类型也能用。创建媒体类型时类型选 Email，几个关键项这样填：SMTP 服务器填域名或 IP；SMTP 服务器端口填 465 或 587（避开 25）；SMTP HELO 填一个正常的域名，有些服务商会校验；SMTP 电子邮件填发件地址，通常要求跟登录账号一致；认证方式选用户名和密码，用户名填完整邮箱，密码填授权码；安全连接选 SSL/TLS 还是 STARTTLS，要和端口对应，465 配 SSL/TLS，587 配 STARTTLS。

这里最容易栽的是加密方式和端口的搭配。465 配上 STARTTLS，或者 587 配上直接 SSL，握手会一路卡到超时，日志里看到的就是连接超时，很容易误判成网络不通。记住一个对应关系就不会错：465 是"一上来就加密"，587 是"先说 hello 再加密"。

5.2 日志里最常见的几种返回

内置类型的发送结果只写在 Zabbix Server 日志里，所以看日志是唯一的排查手段。几种典型情况：出现连接超时，优先怀疑端口被限制或加密方式配错；出现认证失败，优先确认用的是授权码而不是登录密码，以及用户名是否要填完整邮箱；出现发件人被拒，优先检查 From 地址是否和认证账号一致。这几种情况占了内置类型失败原因的绝大多数。

如果你的邮箱服务商对认证方式有一些额外要求，比如要求特定的登录机制，内置类型可能给不出可调选项，这种时候就回到脚本路线，脚本里可以自己控制login和握手细节。这也是我前面说"长期使用建议脚本路线"的原因之一。

6. 常见故障排查速查表与我的排查顺序

6.1 三种典型现象分别对应什么

第一种现象：动作日志里压根没有记录。这说明问题在动作匹配环节，不是邮件通道的问题。检查动作条件是否满足、动作是否启用、操作里有没有勾对应的媒介类型、触发器事件是否真的产生了。

第二种现象：动作日志有记录，结果状态是失败。这说明通道被调用了但没成功。去翻脚本日志或 server 日志，看具体错误。权限、路径、凭据、网络，基本就是这几类。

第三种现象：动作日志显示发送成功，但收件人没收到。这就跑到邮件系统那一侧了，优先看对方邮箱的垃圾邮件目录，其次确认自己发出去的地址拼写没错，再确认对端有没有做入站过滤。这类问题跟 Zabbix 关系不大了。

6.2 高频报错对照表

这张表我基本是背下来的，现场排查时按现象定位原因，能省掉大量猜测时间。

6.3 我自己的固定排查顺序

我的顺序是：先看动作日志有没有记录，再看脚本独立日志或 server 日志的报错，再退到命令行用 zabbix 用户手动跑，最后才去查网络和邮箱服务商。这个顺序是从"最靠近 Zabbix 的环节"往"最远离 Zabbix 的环节"推，能最快把问题范围缩小。

有个经验值得单独说：诊断和消息模板的绑定关系容易被忽略。如果你在动作的操作里定义了自定义消息模板，而模板里的宏写错了名字（比如把{EVENT.NAME}拼成了{EVENT.NAME.}），最后发出去的邮件正文可能是空白或者残缺的。这种问题不会报错，只是内容不对，容易被当成"收到了但看不懂"。建议正文模板先在界面的测试功能里预览一遍。

7. 想让它长期稳定跑，还得补几个工程化动作

7.1 抑制告警风暴，比配通更重要的能力

通道配通只是第一步。真上线之后你会发现，一次网络抖动可能触发几百条相关告警，收件箱瞬间被冲爆，重要的告警反而被淹没。Zabbix 里做抑制有几个可靠手段：一是利用动作里的升级（Escalation）配置，把重复通知的间隔拉长，不要每条都发；二是打开"单次事件"类行为，让同一个事件在未恢复前只发一次；三是利用事件关联（Event correlation），把同一台主机的关联告警合并处理。

我的做法是给不同严重级别配不同的节奏：一般级别只在状态变化时发一次，不重复；严重级别按固定间隔升级，直到有人确认或者恢复；恢复消息统一开启，这样收件人能明确知道事情过去了。

7.2 邮件正文模板要按"扫一眼就能判断"来设计

告警邮件的正文不是越详细越好，目标是让人在手机锁屏通知那么小的空间里也能判断严重程度。我的模板通常包含这几块：主机名和所属业务、触发器名称、当前值、问题首次发生时间、事件编号、以及一句操作提示。值和时间放在最前面，因为这两个决定要不要立刻爬起来处理。

模板里可以直接用 Zabbix 的宏来填充，比如主机名、触发器名、事件时间这些都有对应宏。写完之后一定要用测试功能实际发一封看看排版，纯文本在手机客户端上的折行效果跟你电脑上看到的完全不一样。

7.3 升级和值班路由怎么安排更合理

只有一个人收告警的配置，可以在小规模环境里跑，但一旦团队超过三个人就会出问题：谁负责看、看漏了怎么补。Zabbix 的升级机制可以这样用：第一层发给当前值班的人，如果若干分钟没人确认，第二层升级给备份值班，再往上给负责人。这套东西和邮件通道是叠加关系，不是替代关系，邮件负责留痕，升级负责兜底。

需要注意的是，升级链条上每一层的用户都必须绑好媒介，否则升级到某一层时因为那个人没配邮箱就断了，整个链条形同虚设。这个坑我踩过一次，凌晨的告警升级到第二层就静默了，第二天复盘才发现那个人从没绑过媒介。

7.4 多通道组合，别把鸡蛋放一个篮子

邮件有它的固有缺点：投递延迟不可控、可能进垃圾箱、对端服务故障时你无能为力。所以认真做的环境一般都会配主备两条通道，邮件作为记录和兜底，即时消息类通道作为快速触达。两条同时发，哪条先到算哪条。动作里勾选多个媒介类型就能实现，不需要维护两套动作。

对应的运维习惯也要跟上：每周抽一条真实告警，确认两个通道都收到了；每月检查一次授权码有没有过期（有些服务商会定期失效）；每季度复核一次收件人列表，把离职和转岗的人清掉。这些事看起来琐碎，但真正决定你的告警体系是不是"能信得过"。

最后分享一个我自己的小体会。邮件告警这种基础配置，第一次做的时候我会花两三个小时反复试，做完之后一年可能都不再碰它。所以值得在一开始就把它做扎实：把凭据和代码分离、把日志单独落盘、把排查顺序固化成一张表。等哪天半夜真出事，你能在三分钟内确认"是通道挂了还是真没故障"，这套东西的价值就体现出来了。至于正文模板怎么排、升级节奏怎么定，这些没有标准答案，按你们团队的值班习惯调，调到没人抱怨为止，就算是配好了。