1. 为什么这套监控组合值得花时间搭监控这件事很多团队都是等到出事了才想起来补。我见过太多这样的情况服务器磁盘满了没人知道某个服务进程半夜挂了第二天才发现集群扩容之后新节点压根没纳入监控。这些问题归根结底不是技术难而是监控体系没有搭好。这套方案的核心思路是用Zabbix作为监控底座配合基础模板快速覆盖常见指标通过自动发现机制解决集群节点动态变化的问题最后用自定义监控脚本补齐业务层面的个性化指标。四个环节环环相扣缺一个都会让监控体系出现盲区。具体来说这套方案解决的是这样几个问题第一基础资源监控CPU、内存、磁盘、网络用现成模板一键覆盖不用重复造轮子第二集群环境下节点IP经常变动手动添加主机不现实自动发现注册能让新节点上线后自动纳入监控第三业务层面的指标比如某个队列积压数、某个接口的响应时间没有现成模板需要自己写脚本采集。适合谁来参考如果你手里管着几台到几十台服务器正在用或者打算用 Zabbix 做监控尤其是集群环境下的监控这套流程可以直接抄作业。如果你是完全没接触过 Zabbix 的新手建议先把基础概念过一遍再来看不然有些操作会卡住。下面我按实际部署的顺序来拆从服务端安装到最终的自定义脚本上线每一步都附上我踩过的坑和实测有效的配置。2. 部署前的规划与选型决策2.1 版本选择与组件拆分逻辑Zabbix 的版本迭代比较快选版本这件事我的建议是生产环境用偶数版本的最新稳定版。比如 6.0、6.4 这种奇数版本6.1、6.3是开发版不适合上生产。截至目前6.0 LTS 和 6.4 是比较稳妥的选择6.0 的支持周期更长6.4 的功能更新一些。组件拆分上小规模环境50台以内可以把 Server、Web、Database 装在一台机器上省事。但一旦超过这个量级或者对可用性有要求就必须拆开组件作用拆分建议Zabbix Server核心引擎处理数据采集和告警独立部署配置要高Zabbix Web前端界面可以和 Server 同机Database存储配置和历史数据独立部署IO 要快Zabbix Proxy分布式采集代理跨机房场景必用我自己的环境是 Server 和 Web 放一起数据库单独一台因为数据库的 IO 压力最大混在一起容易互相影响。2.2 数据库选型的实际考量Zabbix 支持 MySQL 和 PostgreSQL官方推荐 PostgreSQL。但说实话如果你团队更熟悉 MySQL用 MySQL 也完全没问题性能差距在实际场景中没那么明显。关键点在于数据库的参数调优这个比选哪个数据库更重要。以 MySQL 为例几个必须调的参数innodb_buffer_pool_size 物理内存的 60%-70% innodb_log_file_size 256M innodb_flush_log_at_trx_commit 2 innodb_file_per_table 1innodb_buffer_pool_size是最关键的它决定了多少数据能缓存在内存里。Zabbix 的历史数据写入非常频繁这个值太小会导致大量磁盘 IO。我见过一个案例buffer pool 只给了 128M结果数据库 CPU 常年 80% 以上调到 8G 之后直接降到 10%。注意innodb_flush_log_at_trx_commit设为 2 会牺牲一点持久性断电可能丢最近1秒的数据但监控数据丢几秒无所谓换来的是写入性能大幅提升。2.3 网络与端口规划部署前把端口理清楚能省掉后面很多排查时间10051Zabbix Server 监听端口Agent 主动上报和 Proxy 通信都走这个10050Zabbix Agent 监听端口Server 主动拉取数据时用80/443Web 界面3306/5432数据库端口防火墙规则要提前放行。我踩过的坑是Server 能连 Agent 的 10050但 Agent 主动上报到 Server 的 10051 没放行导致主动模式的主机一直显示不可用排查了半天才发现是防火墙问题。3. Zabbix 服务端的完整部署过程3.1 系统环境准备与依赖安装我以主流的 Linux 发行版为例用包管理方式安装最省事。先装仓库配置包# 下载并安装 Zabbix 官方仓库 rpm -Uvh https://repo.zabbix.com/zabbix/6.4/rhel/8/x86_64/zabbix-release-6.4-1.el8.noarch.rpm dnf clean all然后安装 Server、Web、Agent 和数据库dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-nginx-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent mysql-server这里有个细节zabbix-sql-scripts 包含了建表的 SQL 文件后面初始化数据库要用到别漏装。3.2 数据库初始化与导入启动数据库并创建 Zabbix 专用库和用户CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER zabbixlocalhost IDENTIFIED BY 你的强密码; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; SET GLOBAL log_bin_trust_function_creators 1; FLUSH PRIVILEGES;log_bin_trust_function_creators 1这个必须开否则导入 SQL 时会因为创建函数报错。导入数据zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix导入完成后记得把log_bin_trust_function_creators关掉这是个安全实践。实操心得导入过程视机器性能可能要几分钟到十几分钟别以为卡死了就中断。我见过有人等了两分钟以为挂了CtrlC 之后重新导入结果表结构冲突只能删库重来。3.3 Server 配置与 Web 前端调优编辑/etc/zabbix/zabbix_server.conf核心是数据库连接信息DBHostlocalhost DBNamezabbix DBUserzabbix DBPassword你的强密码Web 前端的 PHP 配置在/etc/php-fpm.d/zabbix.conf重点是时区php_value[date.timezone] Asia/Shanghai时区不设对Web 界面上的时间全是 UTC看告警时间会很别扭。启动所有服务并设置开机自启systemctl restart zabbix-server zabbix-agent nginx php-fpm systemctl enable zabbix-server zabbix-agent nginx php-fpm浏览器访问 Web 界面按向导走完初始化默认账号是 Admin密码 zabbix。第一件事就是改密码这个不用多说。4. 基础模板的配置与优化4.1 内置模板的选用策略Zabbix 自带了一堆模板但不要无脑全用。我的原则是只启用真正需要的监控项监控项太多会导致数据量爆炸数据库压力大而且告警噪音多。常用的几个模板Linux by Zabbix agentLinux 主机的基础监控CPU、内存、磁盘、网络、进程都有Windows by Zabbix agentWindows 主机对应模板MySQL by Zabbix agent 2MySQL 数据库监控Nginx by Zabbix agentNginx 状态监控以 Linux 模板为例它默认采集的指标有几十个但有些你可能根本不关心。比如Number of logged in users登录用户数这个指标对大多数场景没意义可以在模板里禁用掉对应的监控项。4.2 模板的克隆与定制直接改内置模板不是好习惯因为升级时会覆盖。正确做法是克隆一份再改在「配置」→「模板」里找到目标模板点击「克隆」改个名字比如Linux by Zabbix agent - 定制版在克隆版上做增删改这样升级 Zabbix 时内置模板更新了你的定制版不受影响需要的话再手动合并新特性。4.3 监控项与触发器的调优默认的触发器阈值不一定适合你的环境。比如磁盘空间告警默认是剩余 20% 和 10% 两档但如果你有台机器专门存日志磁盘用到 90% 是常态这个阈值就会天天告警。调整方法在模板的「触发器」里找到对应项修改表达式。比如把磁盘告警改成剩余 5% 才告警last(/Linux by Zabbix agent - 定制版/vfs.fs.size[/,pfree])5注意改触发器阈值前先观察一段时间默认阈值的告警情况看看哪些是噪音再针对性调整。一上来就大改容易把真正该告警的也改没了。另外监控项的历史数据保留时间也要调。默认是 90 天但像 CPU 这种高频采集的指标90 天数据量很大。我的做法是核心指标保留 90 天次要指标保留 30 天趋势数据统一保留 365 天。趋势数据是每小时聚合的占用空间小适合做长期分析。5. 自动发现与集群 IP 注册的实现5.1 自动发现的两种模式对比Zabbix 的自动发现分两种网络发现和主动式自动注册。这两个概念容易混我一开始也搞错过。模式工作原理适用场景网络发现Server 扫描指定 IP 段发现存活主机首次批量纳管IP 段固定自动注册Agent 主动上报自己的信息Server 按规则纳管集群动态扩容IP 不固定集群环境下节点 IP 经常变用网络发现就得不停改扫描范围不现实。自动注册才是正解Agent 启动后主动告诉 Server「我来了我的 IP 是 X我的主机名是 Y」Server 根据预设规则自动把它加到对应主机组并关联模板。5.2 自动注册的配置步骤第一步Agent 端配置编辑/etc/zabbix/zabbix_agentd.confServer你的ServerIP ServerActive你的ServerIP Hostname节点唯一标识 HostMetadatalinux-cluster-node关键是HostMetadata这是 Agent 上报给 Server 的元数据Server 靠它来匹配注册规则。可以写多个值用逗号分隔。第二步Server 端创建动作在 Web 界面「配置」→「动作」→「自动注册」里创建动作条件Host metadata包含linux-cluster-node操作添加主机、添加到主机组「集群节点」、关联模板「Linux by Zabbix agent - 定制版」这样新节点上线后Agent 一启动Server 就自动把它纳管了。第三步验证注册结果在「监测」→「主机」里看新节点有没有出现。如果没有检查几个点Agent 的ServerActive是否指向正确的 Server IPServer 的 10051 端口是否对 Agent 开放动作的条件是否匹配上了可以在「报表」→「动作日志」里看实操心得HostMetadata的值不要用中文也不要有空格否则匹配容易出问题。我习惯用角色-环境的格式比如web-prod、db-prod这样一台 Server 可以按角色分发不同模板。5.3 集群场景下的主机命名规范自动注册有个坑如果主机名重复后注册的会覆盖先注册的。集群扩容时如果新节点用了和旧节点一样的主机名就会出问题。我的做法是用「角色-序号-环境」的命名规范比如web-01-prod、web-02-prod。Agent 的Hostname参数就设成这个值保证全局唯一。如果节点是容器化的每次重建 IP 和主机名都变那就得用容器的唯一 ID 作为主机名或者在启动脚本里动态生成。这个场景比较复杂后面自定义脚本那节会提到怎么配合。6. 自定义监控脚本的编写与集成6.1 什么场景需要自定义脚本内置模板覆盖的是通用指标但业务层面的指标它管不了。举几个我实际遇到过的需求某个消息队列的积压消息数某个接口的 P99 响应时间某个定时任务上次执行是否成功某个目录下的文件数量这些指标没有现成的采集方式必须自己写脚本。6.2 脚本编写规范与 UserParameterZabbix 采集自定义指标靠的是UserParameter。在 Agent 配置文件里加一行UserParameterqueue.backlog[*],/etc/zabbix/scripts/check_queue.sh $1这行的意思是定义一个叫queue.backlog的监控项后面跟参数实际执行/etc/zabbix/scripts/check_queue.sh并把参数传进去。脚本本身要遵守几个规范输出必须是单个数值或者符合 Zabbix 格式的字符串执行时间要短超过 Agent 的Timeout默认3秒会被杀掉要有错误处理采集失败时返回一个明确的错误值而不是空一个检查队列积压的脚本示例#!/bin/bash QUEUE_NAME$1 BACKLOG$(some_command_to_get_backlog $QUEUE_NAME 2/dev/null) if [ -z $BACKLOG ]; then echo ZBX_NOTSUPPORTED exit 1 fi echo $BACKLOGZBX_NOTSUPPORTED是 Zabbix 约定的错误标识返回这个值监控项会显示为「不支持」而不是采集到一个错误的 0。6.3 脚本的测试与调试方法脚本写完别急着往模板里加先在命令行测试# 直接跑脚本 /etc/zabbix/scripts/check_queue.sh myqueue # 用 zabbix_get 模拟 Server 拉取 zabbix_get -s 127.0.0.1 -k queue.backlog[myqueue]zabbix_get这个工具特别有用它能模拟 Server 向 Agent 发请求验证 UserParameter 配置是否正确。如果命令行跑脚本正常但zabbix_get报错那问题就在 Agent 配置上通常是权限或者路径问题。注意Agent 是以zabbix用户运行的脚本和它依赖的命令必须对这个用户可执行。我踩过的坑是脚本用了某个只有 root 能跑的命令命令行测试用 root 跑没问题Agent 一采集就失败。解决办法是用 sudo 配置免密或者把脚本改成不依赖特权命令。6.4 自定义监控项的模板化脚本调通之后把它做成模板方便批量应用在模板里新建监控项类型选「Zabbix 客户端」Key 填queue.backlog[{$QUEUE_NAME}]{$QUEUE_NAME}是宏可以在主机级别覆盖用宏的好处是同一个模板应用到不同主机每台主机可以设不同的队列名不用改模板。再配上触发器和图形一个完整的自定义监控就成型了。触发器比如积压超过 1000 告警last(/Template Queue Monitor/queue.backlog[{$QUEUE_NAME}])10007. 常见问题排查与避坑经验7.1 主机显示不可用的排查思路这是最常见的问题排查顺序我总结成一张表现象可能原因排查方法主动模式不可用Server 10051 未放行telnet ServerIP 10051被动模式不可用Agent 10050 未放行telnet AgentIP 10050主机名不匹配Agent Hostname 与配置不一致检查 agentd.conf采集超时脚本执行太慢看 Agent 日志Agent 日志在/var/log/zabbix/zabbix_agentd.logServer 日志在/var/log/zabbix/zabbix_server.log出问题先看日志90% 的问题日志里都有线索。7.2 自动注册不生效的几种情况自动注册配好了但新节点没进来我遇到过这几种原因HostMetadata 没设或设错Agent 配置里漏了这一行或者值和动作条件对不上动作没启用创建完动作忘了点启用这个很低级但真的容易忘主机已存在同名主机已经手动加过了自动注册不会重复添加Server 的自动注册进程没跑zabbix_server的 autoregistration 进程数设为 0 了排查的时候去「报表」→「动作日志」看如果动作触发了但操作失败日志里会写原因。7.3 数据库性能瓶颈的识别与处理Zabbix 跑一段时间后变慢多半是数据库的问题。几个关键信号Web 界面打开慢尤其是历史数据页面Server 日志里出现query is too slow警告数据库 CPU 持续高位处理手段按优先级调大 innodb_buffer_pool_size这是收益最明显的清理历史数据把不重要的监控项保留时间调短开启数据库分区Zabbix 自带分区脚本按时间分区后查询和清理都快很多拆分数据库把 history 和 trends 分到不同表空间我自己的经验是50 台主机、500 个监控项的环境buffer pool 给 8G历史数据保留 30 天跑起来很轻松。超过这个规模分区就得上。7.4 自定义脚本的常见坑最后集中说几个自定义脚本的坑脚本输出带换行或空格Zabbix 对输出格式敏感echo出来的值前后有空格会导致解析失败用echo -n或者printf脚本依赖的环境变量Agent 运行时的环境变量和登录 shell 不一样脚本里最好用绝对路径脚本执行权限别忘了chmod x而且属主要对超时设置复杂脚本要调大 Agent 的Timeout但别调太大会拖累整体采集这套监控体系搭好之后日常维护其实很省心。新节点上线自动纳管业务指标有脚本兜底告警阈值按环境调优。真正花时间的是一次性把基础打牢后面就是享受自动化带来的便利了。