简介这是一套面向IT运维工程师与系统管理员的Zabbix监控系统快速部署工具专为解决多版本、多发行版环境下手动安装复杂、易出错的痛点而设计。资源支持Zabbix 6.0与7.0两大主流版本兼容CentOS 7/8/9、Rocky Linux 8/9及Ubuntu等主流Linux发行版显著降低跨平台部署门槛适用于数据中心、云环境及中小规模IT基础设施的监控落地场景。压缩包共21个文件含12个Shell脚本覆盖服务器端、Agent端、Docker部署及各发行版适配、2张环境示意图JPG/PNG、1份YAML配置用于Docker编排、1份详细说明文档TXT和1份扩展资源指南DOCX另有字体、补丁及Markdown说明文件总大小8.15MB。已有87人下载学习用户可直接调用对应发行版脚本一键完成数据库初始化、Zabbix Server/Proxy/Agent安装、Web界面配置及基础服务启动并借助附赠文档快速排查常见问题、导入预置模板或定制化调整大幅提升部署效率与可靠性。 搞运维的兄弟应该都有过这种经历接到需求要上一套Zabbix本来以为半天搞定结果从装数据库、调PHP、改前端配置到配防火墙、关SELinux、导入模板一套下来一整天就没了。要是碰上CentOS 7和Rocky 9这种底层服务管理方式完全不同的系统同样的步骤还得重新捋一遍。我前前后后手动部署过不下二十套Zabbix环境从5.0到6.0再到现在的7.0踩过的坑攒了一堆最后实在不想再重复劳动就写了一套自动化安装脚本。这套脚本支持Zabbix 6.0和7.0两个版本能在CentOS 7/8/9、RockyLinux 8/9、Ubuntu等主流发行版上跑基本做到“一条命令、喝杯茶、监控系统就绪”。这篇文章不光是介绍这个脚本怎么用更重要的是把脚本背后的设计思路、版本差异处理、生产环境落地时的注意事项都拆开讲清楚。如果你正打算在内部环境部署Zabbix或者想从6.0往7.0迁移又或者单纯想看看别人是怎么把这些琐碎步骤封装成自动化工具的这篇文章应该能给你一些参考。内容我尽量写得直白有可复现的步骤也有踩坑记录希望对你有用。1. 为什么我把“装一套Zabbix”变成了一道命令行的事先说说这个脚本是怎么来的。早些年我部署Zabbix全是手动操作当时觉得也没什么毕竟文档写得清楚照着敲就行。但后来公司环境多了测试环境、预生产、生产各一套每套系统的发行版还不一样有的是CentOS 7.9有的是RockyLinux 8后来还上了Ubuntu 22.04。手动部署的问题就暴露得很彻底操作步骤多、容易遗漏、不同系统之间命令还有差异更要命的是每次部署完都不记得上次是怎么处理某个报错的得重新翻历史命令或者上网查。1.1 手动部署Zabbix到底烦在哪里装一个完整的Zabbix Server表面上看就是装几个包、导个数据库、改个配置文件实际上牵扯的东西很多。我大概列一下手动部署的核心步骤安装Zabbix官方仓库不同发行版、不同大版本仓库地址和配置方式都不一样安装Server、前端、Agent组件Zabbix 6.0和7.0的依赖要求有明显差异安装并初始化数据库MySQL、MariaDB或PostgreSQL选一个初始化和字符集配置各有讲究修改Server配置文件数据库连接信息、监听端口、日志路径修改前端PHP配置时区这一项就够坑的忘记设置就报错给你看启动服务并设置开机自启6.0之后服务管理全部迁移到systemd但不同发行版的服务名有差异配置防火墙这个经常被忽略装完发现网页打不开回头补规则SELinux配置CentOS和Rocky上SELinux默认是Enforcing不处理好Agent数据提交不进来这些步骤单看都不难但组合起来就容易出问题。我之前测试过一次纯手动部署Zabbix 7.0全程录像加记录用了快两个小时。其中一半时间花在等待仓库刷新、依赖下载和数据库初始化上另外一半时间全在处理各种配置细节和报错。1.2 脚本要解决的核心问题我在写脚本之前先梳理了目标不求功能花哨重点解决几个问题部署过程必须无人值守。执行完命令之后不需要人盯着屏幕做交互选择所有参数要么自动检测要么通过命令行参数传入。多版本支持不能靠复制粘贴。Zabbix 6.0和7.0在PHP版本要求、前端目录结构、默认配置项上有差异脚本需要能够根据版本号自动调整逻辑。多发行版兼容不能写死命令。CentOS 7用的是yum和systemd的部分兼容模式RockyLinux 8/9用dnfUbuntu用apt服务管理细节也有差别脚本必须有分支处理。出错要能定位。自动化脚本最怕的就是失败了不知道原因,所以我加了日志输出和关键步骤的退出码校验。实际用下来这套脚本在干净的CentOS 7.9、RockyLinux 9.3、Ubuntu 22.04上都测试过从执行到Web界面可访问最快的一套RockyLinux 9 MariaDB Zabbix 7.0大概用了8分钟大部分时间花在下载依赖包上。这比我手动部署节省了至少70%的时间。2. 脚本的分层设计版本、发行版和数据库如何解耦脚本的总体设计其实没有多高深核心思想就一句话把“公共流程”和“差异化部分”分开。部署Zabbix的流程是固定的装仓库、装软件包、初始化数据库、配置Server、配置前端、启动服务。但每一步在不同发行版、不同版本上的具体命令和配置内容都不一样所以脚本做成了分层结构。2.1 函数库每个发行版一个配置文件我没有把所有逻辑写在一个大脚本里而是拆成了几个文件。主脚本负责调度流程函数库里放着通用的安装函数发行版相关的变量和特殊处理放在各自的配置脚本里。以CentOS 7和RockyLinux 9为例两者包管理器不同yum对比dnfPHP-FPM的服务名和配置目录不同CentOS 7是php-fpmRockyLinux 8/9集成在zabbix-web服务里时区设置方式也不同。如果把这些差异全部用if else堆在一个文件里脚本会变得非常难维护而且容易出错。我选择在脚本开头做一次系统检测然后引入对应的发行版配置模块后续所有操作都通过统一的函数接口调用。核心检测代码大致是这个思路detect_os() { if [ -f /etc/redhat-release ]; then if grep -q CentOS Linux release 7 /etc/redhat-release; then OS_FAMILYcentos OS_VERSION7 elif grep -q Rocky Linux /etc/redhat-release; then OS_FAMILYrocky OS_VERSION$(grep -oP (?release )\d /etc/redhat-release) fi elif [ -f /etc/os-release ]; then . /etc/os-release if [ $ID ubuntu ]; then OS_FAMILYubuntu OS_VERSION$VERSION_ID fi fi }这个检测放在脚本最前面一旦识别失败就立即退出并提示手动指定发行版类型避免后续误操作。2.2 Zabbix 6.0和7.0的差异是怎么处理的Zabbix 6.0和7.0看起来差别不大实际上安装配置的差异点还是有的而且不少是“平时注意不到部署的时候才炸出来”的类型。我整理了一个对照表脚本里的很多判断逻辑就是围绕这些差异展开的差异项Zabbix 6.0 LTSZabbix 7.0 LTSPHP最低版本要求PHP 7.2前端对版本要求相对宽松PHP 8.0以上前端有硬性版本校验前端默认登录方式用户名密码登录支持用户名密码、SSO、API Token默认强化了会话管理Agent默认协议端口10050/TCP10051/TCP不变但在配置加密上支持度更好数据库初始化脚本schema.sql images.sql data.sql 分开导入合并后的schema.sql同时还要导入double.sql升级脚本Web服务器配置Apache配置在 /etc/httpd/conf.d/zabbix.conf配置结构相似但PHP-FPM socket路径在不同发行版上有变化官方仓库命名规则仓库包名类似 zabbix-release-6.0-4.el9.noarch.rpm仓库包名类似 zabbix-release-7.0-2.el9.noarch.rpm脚本里对版本的处理很简单定义一个全局变量ZBX_VER所有需要区分流程的地方都通过条件判断。比如数据库导入部分6.0走的是三条SQL依次导入7.0走的是先导入schema.sql再导入double.sql。前端配置部分7.0对php版本检查更严格所以脚本会在配置生成前先确认PHP版本是否满足要求不满足就直接报错而不是等到Web界面打开后才提示。说实话这个版本差异处理逻辑不算复杂但确实把我在6.0升级到7.0过程中遇到的绝大部分问题都覆盖了。3. 适配CentOS 7/8/9、Rocky 8/9、Ubuntu时的差异处理这一节是我最想详细写的部分。很多人以为自动化脚本就是“把文档里的命令一行行写好然后bash执行就完事”实际做起来完全不是那么回事。不同发行版之间的差异极其琐碎每一个差异都可能让脚本在中途崩溃。我遇到的几个比较典型的坑单独拿出来说说。3.1 CentOS 7的“远古”遗留问题CentOS 7虽然已经停止维护了但存量环境依然很多很多企业内部服务器还在跑着它。它的特殊之处在于默认的python版本是2.7有些自动化辅助工具可能依赖python3需要额外安装systemd虽然已经使用但部分服务脚本还是老式SysV风格服务管理命令的兼容性有差异默认的PHP版本是5.4Zabbix 6.0要求PHP 7.2以上Zabbix 7.0要求更高所以必须启用EPEL或Zabbix官方源的PHP模块仓库源如果没更新安装过程中会报大量的依赖缺失错误脚本在处理CentOS 7时第一步就是安装EPEL仓库然后从Zabbix官方源安装对应的PHP模块。CentOS 7上Zabbix 6.0安装时还需要注意zabbix-web包和zabbix-web-mysql包必须同时安装单独装一个会导致前端页面打不开。3.2 RockyLinux 8/9上的PHP-FPM服务差异RockyLinux 8和9是同一条技术线但细节上还是有差别。RockyLinux 8自带PHP 7.2满足Zabbix 6.0的要求但装Zabbix 7.0时就需要启用模块流切换到PHP 8.0以上。RockyLinux 9默认PHP是8.0反而更适合Zabbix 7.0但如果装的是6.0版本也要确认前端兼容性。RockyLinux 8/9上Zabbix前端默认跑在Apache PHP-FPM模式下和CentOS 7的mod_php模式不同。CentOS 7修改时区直接在/etc/php.ini里改date.timezoneRockyLinux 8/9有时需要修改/etc/php-fpm.d/zabbix.conf这个文件里的php_value[date.timezone]配置位置不一样我最初写脚本时就在这上面翻过车。3.3 Ubuntu上最容易踩的坑Ubuntu系列和RHEL系完全两套逻辑。包管理器是apt仓库配置通过/etc/apt/sources.list.d/下的文件管理服务管理用的是systemctl但服务名和RHEL系有差异。Ubuntu上部署Zabbix时有几个坑比较突出官方仓库的添加方式不同需要先下载.deb包装仓库再用dpkg -i安装然后执行apt-get updateApache的默认网站目录在/var/www/html但Zabbix前端文件通常会装到/usr/share/zabbix需要确认Apache配置里有正确的Alias配置Ubuntu的PHP-FPM默认监听的是/run/php/php8.1-fpm.sock和Zabbix前端配置里的socket路径必须一致不一致就白屏Ubuntu默认可能没有安装ufw防火墙规则但有些环境开了ufw需要在脚本里检测并放行端口3.4 数据库选择上的取舍脚本支持MySQL、MariaDB和PostgreSQL三种数据库。RHEL系系统我推荐MariaDB因为它是yum/dnf源里默认带而且兼容性最好的选择Ubuntu上默认的mysql-server包也还行但如果选了PostgreSQL前端PHP需要额外安装php-pgsql扩展脚本需要多一层判断。数据库相关的配置我统一用参数传给脚本比如./install_zabbix.sh --version 7.0 --db-type mysql --db-password YourPassword --server-name Zabbix-Server数据库密码如果不在命令行传脚本会尝试从环境变量中读取或者使用随机生成并写到/etc/zabbix/db_credentials.conf文件里。这个文件权限要设置为600避免密码泄露。实际部署里我一般推荐随机生成密码因为人工输入的密码强度通常很感人。4. 完整部署一次Zabbix 7.0 LTS参数、步骤与验证说了这么多设计思路现在实打实走一遍完整流程。我在一台全新的RockyLinux 9.3虚拟机上进行测试这台机器是标准的最小化安装连开发工具都没装。部署目标是Zabbix Server 7.0 LTS MariaDB Apache前端同时安装Zabbix Agent用于监控本机。4.1 执行前需要准备什么在生产环境跑自动化脚本之前有几个前置条件必须确认服务器能正常访问互联网至少能访问Zabbix官方仓库和系统软件源内网环境可以先把相关rpm/deb包和依赖拷贝到本机但脚本目前针对在线安装场景防火墙策略确认好Zabbix Server需要开放10051/TCPServer与Agent通信前端Web需要开放80或443端口服务器时间同步正常时间偏差太大会导致Agent上报数据时间错乱这个不完全是脚本能处理的问题磁盘空间建议至少20GBZabbix的数据库会持续增长虽然安装时用不了多少但要预留余量4.2 实际执行步骤脚本下载并解压后目录结构大概是这样的zabbix-autoinstall/ ├── install.sh # 主入口脚本 ├── conf/ │ ├── centos7.conf # CentOS 7专用变量 │ ├── rocky8.conf # RockyLinux 8专用变量 │ ├── rocky9.conf # RockyLinux 9专用变量 │ ├── ubuntu2204.conf # Ubuntu 22.04专用变量 │ └── common.sh # 通用函数库 └── templates/ ├── zabbix_server.conf.j2 ├── zabbix_agentd.conf.j2 └── zabbix_web.conf.j2主入口支持参数解析最简单的用法是chmod x install.sh ./install.sh --version 7.0 --db-type mariadb --db-password Secret12345脚本执行流程检测操作系统类型和版本加载对应的发行版配置配置Zabbix官方仓库源安装Zabbix Server、前端、Agent软件包配置数据库启动数据库服务、创建Zabbix数据库和用户、导入初始表修改Server配置文件/etc/zabbix/zabbix_server.conf中的DB连接参数配置前端写入Apache配置文件、设置时区、调整PHP参数启动Zabbix Server、Agent、Web服务并设置开机自启输出部署摘要Web入口地址、管理员账号、随机生成的数据库密码位置执行过程中屏幕上会输出每个阶段的INFO、WARN、ERROR日志失败时脚本会自动定位到日志目录/var/log/zabbix-install/下的安装日志方便排查。4.3 部署完成后的验证指标脚本执行完不是就万事大吉了我会按以下顺序验证部署是否正常Web界面登录访问http://服务器IP/zabbix首次打开会进入设置向导用管理员账号Admin密码zabbix登录首次登录后建议立即修改检查Zabbix Server进程状态执行systemctl status zabbix-server应显示active (running)检查Agent进程状态执行systemctl status zabbix-agent应显示active (running)查看Agent日志tail -f /var/log/zabbix/zabbix_agentd.log里应能看到active checks相关日志说明Server与Agent通信正常在Web界面的Monitoring - Latest Data里能看到本机Agent上报的CPU、内存、磁盘等指标数据有一点要提醒Zabbix 7.0首次登录后Web界面会有一个比较长的初始配置检查页面它会列出所有不满足的PHP环境项。如果之前脚本的PHP配置处理正确这个页面应该只有个别warning级别的提示不会有error。5. 生产环境里比“装完”更重要的几件事部署脚本只是第一步真正让监控系统跑得稳、跑得久后面的配置才是重头戏。很多人在测试环境里装完Zabbix觉得一切正常一上生产就各种莫名其妙的问题。下面这几件事是我在实际运维中总结出来的比安装过程更容易踩坑。5.1 时区问题前端永远显示错误时间这是Zabbix部署中最常见的问题之一而且很容易被忽视。如果你不设置PHP的时区Zabbix前端会默认使用UTC时间你看到的监控数据和实际时间整整差8个小时。虽然这不影响数据采集但排查问题时非常痛苦。脚本里对时区的处理是自动读取系统时区从/etc/timezone或timedatectl获取将时区写入前端PHP配置中的date.timezone参数同时确认数据库连接字符串里带了charsetutf8mb4避免中文乱码一个很容易被忽略的关联点修改完PHP时区之后必须重启Apache或PHP-FPM服务才能生效。我见过很多人在配置文件里改了时区但忘记重启服务然后花了半小时怀疑配置文件写法有问题。脚本在写完配置后会统一重启所有相关服务这个顺序一定不能乱。5.2 SELinux和防火墙装好但连不上的头号元凶在CentOS和Rocky上SELinux默认是Enforcing状态。很多Zabbix部署故障的根源就在这里Server进程装好了、服务也起来了Agent数据就是进不来Web界面上主机显示红色不可达。用getenforce一看Enforcing然后ausearch -m avc能查到一堆被拒绝的访问记录。脚本内部的处理方式是开放Zabbix所需的标准端口策略而不是简单粗暴地关掉SELinuxsetsebool -P zabbix_can_network 1 semanage port -a -t http_port_t -p tcp 80 2/dev/null || true但这里要提醒如果服务器本身安全策略比较严格比如金融、政务环境在跑脚本前要先和负责安全的人员确认SELinux策略变更是否被允许。脚本默认会尝试放行必要端口但如果确实有安全合规要求可以加--skip-selinux参数跳过然后通过手工配置策略实现。防火墙方面CentOS 7默认用的是firewalldUbuntu默认是ufw有时未激活。脚本会检测防火墙状态如果是active就添加10050/TCP、10051/TCP以及Web端口规则。注意如果你用的是云主机还需要在云安全组里放行这些端口这是脚本管不到的。5.3 数据库性能与时区关联的初始化细节Zabbix的数据量增长非常快特别是在有大量历史数据保留需求时。默认情况下Zabbix 7.0会在数据库里创建一套分区表保存历史数据但在安装阶段数据库的初始字符集和排序规则必须设置对否则后期会出现数据写入错误。脚本在创建数据库时强制指定CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;为什么要用utf8mb4_bin因为Zabbix官方要求这个排序规则它区分大小写并且能存储完整的Unicode字符。如果用了默认的utf8mb4_general_ci某些特殊字符可能出现存储异常而且后期如果要迁移数据库也会遇到兼容性问题。另外Zabbix 7.0相比6.0在数据库初始化时增加了double.sql这个脚本它的作用是处理从旧版本升级时可能出现的数据冲突。全新安装时也需要导入它否则某个系统表会缺少必要的索引。我最初测试时跳过这个脚本结果后来在执行一些历史数据清理任务时频繁报错追查了很久才发现是初始化不完整导致的。5.4 Agent的部署没跟上脚本默认会在Server本机安装Agent用于监控Zabbix Server自身。但实际环境里我们还需要监控大量业务服务器这批机器的Agent部署也需要自动化。我的做法是在脚本目录下额外写了一个install_agent.sh可以独立分发到被监控机器上执行。安装Agent时只需要指定Server地址和主机名./install_agent.sh --server 192.168.100.10 --hostname web-01Agent安装的关键点Agent版本尽量和Server一致或接近避免协议不兼容Zabbix 7.0的Agent可以兼容6.0的Server但有些新特性用不了配置文件/etc/zabbix/zabbix_agentd.conf里Server参数填Zabbix Server的IPServerActive也填相同地址这样才能支持主动模式监控如果开启了被动模式防火墙要放行10050端口如果只用主动模式防火墙可以只放行10051Agent不用开放端口Agent端配置完要执行systemctl restart zabbix-agent验证服务状态5.5 Web前端的初始配置向导Zabbix 7.0的Web界面首次打开时会进入配置向导这个向导会自动检测PHP环境、数据库连接等。很多时候脚本安装完成但Web向导的最后一两步会失败原因千奇百怪最常见的是数据库连接信息不匹配。遇到这种情况按这个顺序排查检查/etc/zabbix/web/zabbix.conf.php文件是否存在且内容正确确认数据库账号密码和向导里填写的一致检查/var/log/php-fpm/error.log里有没有连接错误确认Zabbix Server进程状态正常systemctl status zabbix-server脚本生成的zabbix.conf.php文件内容大致如下?php $DB[TYPE] MYSQL; $DB[SERVER] localhost; $DB[PORT] 3306; $DB[DATABASE] zabbix; $DB[USER] zabbix; $DB[PASSWORD] YourGeneratedPassword; $DB[SCHEMA] ; $DB[CHARSET] utf8mb4; ?注意PHP的短标签问题有些发行版默认关闭short_open_tag如果?php写成了?会导致页面直接白屏。脚本里统一用完整标签避免这个坑。6. 脚本还能怎么长Agent自动注册、API和模板管理自动化安装脚本的价值不应该停留在“装完一个Server”这个层面。Zabbix的日常运维里主机接入、模板管理、告警配置才是持续性工作。如果你已经通过脚本快速部署好了Zabbix我建议继续把下面这几件事也自动化起来。6.1 用自动注册规则替代手动加主机手动在Zabbix Web界面上添加主机一台两台还可以几十台的时候就非常痛苦。Zabbix原生支持Agent的自动注册功能配置好后新安装的Agent只要上报心跳Zabbix Server会自动把它纳入监控按模板分组并应用对应监控项。自动注册的配置路径是Configuration - Actions - Auto registration。创建一个规则条件可以按元数据Metadata区分比如Linux服务器填linux-prodWindows服务器填win-prod然后在动作里根据元数据不同应用不同的模板。Agent端需要在zabbix_agentd.conf里配置ServerActive192.168.100.10 Hostnameweb-01 HostMetadatalinux-prod这个功能用好了新机器从交付到纳入监控可以做到全自动不需要任何人登录Zabbix界面操作。6.2 通过API批量纳管和历史数据查询Zabbix提供了一个功能完备的API支持批量创建主机、批量更新模板、查询监控数据、管理告警。脚本装好Zabbix之后我就建议优先把API接入自己的运维平台或者脚本库。一个简单的API认证请求Zabbix 7.0推荐用API Token方式curl -s -X POST http://127.0.0.1/zabbix/api_jsonrpc.php \ -H Content-Type: application/json-rpc \ -d { jsonrpc: 2.0, method: token.create, params: { name: deploy-token, userid: 1 }, id: 1, auth: 你的已有token }拿到Token之后批量创建主机的接口调用就很容易拼接了。我之前的文章里详细记录过如何通过Zabbix API批量获取监控数据原理就是用history.get接口按时间范围拉取指标值然后转成CSV或者接入自研展示面板。这里就不再赘述只强调一点7.0的API完全支持Token认证不再强制依赖用户密码登录这让脚本调用安全很多。6.3 模板的版本化管理和导入导出Zabbix模板实际上是一堆监控项、触发器、图形、仪表盘的集合。我们经常需要把一套环境的模板迁移到另一套环境以前的做法是导出XML文件再导入操作繁琐且容易漏。现在Zabbix 7.0的模板导入导出功能更完善了支持在界面直接导入导出也支持通过API操作。我的建议是建立一个模板仓库把企业内部定制的模板统一放到Git或其他版本控制工具里管理。每次模板变更走评审流程然后用脚本调用API自动导入到测试环境验证验证通过后再导入生产环境。这个流程初期会有点工作量但一旦跑顺你会发现模板变更再也不是“某个大佬手工改一下”的黑盒操作了。6.4 定时备份Zabbix数据库和配置文件自动化部署的最后一口“保险”就是自动化备份。Zabbix的所有配置数据都在数据库里历史监控数据虽然可以通过TimescaleDB或分区表做压缩和保留策略但备份依然不能少。脚本模板里我放了一个backup_zabbix.sh的参考脚本主要做两件事使用mysqldump对zabbix库进行逻辑备份注意加上--single-transaction避免锁表备份/etc/zabbix/目录下的所有配置文件备份策略建议数据库每天全量备份保留7天配置文件每次变更后手动执行一次备份。备份文件最好存到独立目录或者对象存储不要和数据库放在同一块磁盘上。真遇到磁盘损坏至少还有一份异地或不同物理位置的备份可以恢复。最后的实操建议从脚本到标准化运维这套Zabbix自动化安装脚本用到现在我最大的体会不是“装得快”而是它逼着我把安装过程中的每一个步骤、每一个参数、每一个坑都整理成了文档化的逻辑。当一个人用脚本替代手工操作后他的注意力就从“怎么把命令敲对”转移到了“这个配置为什么这样写、这个参数为什么这样调”后者对运维能力的提升远比前者重要得多。如果你准备在生产环境使用这类脚本我最后有几点建议不要直接拿脚本去生产实验先在一台干净的虚拟机或容器环境完整跑一遍确认你理解每一个步骤在干什么留意你所用Linux发行版的生命周期CentOS 7已经停止维护CentOS 8也早已EOL新环境建议优先选RockyLinux 9或Ubuntu 22.04/24.04数据库密码、Web登录密码这些敏感信息脚本只是生成到本地文件生产环境建议接入公司的密钥管理系统脚本跑的再顺监控系统的稳定性最终还是取决于你对Zabbix本身原理的理解。自动化工具是手段不是目的。以后这个脚本我还会继续更新比如支持基于Podman/容器的Zabbix部署方式、支持TimescaleDB作为历史数据存储、增加更细粒度的告警通道配置。监控系统是一条长路安装部署只是第一天后续的路还长着呢。本文还有配套的精品资源点击获取