1. 为什么你需要Zabbix自动发现从手动到自动的蜕变如果你刚开始接触服务器监控大概率会经历这样一个阶段登录Zabbix网页手动添加主机然后一个一个地添加监控项比如CPU使用率、内存使用率、磁盘空间再为每个监控项设置触发器告警。监控三五台服务器还好一旦服务器数量上了十台、二十台或者服务器上跑着几十个需要监控的端口和服务这种重复劳动就会让人头皮发麻不仅效率低下还特别容易出错。你可能昨天刚加了一台新服务器今天业务就出了点小问题结果一查发现监控项漏加了几个告警根本没触发只能自己背锅。Zabbix的自动发现功能就是为了解决这种“人肉运维”的痛点而生的。它的核心思想很简单让Zabbix自己去“找”需要监控的东西然后自动创建对应的监控项和触发器实现监控配置的自动化。想象一下你只需要定义好一个规则比如“监控所有TCP监听端口”Zabbix Agent就会自动把服务器上所有打开的端口列表上报给Server。Server拿到这个列表后会自动为每一个端口创建“端口是否存活”的监控项并配上“端口宕机就告警”的触发器。之后无论服务器上新开了端口还是关闭了旧端口监控都会自动跟上你再也不用手动去点来点去了。这听起来很美好但对新手来说官方文档和一些教程往往直接抛出一堆概念比如“低级自动发现”、“监控项原型”、“触发器原型”、“LLD宏”让人看得云里雾里配置步骤也显得支离破碎不知道每一步到底在干什么为什么这么干。我自己刚开始配置的时候就卡在好几个地方反复折腾才搞明白。所以这篇文章我会用一个最经典、也最实用的场景——自动发现并监控服务器上的指定TCP端口——作为例子带你从零开始手把手走通整个流程。我会把每一步的原理、操作和容易踩的坑都掰开揉碎了讲目标是让你跟着做一遍之后不仅能成功配置出来更能真正理解背后的逻辑以后举一反三去配置监控磁盘分区、监控日志文件、监控自定义服务都不在话下。2. 环境准备与核心概念扫盲在开始动手之前我们先把实验环境和几个核心概念搞清楚这能帮你更好地理解后续的每一步操作。实验环境搭建我建议你准备两台虚拟机这样最贴近真实场景。一台装Zabbix Server带Web界面另一台装Zabbix Agent。如果条件有限用一台机器同时安装Server和Agent也可以这种叫“单机部署”或“本机监控”但要注意区分两者的角色。Zabbix Server: 我用的版本是7.0IP地址是192.168.0.60。版本其实影响不大6.0、6.4的配置逻辑基本一致。Zabbix Agent: 我用的是2号版本IP是192.168.0.51。同样Agent1或Agent2的差异对我们这个实验没有影响。必须理解的三个核心概念很多人配置失败就是因为没理解下面这三个东西是干什么的它们是如何串联起来的。自动发现规则 (Discovery Rule) 这是自动发现的“发动机”。你在Zabbix Server上创建它告诉Zabbix“你去用哪个‘钥匙’键值从Agent那里拿数据” 这个“钥匙”就是我们后面要在Agent上配置的UserParameter。规则还会定义多久执行一次这个发现动作比如每隔1小时。监控项原型 (Item Prototype)和触发器原型 (Trigger Prototype) 这是自动发现的“蓝图”。光有发动机不行还得知道发现出东西后要把它做成什么样子。监控项原型定义了针对每一个被发现的对象比如一个端口要创建什么样的监控项比如监控这个端口的网络状态。触发器原型则定义了针对这个监控项在什么条件下需要告警比如端口连续5分钟不可达。LLD宏 (Low-Level Discovery Macros) 这是连接“发现结果”和“原型”的“变量”。当Agent通过脚本返回一个端口列表比如[{{#TCP_PORT}: 8080}, {{#TCP_PORT}: 3306}]时{#TCP_PORT}就是一个LLD宏。在监控项原型里你就可以用net.tcp.service[tcp, {#TCP_PORT}]这样的形式来引用它。这样Zabbix就会为列表里的每一个端口8080和3306分别生成一个具体的监控项net.tcp.service[tcp, 8080]和net.tcp.service[tcp, 3306]。简单来说整个过程就是Server通过“发现规则”调用Agent的“钥匙”Agent执行脚本返回一个带“宏”的数据列表Server根据“原型”和列表中的“宏”批量生成具体的监控项和触发器。3. Server端配置创建自动发现规则与原型现在我们登录Zabbix Server的Web界面开始操作。假设你已经安装好了Zabbix并且能正常登录管理后台。3.1 创建模板并配置自动发现规则我强烈建议你把自动发现的配置放在模板里而不是直接配置在主机上。这样做的好处是以后任何新的服务器你只需要把它链接到这个模板它就自动拥有了全套端口监控能力维护起来非常方便。首先进入“配置” - “模板”点击右上角的“创建模板”。模板名称 起个容易识别的名字比如Template Auto Discovery TCP Ports。群组 选一个比如Templates。其他保持默认点击“添加”。创建好模板后点击进入这个模板的详情页。在顶部选项卡中找到并点击“自动发现规则”然后点击“创建发现规则”。这里是关键配置步骤我逐一解释名称 填写Discovery TCP Ports方便识别。类型 选择“Zabbix客户端”。这意味着Server会去主动询问Agent获取数据。键值 这是最重要的一步这里填的键值必须和后面我们在Agent上配置的UserParameter名称完全一致。我们这里填readPorts。你可以把它理解为Server对Agent说“嘿把readPorts这个钥匙对应的数据给我。”更新间隔 设置自动发现多久执行一次。端口列表通常不会频繁变动设置成1h1小时或者30m30分钟都可以。其他 保持默认即可然后点击“添加”。这样发现规则的“发动机”就装好了。接下来我们要为它设计“蓝图”。3.2 创建监控项原型在刚才创建好的发现规则Discovery TCP Ports那一行点击“监控项原型”然后点击“创建监控项原型”。名称 这里我们要使用LLD宏来让名称动态化。填写TCP Port {#TCP_PORT} is listening。这样当发现端口8080时生成的监控项名称就是TCP Port 8080 is listening一目了然。类型 选择“Zabbix客户端”。键值 这里要填写真正用于检测端口的键。Zabbix内置了一个非常方便的键net.tcp.service[tcp, {#TCP_PORT}]。这个键会尝试连接指定IP的指定TCP端口返回1表示成功0表示失败。注意这里的{#TCP_PORT}就是宏它会自动被替换成具体的端口号比如8080或3306。信息类型 选择“数字无正负”因为返回值是0或1。单位 可以留空。更新间隔 设置检查频率比如30s30秒检查一次端口状态。历史数据保留时长和趋势存储时长 根据你的存储策略调整新手可以先用默认值。填写完后点击“添加”。这个原型告诉Zabbix“每发现一个{#TCP_PORT}宏就创建一个用net.tcp.service去检测该端口是否存活的监控项。”3.3 创建触发器原型光有监控项还不够端口挂了得告警。我们继续在发现规则页面点击“触发器原型”然后“创建触发器原型”。名称 同样使用宏填写Port {#TCP_PORT} is down on {HOST.NAME}。这样告警时会清晰显示是哪台主机的哪个端口出了问题。严重性 根据端口重要性选择比如选择“一般严重”或“严重”。表达式 这里是配置告警条件。点击“添加”来构造表达式。在弹出的窗口中“监控项”选择我们上一步创建的监控项原型TCP Port {#TCP_PORT} is listening。“功能”选择“最后最近的值 N”。“N” 填写0。整个表达式的意思是最近一次检测到的端口状态值如果等于0即端口不可达则触发告警。事件成功迭代 可以设置成1m意思是如果端口在1分钟内恢复了告警会自动解决触发一个“已解决”的事件。配置完成后点击“插入”再点击原型页面的“添加”。这样蓝图部分也全部完成了。3.4 将模板链接到主机最后一步让我们的目标主机应用这个模板。进入“配置” - “主机”找到你的Agent主机IP为192.168.0.51的那台点击主机名称进入详情。在主机详情页找到“模板”这个标签页。在“链接新模板”的输入框里输入我们刚才创建的模板名字Template Auto Discovery TCP Ports从下拉列表中选择它然后点击“添加”最后别忘了点击页面底部的“更新”按钮。至此Server端的配置全部完成。但这只是告诉Server“怎么想”数据还得靠Agent提供。如果现在就去检查你会发现什么监控项都没生成因为Agent那边还没准备好。4. Agent端配置准备数据与脚本现在我们把目光转向被监控的服务器也就是Zabbix Agent端192.168.0.51。Server端的规则要求提供readPorts这个键的数据我们的任务就是在Agent上实现它。4.1 修改Agent配置文件启用自定义键首先我们需要编辑Zabbix Agent的配置文件通常是/etc/zabbix/zabbix_agentd.conf。你需要有root权限。sudo vim /etc/zabbix/zabbix_agentd.conf找到并修改或添加以下两个参数UnsafeUserParameters1 UserParameterreadPorts,/etc/zabbix/scripts/readPorts.sh我来详细解释一下这两行UnsafeUserParameters1 这个参数必须设置为1它允许Zabbix Agent执行我们在UserParameter中定义的脚本。从安全角度讲它有点“危险”因为如果脚本写得不好可能有风险。但在我们可控的内网学习环境里可以打开。这是很多新手会漏掉的一步漏了后面脚本永远返回空数据。UserParameterreadPorts,/etc/zabbix/scripts/readPorts.sh 这是定义自定义键的核心语法。格式是UserParameter键名,命令或脚本路径。readPorts 这个键名必须和我们在Server端“自动发现规则”里填写的“键值”一字不差地对应上。这是通信的密码。/etc/zabbix/scripts/readPorts.sh 这是当Zabbix Server请求readPorts键时Agent本地要执行的脚本的绝对路径。脚本执行后的输出标准输出就是返回给Server的数据。保存并退出编辑器。4.2 创建脚本与数据文件接下来我们需要创建脚本文件和它要读取的数据文件。按照上面配置的路径我们创建目录和文件。# 创建存放脚本的目录 sudo mkdir -p /etc/zabbix/scripts cd /etc/zabbix/scripts第一步创建数据源文件ports.json。这个文件的内容就是自动发现要返回的数据必须遵循特定的JSON格式。为了简化我们先手动创建这个文件。在实际生产环境中这个文件可能是由另一个脚本定期从系统配置文件比如/etc/services或你的CMDB配置管理数据库中生成的。sudo vim ports.json将以下内容写入文件{ data: [ { {#SERVICE}: web_server, {#TCP_PORT}: 8080 }, { {#SERVICE}: mysql_db, {#TCP_PORT}: 3306 }, { {#SERVICE}: custom_app, {#TCP_PORT}: 9000 } ] }这个JSON结构是Zabbix LLD要求的固定格式。data是一个数组里面的每个对象代表一个被发现的项目。每个对象里的键值对就是“宏”和它的值。{#SERVICE}: 这是我们自定义的一个宏代表服务名称。它在监控项原型名称里可以用到比如把监控项名称改成{#SERVICE} on port {#TCP_PORT}会更友好。{#TCP_PORT}: 这是我们定义的核心宏代表端口号。它必须和Server端监控项原型键值里的{#TCP_PORT}宏对应。第二步创建发现脚本readPorts.sh。这个脚本的任务非常简单读取上面那个ports.json文件并将其内容打印出来。Zabbix Agent会捕获这个输出并传给Server。sudo vim readPorts.sh写入以下内容#!/bin/bash # 这是一个简单的自动发现脚本用于读取端口列表JSON文件 JSON_FILE/etc/zabbix/scripts/ports.json # 检查文件是否存在 if [ -f $JSON_FILE ]; then cat $JSON_FILE else # 如果文件不存在输出一个空的JSON结构避免Zabbix报错 echo {data:[]} fi第一行#!/bin/bash是指定脚本解释器。脚本的核心就是cat命令输出JSON文件的内容。我们还加了一个简单的容错判断如果JSON文件意外丢失就输出一个空数组防止Zabbix因获取到无效数据而报错。然后给脚本加上执行权限否则Zabbix Agent用户通常是zabbix没有权利运行它。sudo chmod x /etc/zabbix/scripts/readPorts.sh4.3 重启Agent服务并测试所有文件准备就绪后需要重启Zabbix Agent服务以使配置生效。sudo systemctl restart zabbix-agent # 检查服务状态确保是运行中 sudo systemctl status zabbix-agent现在我们可以在Server端进行一次手动测试验证Agent是否能够正确返回数据。在Zabbix Server机器上192.168.0.60使用zabbix_get命令工具。zabbix_get -s 192.168.0.51 -k readPorts-s: 指定Agent的IP地址。-k: 指定要获取的键值就是我们在配置里定义的readPorts。如果一切配置正确你应该会看到终端上打印出和ports.json文件内容一模一样的JSON数据。这证明从Server到Agent的这条“数据通道”已经打通了Agent能够正确响应Server的查询。注意如果这里执行zabbix_get失败常见的错误有1. 网络不通或防火墙阻挡了10050端口2. Agent配置未重启3. 脚本路径错误或权限不足zabbix用户无法执行4.UnsafeUserParameters未设置为1。你需要根据错误信息逐一排查。5. 效果验证与前端查看最激动人心的时刻到了当Agent配置正确且返回数据后Zabbix Server会在下一次自动发现规则执行时或者我们可以手动让它立即执行处理这些数据并自动创建监控项和触发器。5.1 触发自动发现并查看结果回到Zabbix Web界面进入“配置” - “主机”找到你的Agent主机。点击主机名进入“自动发现规则”标签页。你应该能看到我们之前创建的Discovery TCP Ports规则。可以点击规则名称旁边的“立即执行”按钮一个播放图标手动触发一次发现。等待几秒钟到一分钟然后进入“监控中” - “最新数据”。在过滤器中选择你的主机192.168.0.51点击应用。神奇的事情发生了你应该能看到列表中自动出现了三个监控项TCP Port 8080 is listeningTCP Port 3306 is listeningTCP Port 9000 is listening点击任意一个监控项查看其历史数据图表你会看到一条表示端口状态的曲线值在1附近波动表示端口正常。这意味着Zabbix已经在按照30秒一次的频率主动检测这三个端口的状态了。5.2 验证触发器原型接下来我们验证触发器是否也自动生成了。进入“配置” - “主机”- 选择主机 -“触发器”标签页。你会发现这里自动创建了三个触发器Port 8080 is down on 192.168.0.51Port 3306 is down on 192.168.0.51Port 9000 is down on 192.168.0.51为了测试告警是否有效我们可以手动关闭其中一个端口上的服务。比如停掉监听在8080端口的Web服务。等待一两个监控周期大约1分钟然后去“监控中” - “问题”页面查看。你应该能看到一条关于Port 8080 is down on 192.168.0.51的新问题被触发并显示为“一般严重”或你之前设置的严重性等级。当你重新启动该服务后问题状态会自动变为“已解决”。这个过程完全无需人工干预。5.3 动态扩展性测试自动发现的威力在于它的动态性。现在我们模拟一个场景服务器上新部署了一个应用监听在10086端口。我们只需要修改Agent端的ports.json文件添加这个新端口。sudo vim /etc/zabbix/scripts/ports.json在data数组里新增一个对象{ {#SERVICE}: new_service, {#TCP_PORT}: 10086 }保存文件。你不需要重启Agent服务也不需要修改Server的任何配置。只需等待下一个自动发现周期比如1小时后或者再次去Web界面手动执行一次发现规则。之后你会在“最新数据”里看到第四个监控项TCP Port 10086 is listening以及对应的触发器。监控体系已经自动扩展了6. 避坑指南与进阶思路走通了整个流程你已经掌握了Zabbix自动发现的核心操作。但在实际应用中可能会遇到一些坑。这里我分享几个常见的JSON格式错误这是最常遇到的问题。ports.json文件必须严格符合JSON语法。多一个逗号、少一个引号、括号不匹配都会导致发现失败。建议使用在线的JSON格式校验工具如 jsonlint.com来检查你的文件。脚本输出前也可以用python -m json.tool命令来验证。脚本权限问题Zabbix Agent通常以zabbix用户身份运行。确保/etc/zabbix/scripts/目录和里面的readPorts.sh脚本对zabbix用户至少有读取和执行权限rx。可以用sudo -u zabbix /etc/zabbix/scripts/readPorts.sh命令模拟运行来测试。键值不匹配Server端“发现规则”的“键值”、Agent配置文件里的UserParameter键名、以及你用zabbix_get测试时用的键名三者必须完全一致包括大小写。发现规则不生效检查主机是否正确链接了模板。检查发现规则的“更新间隔”是否设置得过长或者其“状态”是否是“已启用”。手动执行一次看看是否有错误日志在“报表”-“审计日志”里可以查看发现动作的执行记录。进阶思路我们本次用的是静态JSON文件这只是一个起点。真正的自动化在于动态生成这个JSON文件。你可以编写更强大的发现脚本例如发现所有监听端口写一个脚本解析ss -tlnp或netstat -tlnp命令的输出过滤出LISTEN状态的端口动态生成JSON。发现特定目录下的文件监控/var/log/下某个应用日志文件的大小自动发现所有以.log结尾的文件。发现磁盘分区使用df -h或lsblk -J命令自动发现所有挂载点并为其创建磁盘空间使用率的监控。其核心模式不变一个脚本输出标准JSON格式的发现数据 一个原型定义针对每个发现项如何监控和告警。掌握了这个模式你就能用Zabbix的自动发现功能去监控几乎任何可以列出清单的对象极大地解放你的运维生产力。下次当你需要为几十台服务器批量添加监控时再也不用愁眉苦脸了。