Zabbix 的配置流程从安装到告警一次讲透做运维最怕什么不是半夜告警而是该报警的时候没报不该报的时候刷屏。Zabbix 之所以成为监控领域的主力就是因为它的采集能力、触发器逻辑和通知体系足够成体系。但很多人第一次接触它往往卡在配置流程上装完没数据加了主机不监控触发器明明设置了却不触发。这些问题大概率不是因为 Zabbix 本身难而是因为你没把配置流程的内在逻辑捋顺。这篇内容我结合自己实际部署和维护 Zabbix 的经验把整个配置流程拆开来讲。从环境准备、数据库初始化、前端部署到添加主机、配置监控项、设置触发器和告警动作再到自定义监控和问题排查一条线走下来。适合刚上手的新人也适合已经用过但总觉得哪里不通的运维同学。看完之后你会发现Zabbix 的配置其实是一个环环相扣的过程理解了每一环为什么存在配置起来自然就顺了。1. 环境准备与安装决策1.1 先搞清楚 Zabbix 有哪些组成部分Zabbix 不是单一个程序而是一套组合。最基本的部署包含三块Zabbix Server核心服务、Zabbix Agent被监控端程序、Zabbix Web Frontend图型化界面。还有可选的 Zabbix Proxy用于分布式环境下分担 Server 压力以及 Zabbix Java Gateway 之类的扩展组件用于监控 Java 应用。理解这个架构有什么好处好处是你在配置的时候知道哪个环节出了问题该去哪看。比如 Agent 数据没上来你要先去找 Agent 和 Server 之间的网络通不通、Agent 配置文件里的 Server IP 对不对而不是一头扎进前端界面里瞎点。1.2 版本和操作系统选型版本选择我建议选 LTS 版本。Zabbix 的 LTS 版本是官方承诺长期维护的Bug 修复和安全补丁都能持续跟进。1.4 这个版本号通常指的是某个发行版的扩展包版本而不是 Zabbix 主版本号。你在生产环境部署时去官网查一下当前最新的 LTS 主版本就行比如 6.0 或 6.4 系列。操作系统方面CentOS 7、Rocky Linux、Ubuntu Server 都比较常见我的经验是优先选 RHEL 系因为 Zabbix 官方仓库对 RHEL 系的包支持最完整安装时少踩很多编译依赖的坑。数据库推荐 MySQL 或者 PostgreSQL如果监控规模不大用 MariaDB 也能撑住但别用太旧的版本字符集处理上容易出问题。1.3 安装方式包管理器优先源码编译慎用很多新手一上来就执着于源码编译觉得这样“可控”。实际上Zabbix 通过官方仓库安装整个流程轻松得多后期 yum update 或 apt upgrade 也能直接升级不用重新编译一遍依赖。装包之前先把 Zabbix 的官方仓库配好安装过程不会让你去手动装 PHP 扩展、下载依赖包。以 RHEL 系为例配好仓库后核心安装命令大概是dnf install zabbix-server-mysql zabbix-web-mysql zabbix-agent2 zabbix-get这条命令一次性装上了 Server、Web 组件和 Agent2。注意这里我特意选了 zabbix-web-mysql它会自动把 PHP 和 Apache 的依赖带进来。如果你用的是 Nginx还需要额外配置 PHP-FPM操作稍多一点但原理不变。提示装 Agent2 而不是传统 AgentAgent2 支持更多的采集协议配置上兼容度也更好。2. 数据库初始化与关键配置2.1 创建数据库和专用账号Zabbix 的数据几乎全在数据库里监控项历史数据、触发器状态、用户权限、告警记录。所以数据库这一环没做好后面全是灾难。首先为 Zabbix 创建一个独立的库和账号不要使用 root 账号连接业务服务这是最基本的安全习惯。CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbixlocalhost IDENTIFIED BY your_strong_password; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; FLUSH PRIVILEGES;字符集这里我特意写了 utf8mb4如果库的字符集不正确后面存储中文名称、告警信息时会出现乱码这种问题排查起来非常隐蔽。而 utf8mb4_bin 的排序规则则能避免一部分大小写比较的坑。2.2 导入初始化表结构Zabbix 官方提供了初始化 SQL 文件安装好 Server 包后会在 /usr/share/zabbix-sql-scripts/mysql/ 目录下文件名类似 server.sql.gz。顺序很重要先解压再导入到刚才建好的数据库里。zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix导入过程可能比较慢如果提示 ERROR 什么的常见原因是字符集设置不一致或者权限没给足。导入完成后你可以登录 MySQL 查看一下表数量正常情况下应该有几百张表如果表数量明显偏少说明导入过程有问题。2.3 server 配置文件参数说明Zabbix Server 的配置文件在 /etc/zabbix/zabbix_server.conf。你需要重点关注这几个参数DBHost数据库地址。如果数据库和 Server 装在同一台机器写 localhost如果分离部署写 IP。DBName刚才建的数据库名默认 zabbix。DBUser、DBPassword数据库账号和密码。CacheSize配置缓存大小默认是内存的 8% 左右。监控项数量增多时如果这里不够日志里会报 no space in configuration cache 类似的错误。Timeout执行外部脚本或采集时的超时时间默认 3 秒如果监控脚本执行时间较长建议调大到 10 或 30。改完后一定要验证配置语法用zabbix_server -c /etc/zabbix/zabbix_server.conf启动测试一下。很多配置文件错误正常启动时不一定立刻报错等到采集数据时才会暴露所以先静态检查一遍最好。3. 前端界面部署与初始化向导3.1 安装 Web 服务与 PHP 环境Zabbix Web 前端本质上是一套 PHP 程序需要运行在 Apache 或 Nginx 上。rpm 包安装时会自动安装 Apache 和 PHP 的依赖但有两个 PHP 扩展是需要的php-mysql或 php-mysqli、php-gd、php-bcmath、php-mbstring、php-xml。如果用的是官方仓库这些依赖一般会自动带上不需要手动装。但如果你是在已有环境上二次安装请检查 PHP 版本是否符合 Zabbix 的要求比如 Zabbix 6.0 要求 PHP 7.2 以上部分高版本甚至要求 7.4 或 8.0。版本不够的话前端初始化页面会直接给出红色错误提示或者干脆加载不了。3.2 配置虚拟主机与文件权限前端文件默认位置在 /usr/share/zabbix。Apache 的配置在 /etc/httpd/conf.d/zabbix.conf 中默认监听 80 端口。生产环境如果不希望对公网开放可以改成监听内网网卡或者加一层访问认证。文件权限经常被忽略。前端需要写入缓存你至少要让运行 Apache 的用户通常是 apache 或 www-data对 /var/lib/php/session 和 /var/lib/php/wsdlcache 有读写权限否则登录时会报“session 写入失败”之类的错误。3.3 浏览器初始化配置浏览器访问 http://你的IP/zabbix会出现安装向导页面。向导第一步检查环境依赖第二步让你填数据库信息第三步配置 Zabbix Server 的连接参数最后一步会生成配置写入文件 /etc/zabbix/web/zabbix.conf.php。一个常见坑向导里填写的数据库密码和实际 MySQL 密码不一致或者数据库地址不对都会报“连接数据库失败”。还有个小细节向导里的“Port”是指 MySQL 端口默认 3306别填成 Zabbix Server 的端口了。初始化完成后会自动跳到登录页默认账号为 Admin默认密码 zabbix。登录后第一件事就是改密码一般生产环境严禁用默认密码是共识但这个操作很多人会拖等到被扫了才后悔。4. 添加主机与让监控跑起来4.1 添加主机的基本操作登录前端界面后依次进入 数据收集 → 主机 → 创建主机。你需要在主机配置里填三个核心字段主机名称需要能识别建议用 IP-主机名 格式、可见名称用于展示、Agent 的 IP 地址和端口。端口默认 10050对应 Zabbix Agent 的监听端口。如果你用 Agent2默认端口仍然是 10050这里保持默认即可。加入群组这一步很重要你不加入任何群组权限和后续的管理都会受限建议从一开始就规划好主机群组结构比如按业务线分Web集群、数据库集群、缓存集群。4.2 模板的选择与绑定模板是我个人认为 Zabbix 里最值得花时间理解的功能。模板本质上是一组预设的监控项、触发器、图形和告警规则的集合绑定了模板等于一键给你主机配好了一整套监控方案。添加主机时选择“模板”标签页点击选择按钮从模板列表里选一个合适的。比如监控 Linux 服务器搜索 “Linux” 关键词会找到 “Linux by Zabbix agent” 模板选中并添加。监控 MySQL 数据库用 “MySQL by Zabbix agent”。一个主机可以绑定多个模板比如一个 Web 服务器的数据库节点可以同时绑定 “Linux by Zabbix agent” 和 “MySQL by Zabbix agent”。模板之间是叠加的不会冲突。4.3 监控项的键值与间隔绑定模板后监控项会自动生成你能在“主机 → 监控项”里看到它们。每一个监控项都有一个键值例如system.cpu.util[,user]表示采集用户态 CPU 使用率net.if.in[eth0]表示采集 eth0 网卡入流量。理解键值语法极其重要因为你总有一天要自己写监控项。基本规则是键名 方括号参数参数用逗号分隔如果没有参数就留空。例如system.cpu.load[all,avg1]意思是从所有 CPU 上取 load average 1 分钟的值。具体的键值清单可以在监控项配置页面点击键值旁边的问号图标查看自带说明。监控项的更新间隔Update interval默认一般是 1 分钟短一点可以更敏感地发现问题但会增加数据库压力长一点比如 5 分钟适合一些变化缓慢的指标比如磁盘已用空间我通常设置 10 分钟或更长。灵活调整而不是机械地全用默认值这是配置流程中体现经验的地方。4.4 检查数据是否采集成功添加完主机和监控项之后如果一切正常少则几秒多则一两分钟监控项就会开始有数据。怎么判断有没有数据最简单的办法是看“最新数据”页面选中这台主机如果显示有数据条目说明采集链路已经通了。如果一直没数据按顺序排查。第一Agent 是否安装并运行可以在被监控机上执行systemctl status zabbix-agent2。第二网络是否通在 Zabbix Server 上用zabbix_get -s 被监控IP -p 10050 -k system.uptime测试一下能不能取到值。第三查看前端监控项右上角的红色报错图标点开能看到具体的错误信息比如 Timeout while executing a shell script。5. 触发器配置与告警通知5.1 触发器的意义与表达式监控项采集来的数据只是数字只有通过触发器判断才变成告警。触发器的本质是一个逻辑表达式当条件为真时触发某个状态比如 PROBLEM当恢复时状态变为 OK。先看一个简单例子。假设你要监控服务器磁盘根分区使用率当使用率超过 90% 时告警。在模板或主机里新建一个触发器表达式写成last(/Linux by Zabbix agent/vfs.fs.size[/,pused])90这个表达式拆开来看last()函数取最新一个数值/Linux by Zabbix agent/是模板或主机的路径vfs.fs.size[/,pused]是监控项键值表示根分区已用百分比。最后90是条件。触发器的另一个核心函数是nodata()例如nodata(agent.ping,5m)1表示如果 agent.ping 这个键值 5 分钟没有数据就触发“主机不在线”告警。这个比单纯判断数值常见得多也是写触发器必备的套路。5.2 触发器严重程度分级Zabbix 把触发器严重程度分为五级未分类、信息、警告、一般严重、严重。建议不要滥用高等级否则告警多了真正出大事时反而没人重视。我的习惯是资源使用率超阈值用“警告”服务宕机或数据丢失用“严重”处于两者之间的用“一般严重”。分级的意义不只是好看它会直接驱动告警媒介的行为。比如你可以设置警告级只发邮件严重级同时发邮件加短信并且重复发送间隔缩短。5.3 配置告警媒介与动作告警媒介是通知渠道动作是告警发生时执行的行为。两者配合才能把告警送出去。先添加媒介。路径用户 → 用户 → 点击 Admin → 告警媒介。这里可以添加邮箱、短信网关或 Webhook。添加邮箱时你需要配置 SMTP 服务器地址、端口、认证账号和密码并设置收件人地址。Zabbix 不会自己去发现发件人所有信息都需要手动填。配置动作的路径是告警 → 动作 → 创建动作。动作的触发需要满足条件比如“触发器严重程度 ≥ 警告”以及“主机群组包含 XX”。条件满足后定义动作操作发送消息给某个用户或用户群组消息内容可以使用宏变量比如{HOST.NAME}表示主机名{ITEM.NAME}表示监控项名称{TRIGGER.NAME}表示触发器名称{TRIGGER.SEVERITY}表示严重等级。{ITEM.LASTVALUE}是很有用的宏表示监控项最后一个数值比如磁盘使用率当前的值是多少用户收到告警邮件时就能直接看到关键数据而不需要再去前端查。建议在消息内容里明确写明触发器的详细信息最好的告警消息是“哪台机器的哪个指标当前值是多少超过或低于阈值多少”。动作里还可以设置“恢复操作”和“更新操作”。恢复操作的意思是当问题解决时发送一条“OK”消息这能让值班人员确认问题已经闭环而不是石沉大海。更新操作则是问题持续存在时每隔一段时间再次发送通知防止告警被遗漏。5.4 告警升级机制大型环境里告警升级是必须的。比如一条“数据库服务不可用”的严重告警如果 10 分钟没有被处理就升级给运维主管30 分钟还没处理就升级给技术总监。Zabbix 的动作里可以设置多个“操作步骤”每一步可以设置不同的发送对象和消息内容加上“开始时间”和“持续时长”就能实现升级。这一步很多教程不会细讲但踩过坑的人都知道没有升级机制告警发到一个人邮箱里人不在位问题就没人管了。合理配置严重告警的重复发送和升级比单纯把严重级别调高更有用。6. 模板、自定义监控与宏变量6.1 模板的复制与修改模板自带的监控项设置有时候不符合你的实际需求比如默认的触发器阈值太低或者某个监控项你根本不需要。直接修改官方模板会带来一个问题以后升级官方模板时你的修改被覆盖或冲突。所以正确做法是复制模板。在模板列表里选择你要修改的模板点击“全克隆”克隆出一个新模板比如“Linux by Zabbix agent - Custom”然后在新模板里随意修改。修改完成后绑定到这个新模板的主机也会自动切换到新配置。6.2 自定义监控项的实现Zabbix 不可能覆盖所有监控场景比如你有一个自研程序需要暴露一个特定文件里的某个数值。这时候你就需要自定义监控项。有两种方式第一种利用 Zabbix Agent 的 UserParameter。编辑 Agent 配置文件 /etc/zabbix/zabbix_agent2.conf增加UserParametermyapp.requests,/usr/local/bin/count_requests.sh然后在前端监控项里新建监控项键值写myapp.requests更新间隔按需设置。脚本count_requests.sh每次执行后会输出一个数字这个数字就被当作监控值存入 Zabbix。注意脚本要保证执行时间短建议控制在 3 秒内否则容易超时另外脚本输出不要有多余的文本或换行Zabbix 取的是第一行整数值。第二种通过 Zabbix Agent 的不可用采集项perf_counter或模块来实现。这种更底层对新手来说用前者就够了。自定义监控项最容易犯的错误是路径问题。脚本路径写错会导致no such file or directory错误或者脚本没有执行权限。建议先在 Agent 所在的机器上手动执行一遍确认能输出预期值后再配置到前端。6.3 宏变量的使用技巧Zabbix 里的宏变量是一大“隐藏武器”学会用宏能大幅减少配置里的重复劳动。全局宏在“管理 → 通用 → 宏”里定义比如定义一个{$PASSWORD}宏作为数据库密码这样在多个主机上需要用到密码时直接引用宏而不需要在每个主机配置里明文写密码。模板级宏更好用。比如监控所有 Web 服务器的 URL 响应时间不同服务器监控的 URL 可能不同但模板结构相同。这时你可以在模板里定义一个宏{$URL_PATH : /health}然后在监控项键值里用web.page.get[{$URL_PATH}]。这样每次有新服务器加入你只需要在新的主机配置里覆盖{$URL_PATH}这个宏的值而不用修改模板或手动改监控项。宏变量还有自动发现Low-Level Discovery的配合使用。比如自动发现主机上的所有网卡、磁盘或文件系统然后根据宏值自动创建对应的监控项。配置了自动发现规则后新加的磁盘或网卡会被自动纳入监控省去人工维护列表的烦恼。7. 常见问题汇总与性能优化7.1 常见报错与解决办法配置过程中我碰到过比较高频的错误整理成下面这份速查表现象大概率原因处理办法最新数据里监控项一直没值Agent 未安装、网络不通、键值错误用 zabbix_get 测试键值检查防火墙端口 10050 是否开放Web 界面登录后白屏或报 PHP 错误PHP 缺少必要的扩展或版本过低安装 php-bcmath、php-mbstring、php-xml 等扩展检查 PHP 版本符合要求触发器告警收不到邮件媒介配置错误、动作没有绑定用户、SMTP 被云服务商封先检查“报告 → 动作日志”看动作是否执行邮件发送失败通常在动作日志里有具体报错数据库写入性能下降历史数据保留时间过长、监控项过多调整“历史数据保留时间”和“趋势数据保留时间”考虑对数据库进行分区无法创建主机提示权限不足用户群组没有权限在“用户群组”中给对应的群组添加权限否则只能查看不能编辑主机显示红色不可达Zabbix Server 无法连接 Agent检查 Agent 是否正在运行检查 Agent 配置文件里的 Server 列表是否包含 Zabbix Server 的 IP7.2 性能优化建议Zabbix 部署规模变大之后性能会慢慢成为瓶颈。有几点我实际用过之后觉得效果很明显一是历史数据与趋势数据保留时间要分开设置。历史数据原始数据可以只保留 14 天趋势数据小时级聚合可以保留 365 天甚至更久。历史数据保留过长数据库读写压力成倍增加而趋势数据已经能表达变化趋势。二是监控项的收集间隔不要无脑用默认 1 分钟。对于状态类指标比如进程存活、端口存活可以提高到 2 或 5 分钟只有性能类指标如 CPU、内存、IO 才考虑短间隔。同一个主机绑定了多个模板可能产生几百个监控项如果全是一分钟间隔后端负担非常大。三是用 Zabbix Proxy 做分流。如果监控节点分布在不同网络区域比如总部机房和分支机构与其统一连中心 Server不如在分支机构部署一台 Proxy。Agent 被分支机构的 Proxy 采集Proxy 再与中心 Server 通信。这样既降低跨网络带宽占用也让中心 Server 的负担小很多。注意Proxy 本身也需要配置数据库与 Server 的通信端口是 10051而不是 10050别搞混了。7.3 安全与日常维护很多生产 Zabbix 服务器被入侵问题往往出在默认密码和弱口令上。装完 Zabbix 后请立即修改 Admin 密码并且关闭前端页面的匿名访问部分。前端的安装引导可以删除或锁定相关文件防止被二次利用。Agent 配置也值得注意。Agent 监听接口不要暴露到公网尽量绑定内网地址。Zabbix Agent 的 Server 配置项里只允许列表中的 Zabbix Server 拉取数据这能防止别人乱建监控项或者干扰采集。日常维护里备份是最容易忽略的。数据库承担了大量配置和监控数据建议至少每天备份一次 Zabbix 数据库备份文件单独存放。容灾恢复时只要数据库恢复加上原来的配置文件整个 Zabbix 系统就能快速复原。另外监控告警的维护期也不是小事。正常的业务发布、停机维护期间如果不设置“维护期间”告警会疯狂爆发值班人员被轰炸到怀疑人生。你可以在“告警 → 维护”里创建维护窗口选择时间段和执行周期Zabbix 不会在维护期间内触发告警动作。这功能非常实用我每一次上线变更前都会主动设置不然半夜一次重启能发出几百条告警邮件。一些说明Zabbix 的配置流程走一遍之后你会发现它其实是一个很线性的过程准备环境 → 初始化数据库 → 部署前端 → 添加主机 → 配好监控项 → 写好触发器 → 配置告警动作。每一步都不难但每一步都会决定后面能否顺利跑起来。我个人在实际操作中的体会是配置流程里最值得花时间打磨的不是某一台主机的添加而是主机分组和模板管理的规划。前期分类分得清楚后期新加主机、调整阈值、排查问题都会非常顺手。如果你是一个 Zabbix 新人先从头到尾配通一条链路再用模板批量添加几十台机器你就能感受到这套配置流程真正的威力在哪里。 
长河君 · 2026/10/15 15:20:19 · 阅读 1.2k Zabbix 配置流程详解：从环境安装到告警通知一次搞定
Zabbix 的配置流程从安装到告警一次讲透做运维最怕什么不是半夜告警而是该报警的时候没报不该报的时候刷屏。Zabbix 之所以成为监控领域的主力就是因为它的采集能力、触发器逻辑和通知体系足够成体系。但很多人第一次接触它往往卡在配置流程上装完没数据加了主机不监控触发器明明设置了却不触发。这些问题大概率不是因为 Zabbix 本身难而是因为你没把配置流程的内在逻辑捋顺。这篇内容我结合自己实际部署和维护 Zabbix 的经验把整个配置流程拆开来讲。从环境准备、数据库初始化、前端部署到添加主机、配置监控项、设置触发器和告警动作再到自定义监控和问题排查一条线走下来。适合刚上手的新人也适合已经用过但总觉得哪里不通的运维同学。看完之后你会发现Zabbix 的配置其实是一个环环相扣的过程理解了每一环为什么存在配置起来自然就顺了。1. 环境准备与安装决策1.1 先搞清楚 Zabbix 有哪些组成部分Zabbix 不是单一个程序而是一套组合。最基本的部署包含三块Zabbix Server核心服务、Zabbix Agent被监控端程序、Zabbix Web Frontend图型化界面。还有可选的 Zabbix Proxy用于分布式环境下分担 Server 压力以及 Zabbix Java Gateway 之类的扩展组件用于监控 Java 应用。理解这个架构有什么好处好处是你在配置的时候知道哪个环节出了问题该去哪看。比如 Agent 数据没上来你要先去找 Agent 和 Server 之间的网络通不通、Agent 配置文件里的 Server IP 对不对而不是一头扎进前端界面里瞎点。1.2 版本和操作系统选型版本选择我建议选 LTS 版本。Zabbix 的 LTS 版本是官方承诺长期维护的Bug 修复和安全补丁都能持续跟进。1.4 这个版本号通常指的是某个发行版的扩展包版本而不是 Zabbix 主版本号。你在生产环境部署时去官网查一下当前最新的 LTS 主版本就行比如 6.0 或 6.4 系列。操作系统方面CentOS 7、Rocky Linux、Ubuntu Server 都比较常见我的经验是优先选 RHEL 系因为 Zabbix 官方仓库对 RHEL 系的包支持最完整安装时少踩很多编译依赖的坑。数据库推荐 MySQL 或者 PostgreSQL如果监控规模不大用 MariaDB 也能撑住但别用太旧的版本字符集处理上容易出问题。1.3 安装方式包管理器优先源码编译慎用很多新手一上来就执着于源码编译觉得这样“可控”。实际上Zabbix 通过官方仓库安装整个流程轻松得多后期 yum update 或 apt upgrade 也能直接升级不用重新编译一遍依赖。装包之前先把 Zabbix 的官方仓库配好安装过程不会让你去手动装 PHP 扩展、下载依赖包。以 RHEL 系为例配好仓库后核心安装命令大概是dnf install zabbix-server-mysql zabbix-web-mysql zabbix-agent2 zabbix-get这条命令一次性装上了 Server、Web 组件和 Agent2。注意这里我特意选了 zabbix-web-mysql它会自动把 PHP 和 Apache 的依赖带进来。如果你用的是 Nginx还需要额外配置 PHP-FPM操作稍多一点但原理不变。提示装 Agent2 而不是传统 AgentAgent2 支持更多的采集协议配置上兼容度也更好。2. 数据库初始化与关键配置2.1 创建数据库和专用账号Zabbix 的数据几乎全在数据库里监控项历史数据、触发器状态、用户权限、告警记录。所以数据库这一环没做好后面全是灾难。首先为 Zabbix 创建一个独立的库和账号不要使用 root 账号连接业务服务这是最基本的安全习惯。CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbixlocalhost IDENTIFIED BY your_strong_password; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; FLUSH PRIVILEGES;字符集这里我特意写了 utf8mb4如果库的字符集不正确后面存储中文名称、告警信息时会出现乱码这种问题排查起来非常隐蔽。而 utf8mb4_bin 的排序规则则能避免一部分大小写比较的坑。2.2 导入初始化表结构Zabbix 官方提供了初始化 SQL 文件安装好 Server 包后会在 /usr/share/zabbix-sql-scripts/mysql/ 目录下文件名类似 server.sql.gz。顺序很重要先解压再导入到刚才建好的数据库里。zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix导入过程可能比较慢如果提示 ERROR 什么的常见原因是字符集设置不一致或者权限没给足。导入完成后你可以登录 MySQL 查看一下表数量正常情况下应该有几百张表如果表数量明显偏少说明导入过程有问题。2.3 server 配置文件参数说明Zabbix Server 的配置文件在 /etc/zabbix/zabbix_server.conf。你需要重点关注这几个参数DBHost数据库地址。如果数据库和 Server 装在同一台机器写 localhost如果分离部署写 IP。DBName刚才建的数据库名默认 zabbix。DBUser、DBPassword数据库账号和密码。CacheSize配置缓存大小默认是内存的 8% 左右。监控项数量增多时如果这里不够日志里会报 no space in configuration cache 类似的错误。Timeout执行外部脚本或采集时的超时时间默认 3 秒如果监控脚本执行时间较长建议调大到 10 或 30。改完后一定要验证配置语法用zabbix_server -c /etc/zabbix/zabbix_server.conf启动测试一下。很多配置文件错误正常启动时不一定立刻报错等到采集数据时才会暴露所以先静态检查一遍最好。3. 前端界面部署与初始化向导3.1 安装 Web 服务与 PHP 环境Zabbix Web 前端本质上是一套 PHP 程序需要运行在 Apache 或 Nginx 上。rpm 包安装时会自动安装 Apache 和 PHP 的依赖但有两个 PHP 扩展是需要的php-mysql或 php-mysqli、php-gd、php-bcmath、php-mbstring、php-xml。如果用的是官方仓库这些依赖一般会自动带上不需要手动装。但如果你是在已有环境上二次安装请检查 PHP 版本是否符合 Zabbix 的要求比如 Zabbix 6.0 要求 PHP 7.2 以上部分高版本甚至要求 7.4 或 8.0。版本不够的话前端初始化页面会直接给出红色错误提示或者干脆加载不了。3.2 配置虚拟主机与文件权限前端文件默认位置在 /usr/share/zabbix。Apache 的配置在 /etc/httpd/conf.d/zabbix.conf 中默认监听 80 端口。生产环境如果不希望对公网开放可以改成监听内网网卡或者加一层访问认证。文件权限经常被忽略。前端需要写入缓存你至少要让运行 Apache 的用户通常是 apache 或 www-data对 /var/lib/php/session 和 /var/lib/php/wsdlcache 有读写权限否则登录时会报“session 写入失败”之类的错误。3.3 浏览器初始化配置浏览器访问 http://你的IP/zabbix会出现安装向导页面。向导第一步检查环境依赖第二步让你填数据库信息第三步配置 Zabbix Server 的连接参数最后一步会生成配置写入文件 /etc/zabbix/web/zabbix.conf.php。一个常见坑向导里填写的数据库密码和实际 MySQL 密码不一致或者数据库地址不对都会报“连接数据库失败”。还有个小细节向导里的“Port”是指 MySQL 端口默认 3306别填成 Zabbix Server 的端口了。初始化完成后会自动跳到登录页默认账号为 Admin默认密码 zabbix。登录后第一件事就是改密码一般生产环境严禁用默认密码是共识但这个操作很多人会拖等到被扫了才后悔。4. 添加主机与让监控跑起来4.1 添加主机的基本操作登录前端界面后依次进入 数据收集 → 主机 → 创建主机。你需要在主机配置里填三个核心字段主机名称需要能识别建议用 IP-主机名 格式、可见名称用于展示、Agent 的 IP 地址和端口。端口默认 10050对应 Zabbix Agent 的监听端口。如果你用 Agent2默认端口仍然是 10050这里保持默认即可。加入群组这一步很重要你不加入任何群组权限和后续的管理都会受限建议从一开始就规划好主机群组结构比如按业务线分Web集群、数据库集群、缓存集群。4.2 模板的选择与绑定模板是我个人认为 Zabbix 里最值得花时间理解的功能。模板本质上是一组预设的监控项、触发器、图形和告警规则的集合绑定了模板等于一键给你主机配好了一整套监控方案。添加主机时选择“模板”标签页点击选择按钮从模板列表里选一个合适的。比如监控 Linux 服务器搜索 “Linux” 关键词会找到 “Linux by Zabbix agent” 模板选中并添加。监控 MySQL 数据库用 “MySQL by Zabbix agent”。一个主机可以绑定多个模板比如一个 Web 服务器的数据库节点可以同时绑定 “Linux by Zabbix agent” 和 “MySQL by Zabbix agent”。模板之间是叠加的不会冲突。4.3 监控项的键值与间隔绑定模板后监控项会自动生成你能在“主机 → 监控项”里看到它们。每一个监控项都有一个键值例如system.cpu.util[,user]表示采集用户态 CPU 使用率net.if.in[eth0]表示采集 eth0 网卡入流量。理解键值语法极其重要因为你总有一天要自己写监控项。基本规则是键名 方括号参数参数用逗号分隔如果没有参数就留空。例如system.cpu.load[all,avg1]意思是从所有 CPU 上取 load average 1 分钟的值。具体的键值清单可以在监控项配置页面点击键值旁边的问号图标查看自带说明。监控项的更新间隔Update interval默认一般是 1 分钟短一点可以更敏感地发现问题但会增加数据库压力长一点比如 5 分钟适合一些变化缓慢的指标比如磁盘已用空间我通常设置 10 分钟或更长。灵活调整而不是机械地全用默认值这是配置流程中体现经验的地方。4.4 检查数据是否采集成功添加完主机和监控项之后如果一切正常少则几秒多则一两分钟监控项就会开始有数据。怎么判断有没有数据最简单的办法是看“最新数据”页面选中这台主机如果显示有数据条目说明采集链路已经通了。如果一直没数据按顺序排查。第一Agent 是否安装并运行可以在被监控机上执行systemctl status zabbix-agent2。第二网络是否通在 Zabbix Server 上用zabbix_get -s 被监控IP -p 10050 -k system.uptime测试一下能不能取到值。第三查看前端监控项右上角的红色报错图标点开能看到具体的错误信息比如 Timeout while executing a shell script。5. 触发器配置与告警通知5.1 触发器的意义与表达式监控项采集来的数据只是数字只有通过触发器判断才变成告警。触发器的本质是一个逻辑表达式当条件为真时触发某个状态比如 PROBLEM当恢复时状态变为 OK。先看一个简单例子。假设你要监控服务器磁盘根分区使用率当使用率超过 90% 时告警。在模板或主机里新建一个触发器表达式写成last(/Linux by Zabbix agent/vfs.fs.size[/,pused])90这个表达式拆开来看last()函数取最新一个数值/Linux by Zabbix agent/是模板或主机的路径vfs.fs.size[/,pused]是监控项键值表示根分区已用百分比。最后90是条件。触发器的另一个核心函数是nodata()例如nodata(agent.ping,5m)1表示如果 agent.ping 这个键值 5 分钟没有数据就触发“主机不在线”告警。这个比单纯判断数值常见得多也是写触发器必备的套路。5.2 触发器严重程度分级Zabbix 把触发器严重程度分为五级未分类、信息、警告、一般严重、严重。建议不要滥用高等级否则告警多了真正出大事时反而没人重视。我的习惯是资源使用率超阈值用“警告”服务宕机或数据丢失用“严重”处于两者之间的用“一般严重”。分级的意义不只是好看它会直接驱动告警媒介的行为。比如你可以设置警告级只发邮件严重级同时发邮件加短信并且重复发送间隔缩短。5.3 配置告警媒介与动作告警媒介是通知渠道动作是告警发生时执行的行为。两者配合才能把告警送出去。先添加媒介。路径用户 → 用户 → 点击 Admin → 告警媒介。这里可以添加邮箱、短信网关或 Webhook。添加邮箱时你需要配置 SMTP 服务器地址、端口、认证账号和密码并设置收件人地址。Zabbix 不会自己去发现发件人所有信息都需要手动填。配置动作的路径是告警 → 动作 → 创建动作。动作的触发需要满足条件比如“触发器严重程度 ≥ 警告”以及“主机群组包含 XX”。条件满足后定义动作操作发送消息给某个用户或用户群组消息内容可以使用宏变量比如{HOST.NAME}表示主机名{ITEM.NAME}表示监控项名称{TRIGGER.NAME}表示触发器名称{TRIGGER.SEVERITY}表示严重等级。{ITEM.LASTVALUE}是很有用的宏表示监控项最后一个数值比如磁盘使用率当前的值是多少用户收到告警邮件时就能直接看到关键数据而不需要再去前端查。建议在消息内容里明确写明触发器的详细信息最好的告警消息是“哪台机器的哪个指标当前值是多少超过或低于阈值多少”。动作里还可以设置“恢复操作”和“更新操作”。恢复操作的意思是当问题解决时发送一条“OK”消息这能让值班人员确认问题已经闭环而不是石沉大海。更新操作则是问题持续存在时每隔一段时间再次发送通知防止告警被遗漏。5.4 告警升级机制大型环境里告警升级是必须的。比如一条“数据库服务不可用”的严重告警如果 10 分钟没有被处理就升级给运维主管30 分钟还没处理就升级给技术总监。Zabbix 的动作里可以设置多个“操作步骤”每一步可以设置不同的发送对象和消息内容加上“开始时间”和“持续时长”就能实现升级。这一步很多教程不会细讲但踩过坑的人都知道没有升级机制告警发到一个人邮箱里人不在位问题就没人管了。合理配置严重告警的重复发送和升级比单纯把严重级别调高更有用。6. 模板、自定义监控与宏变量6.1 模板的复制与修改模板自带的监控项设置有时候不符合你的实际需求比如默认的触发器阈值太低或者某个监控项你根本不需要。直接修改官方模板会带来一个问题以后升级官方模板时你的修改被覆盖或冲突。所以正确做法是复制模板。在模板列表里选择你要修改的模板点击“全克隆”克隆出一个新模板比如“Linux by Zabbix agent - Custom”然后在新模板里随意修改。修改完成后绑定到这个新模板的主机也会自动切换到新配置。6.2 自定义监控项的实现Zabbix 不可能覆盖所有监控场景比如你有一个自研程序需要暴露一个特定文件里的某个数值。这时候你就需要自定义监控项。有两种方式第一种利用 Zabbix Agent 的 UserParameter。编辑 Agent 配置文件 /etc/zabbix/zabbix_agent2.conf增加UserParametermyapp.requests,/usr/local/bin/count_requests.sh然后在前端监控项里新建监控项键值写myapp.requests更新间隔按需设置。脚本count_requests.sh每次执行后会输出一个数字这个数字就被当作监控值存入 Zabbix。注意脚本要保证执行时间短建议控制在 3 秒内否则容易超时另外脚本输出不要有多余的文本或换行Zabbix 取的是第一行整数值。第二种通过 Zabbix Agent 的不可用采集项perf_counter或模块来实现。这种更底层对新手来说用前者就够了。自定义监控项最容易犯的错误是路径问题。脚本路径写错会导致no such file or directory错误或者脚本没有执行权限。建议先在 Agent 所在的机器上手动执行一遍确认能输出预期值后再配置到前端。6.3 宏变量的使用技巧Zabbix 里的宏变量是一大“隐藏武器”学会用宏能大幅减少配置里的重复劳动。全局宏在“管理 → 通用 → 宏”里定义比如定义一个{$PASSWORD}宏作为数据库密码这样在多个主机上需要用到密码时直接引用宏而不需要在每个主机配置里明文写密码。模板级宏更好用。比如监控所有 Web 服务器的 URL 响应时间不同服务器监控的 URL 可能不同但模板结构相同。这时你可以在模板里定义一个宏{$URL_PATH : /health}然后在监控项键值里用web.page.get[{$URL_PATH}]。这样每次有新服务器加入你只需要在新的主机配置里覆盖{$URL_PATH}这个宏的值而不用修改模板或手动改监控项。宏变量还有自动发现Low-Level Discovery的配合使用。比如自动发现主机上的所有网卡、磁盘或文件系统然后根据宏值自动创建对应的监控项。配置了自动发现规则后新加的磁盘或网卡会被自动纳入监控省去人工维护列表的烦恼。7. 常见问题汇总与性能优化7.1 常见报错与解决办法配置过程中我碰到过比较高频的错误整理成下面这份速查表现象大概率原因处理办法最新数据里监控项一直没值Agent 未安装、网络不通、键值错误用 zabbix_get 测试键值检查防火墙端口 10050 是否开放Web 界面登录后白屏或报 PHP 错误PHP 缺少必要的扩展或版本过低安装 php-bcmath、php-mbstring、php-xml 等扩展检查 PHP 版本符合要求触发器告警收不到邮件媒介配置错误、动作没有绑定用户、SMTP 被云服务商封先检查“报告 → 动作日志”看动作是否执行邮件发送失败通常在动作日志里有具体报错数据库写入性能下降历史数据保留时间过长、监控项过多调整“历史数据保留时间”和“趋势数据保留时间”考虑对数据库进行分区无法创建主机提示权限不足用户群组没有权限在“用户群组”中给对应的群组添加权限否则只能查看不能编辑主机显示红色不可达Zabbix Server 无法连接 Agent检查 Agent 是否正在运行检查 Agent 配置文件里的 Server 列表是否包含 Zabbix Server 的 IP7.2 性能优化建议Zabbix 部署规模变大之后性能会慢慢成为瓶颈。有几点我实际用过之后觉得效果很明显一是历史数据与趋势数据保留时间要分开设置。历史数据原始数据可以只保留 14 天趋势数据小时级聚合可以保留 365 天甚至更久。历史数据保留过长数据库读写压力成倍增加而趋势数据已经能表达变化趋势。二是监控项的收集间隔不要无脑用默认 1 分钟。对于状态类指标比如进程存活、端口存活可以提高到 2 或 5 分钟只有性能类指标如 CPU、内存、IO 才考虑短间隔。同一个主机绑定了多个模板可能产生几百个监控项如果全是一分钟间隔后端负担非常大。三是用 Zabbix Proxy 做分流。如果监控节点分布在不同网络区域比如总部机房和分支机构与其统一连中心 Server不如在分支机构部署一台 Proxy。Agent 被分支机构的 Proxy 采集Proxy 再与中心 Server 通信。这样既降低跨网络带宽占用也让中心 Server 的负担小很多。注意Proxy 本身也需要配置数据库与 Server 的通信端口是 10051而不是 10050别搞混了。7.3 安全与日常维护很多生产 Zabbix 服务器被入侵问题往往出在默认密码和弱口令上。装完 Zabbix 后请立即修改 Admin 密码并且关闭前端页面的匿名访问部分。前端的安装引导可以删除或锁定相关文件防止被二次利用。Agent 配置也值得注意。Agent 监听接口不要暴露到公网尽量绑定内网地址。Zabbix Agent 的 Server 配置项里只允许列表中的 Zabbix Server 拉取数据这能防止别人乱建监控项或者干扰采集。日常维护里备份是最容易忽略的。数据库承担了大量配置和监控数据建议至少每天备份一次 Zabbix 数据库备份文件单独存放。容灾恢复时只要数据库恢复加上原来的配置文件整个 Zabbix 系统就能快速复原。另外监控告警的维护期也不是小事。正常的业务发布、停机维护期间如果不设置“维护期间”告警会疯狂爆发值班人员被轰炸到怀疑人生。你可以在“告警 → 维护”里创建维护窗口选择时间段和执行周期Zabbix 不会在维护期间内触发告警动作。这功能非常实用我每一次上线变更前都会主动设置不然半夜一次重启能发出几百条告警邮件。一些说明Zabbix 的配置流程走一遍之后你会发现它其实是一个很线性的过程准备环境 → 初始化数据库 → 部署前端 → 添加主机 → 配好监控项 → 写好触发器 → 配置告警动作。每一步都不难但每一步都会决定后面能否顺利跑起来。我个人在实际操作中的体会是配置流程里最值得花时间打磨的不是某一台主机的添加而是主机分组和模板管理的规划。前期分类分得清楚后期新加主机、调整阈值、排查问题都会非常顺手。如果你是一个 Zabbix 新人先从头到尾配通一条链路再用模板批量添加几十台机器你就能感受到这套配置流程真正的威力在哪里。