CentOS 7 上 Zabbix 6.4 部署实战：从环境准备到自定义监控与告警

1. 为什么我把 Zabbix 6.4 定为 CentOS 7 集群的监控主力

先说个背景。今年我手头维护了一批 CentOS 7 的服务器，有物理机也有云主机，数量不算夸张，但挨个登上去看磁盘、看 CPU、看内存，已经明显不现实了。最怕的是半夜收到业务方的消息说“某台机器挂了”，等我跳上去查的时候，日志早就被新一轮刷掉了。与其事后翻案，不如事前盯住。所以决定把监控系统搭起来。

在选型时，我并不是没考虑过其他开源方案。我对这套监控系统的诉求很具体：要有“阈值判断后自动通知”的能力，最好能按团队分工配置不同的通知接收人；要有历史数据留存，复盘故障时能翻出 10 天前的 CPU 曲线；要支持自定义监控项，不能只盯着系统层面的指标。Zabbix 正好把这几件事都做在了一套体系里，而且它能直接跑在 CentOS 7 的存量环境上，不需要端掉旧业务重来。

我选用 Zabbix 6.4 的另一个原因是它的前端交互比早期版本顺手不少。仪表盘可以自由拖拽，主机模板集成度也高，Linux 主机接进来之后，CPU、内存、磁盘、网络等常用指标几乎不用手工维护。对运维团队来说，少一个“手工造轮子”的环节，就少一个出错的可能。

这篇指南覆盖的步骤包括：CentOS 7 环境准备、Zabbix Server 与数据库安装、前端页面部署、Agent 端接入、自定义触发器、邮件通知、性能调优以及实际踩坑记录。无论你之前用的是哪种监控方案，只要机器是 CentOS 7，下面这些命令和配置基本可以照着抄。

2. 环境准备：先把那些“看起来不重要”的事做掉

2.1 系统版本与网络规划

先确认系统版本，避免后面软件源选择出错：

cat /etc/redhat-release uname -a

我这边统一是 CentOS Linux release 7.9.2009。Zabbix 6.4 官方对 CentOS 7 有对应的 RPM 仓库，不需要自己编译，这点省事很多。

网络规划上，需要确定 Zabbix Server、被监控主机的 IP 段和端口。Server 端默认监听 10051，Agent 端默认监听 10050。如果你的机器在公有云上，安全组要放行这两个端口；如果在内网机房，也要确认防火墙规则。我的习惯是：

• 内网采集端口不暴露公网，能走内网走内网
• Web 管理端访问尽量限制来源 IP
• Agent 通信使用 PSK 预共享密钥加密（后文会专门讲）

2.2 防火墙与 SELinux 的处理

CentOS 7 默认开启 firewalld，也允许 SELinux。如果直接安装 Zabbix，很容易出现“服务起来了，页面打不开”的情况，最后排查半天发现是 SELinux 阻塞了 Nginx。这里我给两种选择：

如果你内网安全要求没那么苛刻，可以先把 SELinux 设为宽容模式：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

我个人不推荐直接禁用 SELinux，但在 Zabbix 这套场景下，默认策略对 Nginx、PHP-FPM 的目录权限限制确实容易卡住新手。如果你坚持开启 SELinux，那需要额外配置 httpd_can_network_connect 等布尔值，比较繁琐。

防火墙放行端口：

firewall-cmd --permanent --add-port=10051/tcp firewall-cmd --permanent --add-port=10050/tcp firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload

2.3 时间同步

监控系统最怕的就是时钟不一致。Zabbix Server 判断主机是否“存活”靠的是心跳数据更新，如果 Agent 所在机器的时间比 Server 慢了五分钟，你会看到主机状态一直在“未监控”和“可用”之间横跳，实际上业务没任何问题。

必须配置 NTP 同步，CentOS 7 默认可能是 chrony：

yum install -y chrony systemctl enable chronyd systemctl start chronyd chronyc sources -v

确保显示能够从时间源拉取偏移。如果你在内网，没有公网 NTP 权限，至少要搭一个内网时间源，别让各台机器各跑各的。

3. 安装 Zabbix Server 与数据库：6.4 版本的依赖坑

3.1 配置 Zabbix 官方软件源

Zabbix 6.4 需要 PHP 7.2 以上，而 CentOS 7 默认源里只有 PHP 5.4。如果直接yum install zabbix-server-mysql，很可能装了一堆旧依赖后，Web 前端直接报“PHP 版本过低”。正确姿势是先装 Zabbix 仓库，再用 Remi 仓库升级 PHP。

rpm -Uvh https://repo.zabbix.com/zabbix/6.4/rhel/7/x86_64/zabbix-release-6.4-1.el7.noarch.rpm yum clean all

再装 Remi 仓库：

yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm yum install -y yum-utils yum-config-manager --enable remi-php81

我这里选择了 PHP 8.1，搭配 Zabbix 6.4 前端完全没有问题。如果你之前装过其他版本的 PHP，建议先确认版本冲突：

php -v

如果有残留的 PHP 5.4 包，先清理干净再继续。

3.2 安装 Server、前端、Agent

接下来一条命令把核心组件都装上去：

yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-agent2 zabbix-nginx-conf zabbix-sql-scripts

这里我装了 Agent2，它比传统 Agent 在原生的指标采集上更丰富，比如对 PostgreSQL、Redis、MongoDB 都有内置的监控项。如果只监控 Linux 系统指标，装传统zabbix-agent也够用。我先在这台 Server 上也装了 Agent2，用来监控 Zabbix 自己，这叫“监控者先被监控”。

为了后面排查硬件层面的告警，建议顺便装：

yum install -y OpenIPMI-libs ipmitool

如果被监控的服务器上还有 Windows 机器，会需要额外的 exporter 或 Agent，这块不在本文范围，但可以先留个印象：Zabbix 对跨平台的支持比想象中好。

3.3 初始化 MariaDB 数据库

CentOS 7 默认源里的数据库是 MariaDB 5.5。如果数据量不大，跑 Zabbix 够用；但如果你打算留存大量历史数据，建议用 MariaDB 10.5 的第三方源或者干脆装官方二进制。我这里先按默认 MariaDB 走：

yum install -y mariadb-server systemctl enable mariadb systemctl start mariadb mysql_secure_installation

初始化数据库时，顺手把 root 密码设置好。然后创建 Zabbix 的库和账号：

mysql -uroot -p CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'YourStrongPassword'; CREATE USER 'zabbix'@'127.0.0.1' IDENTIFIED BY 'YourStrongPassword'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'127.0.0.1'; FLUSH PRIVILEGES; QUIT

用户名和密码别学我写固定串，生产环境请用强随机密码。数据库字符集用utf8mb4是因为 Zabbix 6.4 支持在告警消息和主机名称里写多语言字符，如果沿用老旧的 UTF8 字符集，遇到某些特殊字符会插入失败。

导入初始数据：

zcat /usr/share/doc/zabbix-sql-scripts/mysql/server.sql.gz | mysql -uzabbix -p zabbix

注意，不同的 Zabbix 小版本中 SQL 脚本的路径可能略有差异。如果zcat找不到文件，去/usr/share/doc/zabbix-sql-scripts/mysql/目录下看一眼实际文件名。导入过程会持续十几秒到几分钟，取决于服务器的磁盘性能。

3.4 修改 Server 配置文件

编辑/etc/zabbix/zabbix_server.conf，重点修改下面几项：

DBHost=127.0.0.1 DBName=zabbix DBUser=zabbix DBPassword=YourStrongPassword CacheSize=128M HistoryCacheSize=64M TrendCacheSize=64M

前面的 DB 参数是基础必填项，后面的三个 Cache 参数是根据我实际监控 100 台左右主机的经验调整的。Zabbix Server 运行时会频繁读写内存缓存，默认值偏保守，如果监控规模稍微上来一点，很容易在日志里看到 “history cache has X% free” 这类告警，意思是历史数据缓存快写满了，需要调大。

改完启动：

systemctl enable zabbix-server systemctl start zabbix-server

3.5 一个容易忽略的时区设置

Zabbix 前端对 PHP 时区有硬性要求。如果你启动 Server 后打开页面时报“PHP time zone needs to be set”之类的错误，去改/etc/php-fpm.d/zabbix.conf：

php_value[date.timezone] = Asia/Shanghai

顺手确认内存限制、上传大小等参数：

php_value[max_execution_time] = 300 php_value[memory_limit] = 256M php_value[post_max_size] = 16M php_value[upload_max_filesize] = 2M

这个文件的注释模板是按 Debian 系的路径写的，CentOS 下实际由 RPM 包装到了对应目录，多看一眼实际路径就不容易踩坑。

4. Web 前端部署：Nginx + PHP-FPM 踩坑实录

4.1 为什么不用自带的 Apache

Zabbix RPM 包默认可以配 Apache，但我个人不推荐在存量 CentOS 7 上为了 Zabbix 单开一套 Apache。内网服务器往往还跑着别的业务，端口冲突和内存占用都是成本。改用 Nginx 更轻量，而且 Zabbix 官方仓库里直接提供了 Nginx 的参考配置。

安装 Nginx：

yum install -y nginx

修改/etc/nginx/conf.d/zabbix.conf，参考如下配置：

server { listen 80; server_name zabbix.example.com; root /usr/share/zabbix; index index.php; access_log /var/log/nginx/zabbix_access.log; error_log /var/log/nginx/zabbix_error.log; location / { try_files $uri $uri/ =404; } location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

如果你已经部署了 HTTPS，就把 443 的证书配置加进来。Zabbix 管理端建议至少绑一个域名，配合证书访问，不然内网裸 HTTP 下密码是明文传输。

4.2 我记得的前端 502 问题

Nginx 配置好后，启动服务大概率遇到两种现象：页面 502，或者页面是纯文字没有样式。

502 的通常原因：PHP-FPM 没起来，或者 socket 路径不对。排查方法：

systemctl status php-fpm ls -l /run/php-fpm/www.sock

如果 socket 文件存在，但 Nginx 没有权限访问，常见原因是 php-fpm 的listen.owner和listen.group与 Nginx 进程用户不一致。在/etc/php-fpm.d/www.conf里调整：

listen.owner = nginx listen.group = nginx listen.mode = 0660

页面没有样式的原因通常是 Nginx 的location规则没有正确匹配静态文件，导致 CSS、JS 请求全部被丢给 PHP 解析。上面配置里第一段try_files $uri $uri/ =404;就是把静态文件直接交给文件系统处理，避免这个坑。

设置 PHP-FPM 的 session 目录权限，否则登录页面会出现“session start failed”：

mkdir -p /var/lib/php/session chown -R nginx:nginx /var/lib/php/session

4.3 完成前端安装向导

浏览器访问 Zabbix 的地址，进入安装向导。这里有一项“Zabbix server details”，需要填 Server 的 IP 或主机名和端口 10051。如果 Server 和 Web 装在同一台机器，直接填 127.0.0.1 或 localhost 都行。

前端到“Write configuration file”这一步时，它会要求把配置文件保存到/etc/zabbix/web/zabbix.conf.php。如果目录权限不够，可以在服务器上手动写入向导给出的内容，然后再次点击下一步。

安装完成后用默认账号Admin/zabbix登录，第一件事是修改密码，第二件事是改语言为中文。Zabbix 6.4 的中文翻译整体质量已经不错，但有些模板描述还是英文，别被吓到。

5. 把 CentOS 7 主机接入监控：Agent 安装与主动/被动采集

5.1 安装 Agent 并配置 Server 地址

在被监控主机上执行：

rpm -Uvh https://repo.zabbix.com/zabbix/6.4/rhel/7/x86_64/zabbix-release-6.4-1.el7.noarch.rpm yum install -y zabbix-agent2

编辑/etc/zabbix/zabbix_agent2.conf：

Server=192.168.10.10 ServerActive=192.168.10.10 Hostname=web-01

• Server字段允许来自这段 IP 的被动采集请求，也就是 Zabbix Server 从 Agent 拉取数据。
• ServerActive是主动采集，Agent 主动连接到 Server 的 10051 端口，把指标推过去。

两种模式各有适用场景。机器数量少、网络简单的时候，用被动采集足够。移动端、跨机房、防火墙策略复杂的环境，主动采集会更可靠，因为它不需要对 Agent 开入站端口。

生产上我习惯同时开两种，前端选模板时用默认的“Zabbix agent active”或“Zabbix agent”模板都能兼容。

5.2 PSK 加密配置

Zabbix 支持预共享密钥加密 Agent 通信，这个强烈建议开启。先在 Server 端生成一个 PSK：

openssl rand -hex 32 > /etc/zabbix/zabbix_server.psk chmod 640 /etc/zabbix/zabbix_server.psk chown root:zabbix /etc/zabbix/zabbix_server.psk

在 Agent 端也放同一个文件，并在配置里打开：

TLSConnect=psk TLSAccept=psk TLSPSKIdentity=psk_client_01 TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

注意 Server 端也必须在/etc/zabbix/zabbix_server.conf里设置：

TLSCAFile= TLSConnect=psk TLSAccept=psk

前端页面的主机配置里，填好对应的“PSK identity”和“PSK”的值。如果你省略了这步，默认走明文通信，内网抓包可以直接看到监控指标，对很多业务来说是不能接受的。

5.3 Web 界面添加主机

登录 Zabbix 前端，依次点“数据采集 > 主机 > 创建主机”。需要填：

• 主机名称：建议与 Hostname 字段一致
• 可见名称：可以写中文备注，比如“Web-01-北京”
• 群组：选择一个项目组
• 接口：Agent 的 IP 和端口 10050

然后切到“模板”页签，搜索Linux by Zabbix agent，添加进去。这个模板里已经预置了 CPU、内存、磁盘、网络、系统服务等几十个监控项和对应的触发器。保存之后，等待 1-2 个刷新周期，你应该能在“监控 > 主机”里看到新主机和绿色心跳。

如果一直显示“没有数据”，优先排查两部分：一是网络连通性（telnet 192.168.10.10 10050），二是 Agent 配置里的Server是否写对了。曾经有同事把Server和ServerActive混为一谈，结果被动采集完全不通。

6. 自定义监控项与告警触发器：别只盯着默认模板

6.1 通过 UserParameter 自定义键值

模板只能监控通用指标，实际业务里你往往会关心“某个进程是否存活”“某个日志文件是否还在增长”“某个端口是否响应”。Zabbix 的UserParameter就是在 Agent 端自定义一个键值，把脚本输出交给 Zabbix 处理。

举个例子，监控 Nginx 进程数量：

vim /etc/zabbix/zabbix_agent2.d/user_parameter_nginx.conf

写入：

UserParameter=nginx.process.count,pgrep -f "nginx: master" | wc -l

改完重启 Agent：

systemctl restart zabbix-agent2

然后在 Web 端给这个主机创建一个监控项：

• 名称：Nginx 进程数
• 类型：Zabbix 客户端（被动）
• 键值：nginx.process.count
• 信息类型：数值
• 更新间隔：30s

这里有个小技巧：自定义键值可以在 Service 端先测试一下能不能取到数据。点击监控项目列表里的“测试”，填入nginx.process.count，会直接连 Agent 返回结果。如果返回“Not supported”，去 Agent 日志里找报错，多半是脚本本身输出格式不对。

6.2 写一个有实用价值的触发器

只有监控项没有触发器，等于只记录不报警。触发器的作用是判断“现在这个数值是否已经超出容忍范围”。

比如磁盘使用率超过 90% 就触发告警，表达式可以写成：

last(/web-01/vfs.fs.size[/used,pfree]) < 10

注意 Zabbix 6.4 的表达式函数名，这里vfs.fs.size[/used,pfree]返回的是磁盘剩余百分比，小于 10 意味着使用率超过 90%。

我习惯把触发器的告警级别分为三级：

级别	示例	处理时效
信息	CPU 单核负载短暂飙高	汇总观察
警告	磁盘使用率 85%	白天处理
严重	磁盘使用率 92%	立即处理

别一上来就把触发器阈值写得太敏感。之前我给 MySQL 主从延迟设置的告警阈值是 10 秒，结果每天都收到几十封告警邮件，团队后来直接无视了。告警的初衷是“在故障前留出处置时间”，不是制造噪音。建议先用观察期数据调整阈值，再切换到正式告警。

6.3 触发器依赖关系

如果一台服务器的磁盘挂载点和进程是强关联关系，触发器之间要配置依赖。比如“nginx 进程挂了”这个触发器，可以依赖“主机 agent 心跳丢失”这个触发器，避免主机宕机时重复发一堆告警。

在触发器配置页的“依赖”里选择父触发器即可。这个细节平时没人提，但碰上大面积故障时特别有用，不然每个监控项都会发一条告警，接收人手机瞬间被打爆。

7. 告警通知：从邮件到企业微信机器人

7.1 配置邮件通知

Zabbix 自带的邮件通知使用 SMTP 协议。前端点击“用户设置 > 媒介类型 > Email”，配置 SMTP 服务器、端口、发件人账号密码。如果使用企业邮箱，很多还需要开启客户端授权码，不能直接填登录密码。

配置完成后，需要给用户分配媒介：

• 用户设置 > 用户 > 报警媒介
• 添加一个 Email 类型的媒介，填写接收邮箱
• 确认“启用”状态，并设置告警时间段

很多新手配了邮件媒介却收不到信，多半漏了“动作”这步。Zabbix 的通知逻辑是：必须创建一个动作，把“触发器事件”和“媒介”关联起来。

动作配置路径：告警 > 动作 > 触发器动作 > 创建动作。

简单配置：

• 触发条件：触发器严重级别 >= 警告
• 操作：发送消息给用户组 “Ops”
• 恢复操作：发送“问题已恢复”给同一批人

再勾选“启用”并保存。

7.2 用 Webhook 推送企业微信

邮件缺点是延迟高、容易被当垃圾邮件。我给生产环境配的是企业微信机器人，原理很简单：Webhook 暴露一个 URL，收到事件后组装 JSON 后推送。

企业微信群里添加一个自定义机器人，拿到 Webhook 地址后，在 Zabbix 里配置一个“Webhook”类型的媒介。Zabbix 6.4 自带了一些 Webhook 的模板，比如 Slack、Telegram。企业微信需要自己写 MediaType 脚本，大致逻辑：

curl -s -X POST 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY' \ -H 'Content-Type: application/json' \ -d '{"msgtype":"text","text":{"content":"告警: '"{ALERT.MESSAGE}"'"}}'

在媒介类型参数里可以使用宏，比如{ALERT.MESSAGE}、{TRIGGER.NAME}、{HOST.NAME}。这样每次告警都会带出主机和触发器信息。

7.3 告警升级策略

Zabbix 动作里可以做多级操作。比如：

• 第 0 分钟：发送给值班群
• 第 15 分钟：如果问题仍未恢复，再发送给运维负责人
• 第 30 分钟：发送给整个技术部

每个操作都可以定义“步骤”区间。这个策略在夜间值班场景特别有价值，第一级值班人员如果 15 分钟没处理，消息自动升级，就不用有人专门盯着告警屏了。

8. 常见故障排查与性能调优：日志、缓存和数据库

8.1 Server 日志里都有哪些关键信息

Zabbix Server 的日志在/var/log/zabbix/zabbix_server.log，遇到任何“看起来没反应”的问题，先看这个文件。

常见日志信息如下：

日志关键字	含义	处理方向
cannot send list of active checks	Agent 主动采集连不上 Server	检查 10051 端口、防火墙
History cache has 25% free	历史缓存快满了	调大HistoryCacheSize
unreachable host	采集目标不可达	检查 Agent 进程、端口、网络
failed to select database	数据库连接失败	检查 DB 配置和连接数

服务进程本身没问题，但数据库连接被占满是另一类经典故障。Zabbix Server 是重度数据库使用者，尤其在大屏展示和告警并发时，MariaDB 默认连接数往往不够。可以到数据库里查当前连接数：

SHOW VARIABLES LIKE 'max_connections'; SHOW PROCESSLIST;

如果是慢查询堆积，优先看 Zabbix Server 日志里的 SQL 慢查询记录。大部分情况下需要调整的不是连接数，而是定时任务没有分区归档历史数据，导致history表膨胀得太快。

8.2 历史数据表分区

Zabbix 的历史数据量增长非常快，20 台主机跑一个月，history表可能就有几千万行。如果不做处理，数据库变慢后，整个监控系统都会跟着出问题。

Zabbix 6.4 从安装向导导入的表结构已经默认启用了分区。但还需要一个定时任务来清理旧分区。我用的是官方提供的人工分区脚本思路，也可以直接写 cron 定期执行分区维护脚本。

另一种更省事的方案是调整数据保留策略：管理 > 一般设置 > 历史数据。

• 历史数据保留时间：90 天
• 趋势数据保留时间：1 年

历史数据是原始采样值，趋势数据是聚合成小时/天级别的数据。默认模板下，趋势数据足够画长期的曲线图，历史数据留 90 天对日常排障够用了。

8.3 缓存参数调优

Zabbix Server 使用多级缓存保存监控项、历史数据和配置信息。当你在前端看到“Zabbix server is not running”但又确定进程活着时，很可能就是缓存被占满，进程在反复重启。

监控规模不同，配置差异很大。我的经验值参考：

主机数量	CacheSize	HistoryCacheSize	TrendCacheSize
10-30 台	64M	16M	16M
30-100 台	128M	64M	64M
100-300 台	256M	128M	128M

修改配置后重启：

systemctl restart zabbix-server

如果内存充足，宁可多给，不要卡在缓存瓶颈上。

8.4 Agent 端常见问题

Agent 端日志在/var/log/zabbix/zabbix_agent2.log。常见的现象：

• 主动检查一直失败：检查ServerActive是否写对，以及是否能从 Agent 端 telnet 到 Server 的 10051。
• 自定义脚本返回值不符合预期：Zabbix 要求脚本返回的非数值类型不是空行，且不能包含多余输出。可以手动执行一遍脚本，确认输出。
• Agent 频繁重启：看日志里是否有cannot find symbol，某些 Agent2 模块与操作系统版本不兼容时会出现动态库问题，换个模块或降级版本能解决。

8.5 前端页面慢的优化方向

如果 Zabbix 页面加载很慢，先看是不是 PHP-FPM 进程数不足。默认pm.max_children可能是 50，并发访问一高就卡。调整/etc/php-fpm.d/www.conf：

pm.max_children = 150 pm.start_servers = 20 pm.min_spare_servers = 10 pm.max_spare_servers = 40

接着检查 Nginx 是否开启了 Gzip 压缩。Zabbix 前端有很多 JS 和 CSS 文件，没有压缩的话加载体积会爆炸。

gzip on; gzip_types application/javascript text/css application/json image/svg+xml;

前端静态资源可以交给 Nginx 直接返回，加个expires 7d;缓存头，刷新页面速度会明显不一样。

9. 一套日常巡检清单：把我踩过的坑提前告诉您

9.1 每天该看什么

Zabbix 搭好之后不是一劳永逸的，我每天会固定看几个地方：

• 前端“主机”页面有没有红色“未监控”状态
• 最近 24 小时有没有产生大量“恢复”事件的触发器，这可能意味着阈值太敏感
• Server 本身的 CPU 和内存，避免监控系统反噬业务机器资源

9.2 哪些硬件指标值得额外关注

Linux 模板默认的 CPU、内存、磁盘使用率够用，但有两个指标我建议单独建监控：

• 磁盘 inode 使用率。很多应用出现“磁盘满”但df -h显示还有空间，其实是 inode 满了，大量小文件占光了索引节点。
• 网卡丢包率和错误包数。这个指标能提前预警网卡硬件故障或链路不稳定。

键值可以分别用：

vfs.fs.inode[/used,pfree] net.if.errs[eth0,errors]

9.3 升级与备份

Zabbix 的版本升级建议留意官方 LTS 版本时间线。6.4 目前还在生命周期内，升级到新版本前，至少备份两类东西：数据库和/etc/zabbix/下的配置文件。

mysqldump -uroot -p zabbix > /data/backup/zabbix_$(date +%F).sql tar czf /data/backup/zabbix_config_$(date +%F).tar.gz /etc/zabbix

恢复时先恢复数据库，再按官方文档重新安装对应版本的 RPM 包，最后恢复配置文件。

9.4 监控系统自身的安全加固

• 数据库账号不要用 root，单独给 zabbix 用户最小权限即可
• Web 管理端绑定内网 IP，不要暴露公网
• 如果必须公网访问，一定要套 HTTPS
• Agent 与 Server 之间开启 PSK 加密
• Zabbix 管理账号启用强密码，并定期轮换

这些基础项看着琐碎，但监控系统本身就握有全公司服务器的敏感信息，一旦被攻破，等于把内网情况全暴露了。

我在实际维护这套环境的过程里，最大的体会是：监控系统不是装完就完事的“工具”，它更像一个持续磨合的合作伙伴。模板给你的是通用视角，真正贴合业务的部分，还是要靠自定义键值和触发器一点点补全。现在业务团队找我查问题，我第一反应不是登服务器，而是先打开仪表盘看历史曲线。数据不会撒谎，把监控曲线调顺畅了，很多故障一眼就能定位到原因。