ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

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

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 端默认监听 10051Agent 端默认监听 10050。如果你的机器在公有云上安全组要放行这两个端口如果在内网机房也要确认防火墙规则。我的习惯是内网采集端口不暴露公网能走内网走内网Web 管理端访问尽量限制来源 IPAgent 通信使用 PSK 预共享密钥加密后文会专门讲2.2 防火墙与 SELinux 的处理CentOS 7 默认开启 firewalld也允许 SELinux。如果直接安装 Zabbix很容易出现“服务起来了页面打不开”的情况最后排查半天发现是 SELinux 阻塞了 Nginx。这里我给两种选择如果你内网安全要求没那么苛刻可以先把 SELinux 设为宽容模式setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config我个人不推荐直接禁用 SELinux但在 Zabbix 这套场景下默认策略对 Nginx、PHP-FPM 的目录权限限制确实容易卡住新手。如果你坚持开启 SELinux那需要额外配置 httpd_can_network_connect 等布尔值比较繁琐。防火墙放行端口firewall-cmd --permanent --add-port10051/tcp firewall-cmd --permanent --add-port10050/tcp firewall-cmd --permanent --add-port80/tcp firewall-cmd --reload2.3 时间同步监控系统最怕的就是时钟不一致。Zabbix Server 判断主机是否“存活”靠的是心跳数据更新如果 Agent 所在机器的时间比 Server 慢了五分钟你会看到主机状态一直在“未监控”和“可用”之间横跳实际上业务没任何问题。必须配置 NTP 同步CentOS 7 默认可能是 chronyyum 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 zabbixlocalhost IDENTIFIED BY YourStrongPassword; CREATE USER zabbix127.0.0.1 IDENTIFIED BY YourStrongPassword; GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost; GRANT ALL PRIVILEGES ON zabbix.* TO zabbix127.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重点修改下面几项DBHost127.0.0.1 DBNamezabbix DBUserzabbix DBPasswordYourStrongPassword CacheSize128M HistoryCacheSize64M TrendCacheSize64M前面的 DB 参数是基础必填项后面的三个 Cache 参数是根据我实际监控 100 台左右主机的经验调整的。Zabbix Server 运行时会频繁读写内存缓存默认值偏保守如果监控规模稍微上来一点很容易在日志里看到 “history cache has X% free” 这类告警意思是历史数据缓存快写满了需要调大。改完启动systemctl enable zabbix-server systemctl start zabbix-server3.5 一个容易忽略的时区设置Zabbix 前端对 PHP 时区有硬性要求。如果你启动 Server 后打开页面时报“PHP time zone needs to be set”之类的错误去改/etc/php-fpm.d/zabbix.confphp_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 为什么不用自带的 ApacheZabbix RPM 包默认可以配 Apache但我个人不推荐在存量 CentOS 7 上为了 Zabbix 单开一套 Apache。内网服务器往往还跑着别的业务端口冲突和内存占用都是成本。改用 Nginx 更轻量而且 Zabbix 官方仓库里直接提供了 Nginx 的参考配置。安装 Nginxyum 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/session4.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.confServer192.168.10.10 ServerActive192.168.10.10 Hostnameweb-01Server字段允许来自这段 IP 的被动采集请求也就是 Zabbix Server 从 Agent 拉取数据。ServerActive是主动采集Agent 主动连接到 Server 的 10051 端口把指标推过去。两种模式各有适用场景。机器数量少、网络简单的时候用被动采集足够。移动端、跨机房、防火墙策略复杂的环境主动采集会更可靠因为它不需要对 Agent 开入站端口。生产上我习惯同时开两种前端选模板时用默认的“Zabbix agent active”或“Zabbix agent”模板都能兼容。5.2 PSK 加密配置Zabbix 支持预共享密钥加密 Agent 通信这个强烈建议开启。先在 Server 端生成一个 PSKopenssl rand -hex 32 /etc/zabbix/zabbix_server.psk chmod 640 /etc/zabbix/zabbix_server.psk chown root:zabbix /etc/zabbix/zabbix_server.psk在 Agent 端也放同一个文件并在配置里打开TLSConnectpsk TLSAcceptpsk TLSPSKIdentitypsk_client_01 TLSPSKFile/etc/zabbix/zabbix_agent2.psk注意 Server 端也必须在/etc/zabbix/zabbix_server.conf里设置TLSCAFile TLSConnectpsk TLSAcceptpsk前端页面的主机配置里填好对应的“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写入UserParameternginx.process.count,pgrep -f nginx: master | wc -l改完重启 Agentsystemctl 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?keyYOUR_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 checksAgent 主动采集连不上 Server检查 10051 端口、防火墙History cache has 25% free历史缓存快满了调大HistoryCacheSizeunreachable 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”但又确定进程活着时很可能就是缓存被占满进程在反复重启。监控规模不同配置差异很大。我的经验值参考主机数量CacheSizeHistoryCacheSizeTrendCacheSize10-30 台64M16M16M30-100 台128M64M64M100-300 台256M128M128M修改配置后重启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.confpm.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/svgxml;前端静态资源可以交给 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不要暴露公网如果必须公网访问一定要套 HTTPSAgent 与 Server 之间开启 PSK 加密Zabbix 管理账号启用强密码并定期轮换这些基础项看着琐碎但监控系统本身就握有全公司服务器的敏感信息一旦被攻破等于把内网情况全暴露了。我在实际维护这套环境的过程里最大的体会是监控系统不是装完就完事的“工具”它更像一个持续磨合的合作伙伴。模板给你的是通用视角真正贴合业务的部分还是要靠自定义键值和触发器一点点补全。现在业务团队找我查问题我第一反应不是登服务器而是先打开仪表盘看历史曲线。数据不会撒谎把监控曲线调顺畅了很多故障一眼就能定位到原因。
返回列表