Zabbix与Prometheus监控体系实战：从部署到告警全解析

做运维这几年一个很深的体会监控不是“装个工具”就结束了而是要把数据采集、集中存储、可视化展示、告警通知这一整条链路真正跑通。很多公司一开始只是给服务器加了个 CPU、内存监控等线上真的出故障时才发现数据粒度太粗、告警全发到没人看的渠道、想回溯历史却保存周期太短。这篇文章把 Zabbix 和 Prometheus 两套主流监控体系完整拆解一遍从核心概念、环境部署、基础监控、告警配置到常见坑点一次讲清楚。内容覆盖两个方向的完整落地流程Zabbix 负责传统服务器、网络设备、UPS 等基础设施监控Prometheus 负责云原生、容器化、应用指标监控。无论是刚入行的运维新人还是需要从零搭建监控体系的工程师都能照着本文一步步操作。读者最好对 Linux 基础命令、Docker 基本使用有一定了解但即便没接触过监控系统也能跟着配置完成。1. 监控体系核心概念与选型1.1 监控到底在监控什么监控的范畴不只是一台服务器的 CPU 是否跑满。从生产实践经验来看监控体系通常覆盖三个层次基础设施层服务器的 CPU、内存、磁盘、网络流量以及交换机、路由器、防火墙等网络设备的端口状态和流量。应用服务层进程是否存在、端口是否监听、接口响应耗时、JVM 内存、数据库连接数、Redis 命中率、消息队列堆积量等。业务指标层订单量、交易成功率、支付失败数、转化率等直接反映业务健康度的指标。监控系统的核心流程也可以概括为四步采集数据、集中存储、可视化展示、异常告警。把这四步做好才算是完整的监控平台。1.2 Zabbix 是什么Zabbix 是一个企业级开源监控系统发展历史比 Prometheus 长很多。它的设计思路非常贴近传统运维一台 Zabbix Server 作为中心节点通过安装在目标机器上的 Agent 采集数据也支持通过 SNMP 协议监控网络设备通过 IPMI 监控服务器硬件状态通过 JMX 监控 Java 应用。Zabbix 的架构中通常包含 Server、数据库、Web 前端、Agent 和可选的 Proxy。Server 负责集中调度、触发器和告警判断数据存放在 MySQL 或 PostgreSQL 中Web 前端用于配置和查看。整体上Zabbix 适合监控规模大、设备类型杂、网络环境复杂的传统 IT 基础设施。1.3 Prometheus 是什么Prometheus 是云原生计算基金会CNCF下的开源监控系统在 Kubernetes 和微服务架构盛行的时代被广泛使用。它的核心设计思路是“拉模型”被监控的应用或节点通过 HTTP 暴露一个 metrics 接口Prometheus 定期访问这个接口拉取指标数据并把带有时间戳的采样数据写入本地时序数据库。Prometheus 的数据模型非常灵活每条时间序列由指标名和一组标签label唯一标识。比如node_cpu_seconds_total{cpu0, modeidle}就表示 0 号 CPU 的空闲时间累计值。这种维度化数据模型让透出查询变得非常方便。1.4 Zabbix 与 Prometheus 的区别对比维度ZabbixPrometheus定位传统 IT 基础设施监控云原生、容器、应用指标监控采集方式以轮询为主Agent 也可主动上报以 Pull 为主也支持 Pushgateway数据模型监控项Item 历史数据、趋势数据时间序列 多维标签数据存储MySQL / PostgreSQL适合历史数据归档本地 TSDB支持长期数据但通常保留有限周期告警体系触发器 动作内置通知渠道丰富规则文件 Alertmanager分组抑制能力强可视化自带 Web 界面模板丰富自带基础 UI通常配合 Grafana 展示自动发现支持网络设备发现、低级别发现LLD支持各类服务发现尤其适合 K8s上手成本功能全面但概念较多配置相对简洁但 PromQL 需要学习1.5 生产环境怎么选型选型不是“哪个好”的问题而是“哪个更适合你的环境”。如果公司业务主要以物理机、虚拟机、核心交换机、路由器、UPS 电源为主Zabbix 的成熟度和内置模板会省去大量工作量。如果公司业务已经容器化、微服务化应用部署在 Kubernetes 上Prometheus 几乎是最自然的选择因为 Kubernetes 生态的指标接口、服务发现机制和 Prometheus 天然契合。现实项目中也经常出现两套并存的局面Zabbix 管传统设备Prometheus 管容器和应用。本文后面的实战部分会分别把两套体系跑起来方便读者根据自己的实际场景做组合。2. 环境准备与版本说明2.1 操作系统与部署方式本文实验环境以 Rocky Linux 9 为例该系与 RHEL 9 / AlmaLinux 9 兼容命令基本通用。Zabbix 使用 Docker Compose 方式部署Prometheus、Grafana、Alertmanager 使用 Docker 方式部署node_exporter 以二进制方式安装到宿主机。采用容器化部署的原因是服务启动快、环境隔离好、卸载干净适合学习和测试。生产环境如果对性能要求高也可以把 Zabbix Server 和 Prometheus 改为二进制方式部署但核心配置思路是一致的。2.2 端口规划与防火墙部署前先明确各组件使用的端口避免冲突也方便后续排查网络问题。组件端口说明Zabbix Web8080Web 管理界面Zabbix Server10051接收 Agent 主动上报数据Zabbix Agent10050被动模式下允许 Server 采集Prometheus9090Web UI 和 APInode_exporter9100节点指标采集接口Alertmanager9093告警管理Grafana3000可视化面板如果你的服务器开启了 firewalld可以执行类似下面的命令放行端口。生产环境建议不要对公网开放这些端口而应限制来源 IP。firewall-cmd --permanent --add-port{8080,10051,9090,9093,3000,9100}/tcp firewall-cmd --reload更安全的做法是只允许办公网或运维跳板机 IP 访问firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.0.0/24 port protocoltcp port3000 accept firewall-cmd --reload2.3 版本说明本文示例中 Zabbix 使用当前主流的 7.0 LTS 系列镜像Prometheus 使用 2.x 系列镜像Grafana 使用最新稳定版镜像。具体版本以官方仓库当前提供为准。容器镜像的 tag 可以锁定版本也可以在测试环境中先使用 latest 验证功能生产环境建议固定 tag。3. Zabbix 核心组件与监控模型3.1 Zabbix 架构组成Zabbix 的核心组件包括以下几部分Zabbix Server核心调度服务负责数据采集调度、触发器计算、执行告警动作。数据库保存配置、历史数据、趋势数据Zabbix 7.0 支持 MySQL 和 PostgreSQL。Zabbix WebPHP 编写的管理界面负责配置和展示。Zabbix Agent部署在被监控主机上采集本地指标后返回给 Server。Zabbix Proxy可选组件在分布式场景下代替 Server 采集数据再批量同步给 Server。数据流向可以简单理解为Agent 采集本地指标 ↓ 主动上报或被动拉取 Zabbix Server 接收数据 ↓ 写入 数据库MySQL / PostgreSQL ↓ 计算 触发器判断是否异常 ↓ 触发 动作发送告警通知3.2 核心对象概念使用 Zabbix 之前需要先理解几个核心对象。主机Host一台被监控的服务器、交换机或其他设备。监控项Item采集某个具体指标的定义例如 CPU 使用率、磁盘空间剩余量。触发器Trigger对监控项数据设置阈值表达式返回 OK 或 PROBLEM 状态。动作Action当触发器状态变化时执行的操作例如发送告警邮件、调用 Webhook。模板Template一组监控项、触发器的集合可以批量套用到多台主机。自动发现Discovery自动发现网络设备或主机上的新资源。理解这几个概念后Zabbix 的使用逻辑就清晰了给主机套模板 - 模板里的监控项开始采集数据 - 触发器判断异常 - 动作发通知。3.3 Agent 主动模式与被动模式Zabbix Agent 有两种工作模式。被动模式下Zabbix Server 主动连接 Agent 的 10050 端口请求某个监控项的数据。这个模式适合 Server 与 Agent 网络互通、访问策略简单的场景。主动模式下Agent 主动连接 Zabbix Server 的 10051 端口周期性获取需要采集的监控项列表然后把数据批量传给 Server。这个模式适合 Agent 位于内网、Server 在外部网络或者 Agent 数量较多、需要减轻 Server 压力的场景。实际配置时Agent 配置文件里的Server参数表示允许哪些 IP 被动采集ServerActive参数表示主动上报到哪个 Server 地址。两个参数通常需要同时配置。4. Zabbix 7.0 部署与基础监控实战4.1 使用 Docker Compose 部署 Zabbix在开始前先创建项目目录并准备 docker-compose 文件。mkdir -p /opt/zabbix cd /opt/zabbix创建docker-compose.ymlservices: zabbix-db: image: mysql:8.0 container_name: zabbix-db restart: always command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_bin environment: MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd MYSQL_ROOT_PASSWORD: root_pwd volumes: - zabbix-db-data:/var/lib/mysql zabbix-server: image: zabbix/zabbix-server-mysql:7.0-ubuntu-latest container_name: zabbix-server restart: always environment: DB_SERVER_HOST: zabbix-db MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd ports: - 10051:10051 depends_on: - zabbix-db zabbix-web: image: zabbix/zabbix-web-nginx-mysql:7.0-ubuntu-latest container_name: zabbix-web restart: always environment: ZBX_SERVER_HOST: zabbix-server DB_SERVER_HOST: zabbix-db MYSQL_DATABASE: zabbix MYSQL_USER: zabbix MYSQL_PASSWORD: zabbix_pwd PHP_TZ: Asia/Shanghai ports: - 8080:8080 depends_on: - zabbix-server volumes: zabbix-db-data:字段说明MYSQL_DATABASE、MYSQL_USER、MYSQL_PASSWORD 是 Zabbix 数据库名和账号生产环境务必改为强密码。zabbix-server 镜像里的 DB_SERVER_HOST 指向数据库容器名 zabbix-db容器之间通过 Compose 网络互相访问。zabbix-web 配置 PHP_TZ 为 Asia/Shanghai避免前端时间显示不对。启动服务docker compose up -d docker compose ps等待 1 到 2 分钟数据库初始化完成后访问http://服务器IP:8080。默认账号为 Admin密码为 zabbix。首次登录后建议立即修改默认密码。4.2 在宿主机安装 Zabbix Agent2Zabbix 7.0 推荐使用 Agent2。在需要被监控的服务器上安装 Agent2以 Rocky Linux 9 为例先添加官方仓库再安装。rpm -ivh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-1.el9.noarch.rpm dnf install -y zabbix-agent2如果包名或仓库路径随着版本调整以 Zabbix 官方仓库提供的信息为准。修改 Agent2 配置vi /etc/zabbix/zabbix_agent2.conf修改或确认以下内容Server192.168.10.10 ServerActive192.168.10.10 Hostnamenode1.example.com其中192.168.10.10是 Zabbix Server 的 IP替换为你自己的环境地址。Hostname建议填写全限定主机名后续在 Web 界面添加主机时保持一致。启动并设置开机自启systemctl start zabbix-agent2 systemctl enable zabbix-agent2 ss -lntp | grep 10050如果看到 10050 端口监听说明 Agent2 已经正常运行。4.3 在 Web 界面添加主机登录 Zabbix Web 界面进入菜单“数据采集 - 主机”点击“创建主机”。填写主机名称例如 node1.example.com选择主机组然后设置 Agent 接口填写被监控服务器的 IP端口保持 10050。在模板栏输入Linux by Zabbix agent active选择该模板。这个模板里已经预置了大量 CPU、内存、磁盘、网络、系统服务的监控项和触发器适合直接使用。保存后等待一两分钟回到“监测 - 最新数据”筛选主机 node1.example.com就能看到采集到的指标数据。4.4 自定义一个触发器示例Zabbix 模板自带的触发器已经覆盖常见场景但有时需要自定义一个业务相关的告警。下面演示创建一个 CPU 使用率超过 90% 持续 5 分钟的触发器。进入菜单“数据采集 - 触发器”点击“创建触发器”。名称CPU 使用率超过 90%严重性警告表达式avg(/Linux by Zabbix agent active/system.cpu.util[,total],5m) 90这个表达式的含义是在模板Linux by Zabbix agent active下取监控项system.cpu.util[,total]最近 5 分钟的平均值如果大于 90就触发 PROBLEM 状态。保存后可以稍后在“监测 - 问题”中查看触发情况。4.5 配置钉钉告警动作Zabbix 的告警逻辑是触发器状态发生变化后由动作Action执行操作。要接入钉钉需要先配置报警媒介类型再分配给用户最后创建动作。Zabbix 7.0 的 Webhook 媒介基于 JavaScript社区有很多钉钉适配方案。核心思路是在“管理 - 报警媒介类型 - 创建媒介类型”中选择类型为 Webhook配置钉钉机器人的 Webhook 地址和自定义脚本。然后在“用户 - 报警媒介”中把该媒介分配给接收告警的用户最后在“告警 - 动作”中创建动作操作里选择发送消息给该用户。钉钉机器人本身要求签名校验因此生产环境通常由一个小服务转发 Alertmanager 或 Zabbix 的告警到钉钉。具体转发服务的实现在后文 Prometheus 告警部分会给出一个可运行的参考脚本。5. Prometheus Grafana 监控部署实战5.1 Prometheus 架构与采集模型Prometheus 的架构可以拆成几部分Prometheus Server负责拉取指标、存储时间序列数据、执行预警规则。Exporter以 HTTP 方式暴露指标常见的 node_exporter、mysqld_exporter、redis_exporter 都是这种形态。Pushgateway用于支持不适合 Pull 模式的短生命周期任务。Alertmanager接收 Prometheus 推送的告警负责分组、抑制、去重并发送通知。Grafana负责可视化展示虽然不是 Prometheus 官方组件但已经成为事实上的标准搭配。Prometheus 采用 Pull 模式即 Prometheus 主动访问 exporter 的 metrics 接口。这种模式的好处是采集目标清晰不容易对目标节点产生额外连接压力也方便在 Kubernetes 中通过服务发现自动发现新的监控目标。5.2 使用 Node Exporter 采集宿主机指标先从 GitHub Releases 页面获取 node_exporter 最新稳定版示例中使用 v1.8.2。cd /opt wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xzf node_exporter-1.8.2.linux-amd64.tar.gz cp node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/启动 node_exporter。可以使用 systemd 管理也可以先直接运行验证nohup node_exporter --web.listen-address:9100 然后验证指标接口curl http://127.0.0.1:9100/metrics | head -20如果能看到以node_开头的大量指标说明 exporter 工作正常。生产环境建议写成 systemd 服务这里给一个最小配置思路[Unit] DescriptionNode Exporter Afternetwork.target [Service] ExecStart/usr/local/bin/node_exporter Restartalways [Install] WantedBymulti-user.target5.3 编写 Prometheus 配置并启动Prometheus 的配置文件采用 YAML 格式。创建/opt/prometheus/prometheus.ymlglobal: scrape_interval: 15s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: - 127.0.0.1:9093 rule_files: - /etc/prometheus/rules.yml scrape_configs: - job_name: node static_configs: - targets: - 127.0.0.1:9100配置说明scrape_interval采集间隔15 秒适合大多数场景业务指标要求高时可以调低到 10 秒。evaluation_interval告警规则评估间隔Prometheus 会定期检查规则文件中的表达式。rule_files告警规则文件路径。alerting.alertmanagersAlertmanager 实例地址。scrape_configs抓取任务列表这里的 job_name 是 nodetargets 指向 node_exporter。启动 Prometheus。为了让 Prometheus 容器能直接访问宿主机的 node_exporter这里使用--network hostdocker run -d \ --name prometheus \ --restartalways \ --network host \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ -v /opt/prometheus/rules.yml:/etc/prometheus/rules.yml \ -v prometheus-data:/prometheus \ prom/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/prometheus \ --storage.tsdb.retention.time15d--storage.tsdb.retention.time15d表示本地数据保留 15 天。生产环境根据业务需求调整数据量大的可以考虑接入远端存储。浏览器访问http://服务器IP:9090在“Status - Targets”页面应该能看到 node 这个 job 的状态为 UP。5.4 初识 PromQL 常用查询PromQL 是 Prometheus 的查询语言掌握几个常用函数后基本就能完成日常诊断。查询当前所有采集目标的状态up返回值为 1 表示正常在线0 表示目标不可达。查询 5 分钟内的 CPU 使用率100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)查询可用内存node_memory_MemAvailable_bytes查询根分区使用率100 - (node_filesystem_free_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/} * 100)这里的关键是理解 rate 函数的含义。node_cpu_seconds_total是累计值直接除以时间间隔