很多刚入行的运维同学都会遇到同一个困惑公司监控体系到底应该怎么搭建网上搜索 Zabbix 和 Prometheus资料五花八门要么只讲安装不讲原理要么堆了一堆概念没有落地步骤。尤其是当你想把两台、几十台甚至上百台服务器统一管理起来时监控方案的选型、部署、指标采集、告警通知每一个环节都是坑。本文围绕 Zabbix 和 Prometheus 两条主流监控技术栈展开从核心概念讲起逐步拆解服务端安装、被监控端接入、指标配置、告警对接等完整流程。不管你是刚接触监控的运维新人还是已经负责生产环境的工程师都能从里面找到可以直接复用的操作步骤和避坑经验。需要提前说明的是监控领域的版本迭代很快不同操作系统的包管理方式也不同。本文示例以常见的 Linux 环境为例重点演示配置思路和完整链路具体版本号请根据你的实际服务器环境进行调整。1. 背景与核心概念1.1 为什么企业需要监控系统很多初学者会把监控简单理解为“看服务器死了没有”实际上企业级监控远不止这一层。生产环境中的故障往往是缓慢发生的磁盘使用率一点点涨到 95%内存持续泄漏导致 GC 频繁数据库连接数慢慢耗尽API 响应时间从 50ms 恶化到 3s。如果没有监控这些问题通常要等到用户投诉或者服务完全不可用才会被发现。监控系统的核心价值在于三点提前发现风险在故障真正发生之前通过阈值预警让运维有时间介入。快速定位问题当服务异常时通过历史指标数据还原故障时间线缩小排查范围。数据驱动决策容量规划、性能优化、成本控制都依赖长期稳定的监控数据。1.2 Zabbix 是什么Zabbix 是一个老牌的企业级开源监控平台诞生于 2001 年。它采用 C/S 架构核心组件包括 Zabbix Server、Zabbix Proxy、Zabbix Agent 和 Web 前端界面。Zabbix 的特点可以概括为“全而稳”。它原生支持 SNMP、JMX、IPMI、Agent 等多种采集方式几乎可以监控网络设备、服务器硬件、数据库、中间件、虚拟机等一切有 IP 地址的对象。Zabbix 自带告警、图表、报表、权限管理功能开箱即用对传统运维场景非常友好。1.3 Prometheus 是什么Prometheus 是由 SoundCloud 开发、后来捐赠给 CNCF 的开源监控系统也是 Kubernetes 生态中事实上的监控标准。它采用 Pull 模型即 Prometheus Server 主动从目标端点拉取指标数据而不是等待客户端推送。Prometheus 的核心组件包括 Prometheus Server、Exporter、Alertmanager 和 Grafana通常搭配使用。它的数据模型基于时序数据库每一条数据都带有一组标签Label这使得 Prometheus 在多维度数据查询和关联分析上非常灵活配合 PromQL 查询语言可以完成很复杂的聚合计算。1.4 Zabbix 和 Prometheus 怎么选这是运维圈讨论最多的话题之一也是很多新人在技术选型时最纠结的地方。对比维度ZabbixPrometheus架构模型Server/Agent 推送为主Server 主动拉取部署复杂度中等组件多但有完整前端轻量二进制即可运行监控对象服务器、网络设备、传统 IT 基础设施云原生、容器、微服务、应用指标数据存储关系型数据库 内部存储自带时序数据库 TSDB查询语言配置式筛选 预处理PromQL 灵活查询告警能力内置触发器、动作、通知需要搭配 Alertmanager可视化自带 Web UI功能较全一般搭配 Grafana适合场景传统机房、政企、网络设备较多的环境Kubernetes、云原生、DevOps 体系说实话两者不是互相替代的关系而是各有分工。传统物理机、网络交换机、UPS、带外管理卡这些场景Zabbix 的 SNMP 和 Agent 能力非常成熟而容器环境、微服务业务指标、Kubernetes 集群Prometheus 几乎是不二之选。很多中大型企业的实际现状是两套并存Zabbix 负责基础设施底线监控Prometheus 负责应用和容器层监控最后统一在 Grafana 或自研平台上展示。2. 环境准备与版本说明2.1 部署架构规划在开始安装之前先确定你的实验环境。以最小化学习环境为例我们准备两台服务器主机名IP 地址操作系统角色monitor192.168.10.10CentOS 7.9 / Ubuntu 20.04Zabbix Server Prometheus Grafanaweb-server192.168.10.20CentOS 7.9 / Ubuntu 20.04Zabbix Agent Node Exporter生产环境中建议将 Zabbix Server 和 Prometheus 分开部署但在学习阶段合在一起可以节省资源方便理解整体链路。2.2 系统基础配置无论使用哪种 Linux 发行版先完成基础环境配置。这里以 CentOS 为例# 关闭防火墙生产环境按需放行端口这里实验环境直接关闭 systemctl stop firewalld systemctl disable firewalld # 关闭 SELinux setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 同步系统时间 yum install -y ntpdate ntpdate ntp.aliyun.com需要特别提醒生产环境不要直接关闭防火墙和 SELinux而是按端口粒度放行。Zabbix Server 默认需要 80/443Web、10051Server 接收数据Zabbix Agent 需要 10050Prometheus 默认 9090Grafana 默认 3000。2.3 安装 Docker可选如果你不想在宿主机上直接安装一堆依赖用 Docker Compose 部署 Prometheus Grafana 是很高效的方式。后面 Prometheus 部分的示例会提供 Docker 版本同时也提供二进制版本方便没有 Docker 环境的朋友操作。# 安装 Docker以 CentOS 为例 yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker3. Zabbix 服务端安装与配置3.1 安装 Zabbix ServerZabbix 官方提供了针对不同发行版的软件源安装非常标准化。下面以 Zabbix 6.0 LTS MySQL Nginx 为例演示。# 1. 安装 Zabbix 官方源 rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-4.el7.noarch.rpm yum clean all # 2. 安装 Zabbix Server、Web 前端和 Agent yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-nginx-conf zabbix-agent # 3. 安装 MySQL 并启动CentOS 7 默认 MySQL 分支也可以用 MariaDB yum install -y mariadb-server systemctl start mariadb systemctl enable mariadb3.2 初始化数据库Zabbix 的数据表结构需要单独导入。数据库名称、用户名和密码可以根据实际情况调整但后续配置里要保持一致。# 进入 MySQL创建数据库和用户 mysql -uroot -p # 在 MySQL 命令行中执行 create database zabbix character set utf8mb4 collate utf8mb4_bin; create user zabbixlocalhost identified by Zabbix2026; create user zabbix127.0.0.1 identified by Zabbix2026; grant all privileges on zabbix.* to zabbixlocalhost; grant all privileges on zabbix.* to zabbix127.0.0.1; flush privileges; quit; # 导入初始表结构和数据 zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix注意导入过程可能需要十几秒到几分钟如果出现ERROR提示先检查数据库字符集和用户权限不要反复重复导入。3.3 修改 Zabbix Server 配置编辑 Zabbix Server 主配置文件填写数据库连接信息。vim /etc/zabbix/zabbix_server.conf需要关注并修改以下几项DBHost127.0.0.1 DBNamezabbix DBUserzabbix DBPasswordZabbix2026同时修改 PHP 时区配置vim /etc/php-fpm.d/zabbix.conf # 找到 php_value[date.timezone] 一行取消注释并修改 php_value[date.timezone] Asia/Shanghai3.4 配置 Nginx 并启动Zabbix 6.0 的 Nginx 配置已经集成在zabbix-nginx-conf包中只需要修改监听端口和 server_namevim /etc/nginx/conf.d/zabbix.conf # 修改 listen 端口默认 8080改成 80 或保持 8080 均可 listen 80; server_name monitor.example.com;启动服务systemctl restart zabbix-server zabbix-agent php-fpm nginx systemctl enable zabbix-server zabbix-agent php-fpm nginx3.5 完成 Web 初始化打开浏览器访问http://192.168.10.10进入 Zabbix Web 安装向导。安装向导会检查 PHP 环境、数据库连接、写权限等前置条件。遇到红色报错项时根据提示安装对应的 PHP 扩展或修改配置文件。填写数据库连接信息后向导会自动完成数据表校验。默认管理员账号是Admin密码是zabbix。登录后第一件事是修改密码然后进入Configuration - Hosts开始添加需要监控的主机。4. Prometheus Grafana 部署实战4.1 安装 Prometheus ServerPrometheus 是纯二进制分发不需要依赖额外的运行环境这一点比 Zabbix 要轻量很多。# 下载并解压版本号请到官网查询最新稳定版 cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz mv prometheus-2.53.0.linux-amd64 prometheus创建系统用户并配置启动服务useradd --no-create-home --shell /bin/false prometheus mkdir -p /etc/prometheus mkdir -p /var/lib/prometheus cp /opt/prometheus/prometheus /usr/local/bin/ cp /opt/prometheus/promtool /usr/local/bin/ cp -r /opt/prometheus/consoles /etc/prometheus/ cp -r /opt/prometheus/console_libraries /etc/prometheus/ chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus4.2 编写 Prometheus 主配置/etc/prometheus/prometheus.yml是 Prometheus 的核心配置文件。以下是最小可用配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node_exporter static_configs: - targets: [192.168.10.20:9100]配置项说明scrape_intervalPrometheus 拉取指标的频率。生产环境建议 15s 到 30s不要设置太短否则会对被监控端造成压力。evaluation_intervalPrometheus 评估告警规则的频率。scrape_configs定义采集任务。每个job_name是一组逻辑上相关的采集目标。创建 systemd 服务文件vim /etc/systemd/system/prometheus.service内容如下[Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus/ \ --web.console.templates/etc/prometheus/consoles \ --web.console.libraries/etc/prometheus/console_libraries [Install] WantedBymulti-user.target启动服务systemctl daemon-reload systemctl start prometheus systemctl enable prometheus4.3 部署 Node ExporterNode Exporter 是 Prometheus 生态中最常用的主机指标采集器负责暴露服务器的 CPU、内存、磁盘、网络等指标。在被监控主机上执行# 下载解压 cd /opt wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/ # 创建服务用户 useradd --no-create-home --shell /bin/false node_exporter创建 systemd 服务vim /etc/systemd/system/node_exporter.service[Unit] DescriptionNode Exporter Wantsnetwork-online.target Afternetwork-online.target [Service] Usernode_exporter Groupnode_exporter Typesimple ExecStart/usr/local/bin/node_exporter [Install] WantedBymulti-user.target启动并验证systemctl daemon-reload systemctl start node_exporter systemctl enable node_exporter # 验证指标是否正常输出 curl http://192.168.10.20:9100/metrics | head -n 20打开浏览器访问http://192.168.10.20:9100/metrics可以看到node_cpu_seconds_total、node_memory_MemTotal_bytes、node_filesystem_size_bytes等一系列指标。Prometheus 没有任何魔法它本质上就是每隔 15 秒来这个 URL 抓取一次文本数据。4.4 安装配置 GrafanaGrafana 是当前最流行的开源可视化平台虽然 Prometheus 自带了简单的图表功能但在生产环境中几乎没有团队直接使用大家都会选择 Grafana 做统一展示。# 添加 Grafana 官方源 vim /etc/yum.repos.d/grafana.repo[grafana] namegrafana baseurlhttps://rpm.grafana.com repo_gpgcheck1 enabled1 gpgcheck1 gpgkeyhttps://rpm.grafana.com/gpg.key sslverify1 sslcacert/etc/pki/tls/certs/ca-bundle.crtyum install -y grafana systemctl start grafana-server systemctl enable grafana-serverGrafana 默认端口是 3000浏览器访问http://192.168.10.10:3000初始账号和密码都是admin登录后强制修改密码。接下来需要添加 Prometheus 数据源点击左侧齿轮图标 -Data Sources-Add data source。选择Prometheus。在URL一栏填写http://192.168.10.10:9090。点击Save Test看到绿色提示表示连接成功。添加数据源后可以导入官方仪表盘模板。Node Exporter 最常用的模板 ID 是1860在Dashboards - Import中输入 ID选择 Prometheus 数据源并加载即可看到 CPU、内存、磁盘、网络等可视化面板。如果你希望用 Docker Compose 快速部署整套 Prometheus 环境可以参考下面的写法version: 3.8 services: prometheus: image: prom/prometheus container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana container_name: grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin volumes: - grafana_data:/var/lib/grafana restart: unless-stopped volumes: prometheus_data: grafana_data:不过需要提醒Docker 部署适合测试和轻量场景。生产环境里如果是几百台规模的主机监控建议还是二进制方式部署便于 systemd 统一管理和资源控制。5. 配置告警规则与通知对接监控系统只有数据展示是不够的告警才是核心闭环。当服务器 CPU 持续飙高、磁盘即将写满时运维必须第一时间收到通知。5.1 Zabbix 告警配置Zabbix 的告警体系由触发器Trigger和动作Action组成。触发器定义“什么情况下算异常”动作定义“异常后做什么”。以一个常见场景为例监控磁盘根分区使用率超过 90% 并持续 10 分钟。首先在Configuration - Hosts中找到对应主机点击Triggers创建触发器名称Root partition disk usage is too highSeverityWarning表达式last(/Linux server/vfs.fs.size[/,pused])90表达式的含义是取主机Linux server上挂载点/的使用百分比当最近一次取值大于 90 时触发告警。然后配置动作。在Configuration - Actions - Trigger actions中创建动作指定条件为“触发器级别 Warning”操作包括发送邮件、发送钉钉机器人消息等。Zabbix 对接钉钉机器人是一种很流行的通知方式。钉钉群添加自定义机器人后会生成一个 Webhook 地址通过zabbix_server.conf中的 AlertScriptsPath 指定脚本目录把通知脚本放进去即可。# 查看告警脚本目录 grep AlertScriptsPath /etc/zabbix/zabbix_server.conf # 在 AlertScriptsPath 下创建 dingding.py vim /usr/lib/zabbix/alertscripts/dingding.py脚本的核心逻辑是接收告警标题和内容调用钉钉 Webhook 发送 HTTP 请求。也可以直接用 curl 实现Python 脚本在拼接复杂消息时更灵活。脚本写完记得加执行权限并在动作配置的“操作”步骤里填写脚本参数和告警消息模板。5.2 Prometheus 告警规则Prometheus 通过配置rules文件来定义告警规则由 Alertmanager 负责发送通知。首先在/etc/prometheus/下创建规则文件alert_rules.ymlgroups: - name: node_exporter_alerts rules: - alert: HighCPUUsage expr: 100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: CPU 使用率过高实例{{ $labels.instance }} description: CPU 使用率已持续超过 85% 达 10 分钟当前值{{ $value }}%规则字段说明alert告警名称。exprPromQL 表达式当结果为 true 时触发告警。for持续时间。表达式持续满足该时长才触发避免瞬时抖动造成误报。labels附加标签通常用于标记告警级别。annotations告警消息内容支持模板变量。修改主配置引入规则文件rule_files: - alert_rules.yml重启 Prometheus 后在 Web UI 的Status - Rules页面可以看到规则加载状态。5.3 部署 AlertmanagerAlertmanager 负责接收 Prometheus 推送的告警并执行去重、分组、静默、路由和发送通知。wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz tar xvf alertmanager-0.27.0.linux-amd64.tar.gz mv alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/ mv alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/创建配置文件/etc/alertmanager/alertmanager.ymlglobal: resolve_timeout: 5m smtp_smarthost: smtp.example.com:465 smtp_from: alertexample.com smtp_auth_username: alertexample.com smtp_auth_password: your-password route: group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: email receivers: - name: email email_configs: - to: opsexample.com send_resolved: truesend_resolved: true表示故障恢复后也发送一条通知这能帮助运维确认告警已闭环。同时修改 Prometheus 主配置加入 Alertmanager 地址alerting: alertmanagers: - static_configs: - targets: - localhost:9093启动 Alertmanager 后在 Web UIhttp://192.168.10.10:9093可以看到所有告警状态。新触发且尚未发送通知的告警是Active已发送通知的变为Firing恢复后为Resolved。6. 常见问题与排查思路6.1 Zabbix Server 告警处理器利用率过高有网友反馈 Zabbix Server 日志出现utilization of history syncer processes over 75%。这个问题的本质是历史数据写入数据库太慢后台同步进程处理不过来了。常见原因和解决方向问题现象常见原因解决思路history syncer 利用率高监控项数量太多历史数据写入频繁调整HistoryCacheSize、增加同步进程数数据库性能瓶颈表数据量过大缺少索引定期清理历史数据开启分区表采集频率过高大量监控项设置 10s 或更短间隔合理延长采集间隔非关键指标设为 60s趋势数据保留周期过长housekeeper 清理跟不上调整数据保留策略删除不必要的历史表6.2 Prometheus 指标拉取失败现象Prometheus 的Targets页面显示DOWN。排查步骤在被监控机上执行curl http://IP:9100/metrics确认端口是否监听。检查防火墙是否放行端口。在 Prometheus 服务器上执行telnet IP 9100确认网络连通性。检查目标主机名是否能被解析static_configs中填的是 IP 还是域名。6.3 Grafana 图表显示 No data数据源连接没问题但面板无数据通常有两种情况仪表盘模板的查询语句与实际指标不匹配特别是导入第三方模板时版本不一致。时间范围设置不对。Grafana 默认查看最近 6 小时如果刚部署完可以切换到Last 15 minutes验证。6.4 Zabbix Agent 显示 Host unreachable最常见的原因是 Zabbix Server 到 Agent 的 10050 端口不通或者 Agent 配置里的Server字段没有包含 Zabbix Server 的 IP。注意 Agent 配置文件中有两个容易混淆的项Server允许哪些地址来获取监控数据。ServerActiveAgent 主动向哪些地址汇报数据。只设置了ServerActive而忘了填Server会出现主机状态被标记为不支持的情况。7. 最佳实践与工程建议7.1 监控体系设计原则在部署监控之前先花时间想清楚监控的对象和范围比急着装软件更重要。一个好的监控体系通常分层设计基础设施层服务器 CPU、内存、磁盘、网络通过 Zabbix Agent 或 Node Exporter 采集。中间件层MySQL、Redis、Nginx、Kafka 等组件的连接数、慢查询、延迟、命中率等指标。应用层接口 QPS、错误率、响应时间 P95/P99这类指标通常通过 Prometheus SDK 埋点暴露。业务层订单量、注册转化率、支付成功率等。这类指标最接近公司业务价值也往往最容易被人忽略。7.2 告警策略要克制很多团队的监控系统最终沦为“狼来了”的工具原因是告警太多太滥每个人都处于告警疲劳状态。建议从以下几点控制告警质量所有告警必须配置for/ 持续时间避免瞬时抖动触发。告警级别最多分三级Warning、Critical、Fatal不要搞出七八种颜色。每条告警消息必须包含“谁在什么时候、哪个实例、当前值多少、如何解决”不要只发一句“CPU high”。周期性审查告警规则清理长期不处理或重复的规则。7.3 数据保留与容量规划Prometheus 的 TSDB 存储占用和三个因素相关指标数量、采集频率、保留时间。经验公式是每个样本大约 2 字节存储空间。假设你有 1000 个指标、15s 采集一次、保留 15 天计算公式是1000 × (86400 / 15) × 15 × 2 ≈ 172 MB看起来不大但生产环境指标数量动辄几百万条实际占用会迅速膨胀。建议按指标 importance 调整采集频率核心指标 15s边缘指标 60s。通过--storage.tsdb.retention.time控制保留周期。长期历史数据可以对接 Thanos 或 VictoriaMetrics而不是直接加大磁盘。7.4 安全与权限管理监控系统收集的是整个基础设施的敏感数据其自身安全性往往决定整个运维体系的安全性。Zabbix Web 前端必须开启 HTTPS并限制管理员 IP 白名单。Prometheus 默认没有认证机制生产环境建议在前面加 Nginx 反向代理做 Basic Auth。Grafana 开启匿名访问限制不同团队之间的看板通过 Organization 隔离。所有监控脚本中的数据库密码、Webhook 地址等敏感信息不要明文写在配置文件里使用环境变量或密钥管理工具注入。7.5 监控系统自身的可观测性这里有一个经典悖论监控系统挂了谁来监控监控建议至少做到两点Zabbix Server 和 Prometheus 自身进程使用 systemd 托管配置 Restarton-failure。将 Zabbix Server 和 Prometheus 的关键指标进程存活、数据采集延迟互相监控形成交叉验证。8. 总结与学习路线本文从企业监控的真实需求出发完整拆解了 Zabbix 和 Prometheus 两套主流技术栈从基础概念到服务端安装、被监控端接入、告警规则配置、通知对接、常见问题排查最后补充了监控体系设计的工程建议。学完本文你应该已经掌握了Zabbix 的架构、数据库初始化、Agent 接入流程。Prometheus 的 Pull 模型、Exporter 机制和 PromQL 基础。Grafana 数据源接入和仪表盘导入。两种监控体系的告警配置路径和通知方式。监控数据保留、容量规划和告警质量控制的经验方法。下一阶段建议你按这个路线继续深入学习在真实服务器上完整部署一遍 Zabbix 或者 Prometheus不要只看不练。用 Zabbix SNMP 监控一台真实交换机或路由器理解网络设备监控和服务器监控的区别。学习 PromQL 的高级聚合操作比如rate()、increase()、histogram_quantile()。尝试用 Docker Compose 搭建一套完整的 Prometheus Grafana Alertmanager 环境。阅读 Kubernetes 官方文档中关于 Metrics Server 和 kube-state-metrics 的内容逐步进入云原生监控领域。监控系统的学习曲线确实不短但它是运维工程师最值得投入的方向之一。一个人可能不需要精通所有技术栈但只要能独立把一套监控从零搭起来并稳定运行你对整个系统的理解就会提升一个档次。遇到报错不要慌按日志、端口、配置、权限四个方向去排查大多数问题都能解决。如果本文对你有帮助可以收藏备用也可以转发给身边正在学习监控的朋友。后面我会继续更新 Zabbix 模板定制、Prometheus 云原生监控、Grafana 高级面板设计等实战内容欢迎保持关注。
Zabbix与Prometheus监控系统搭建实战：从基础概念到告警通知全流程
很多刚入行的运维同学都会遇到同一个困惑公司监控体系到底应该怎么搭建网上搜索 Zabbix 和 Prometheus资料五花八门要么只讲安装不讲原理要么堆了一堆概念没有落地步骤。尤其是当你想把两台、几十台甚至上百台服务器统一管理起来时监控方案的选型、部署、指标采集、告警通知每一个环节都是坑。本文围绕 Zabbix 和 Prometheus 两条主流监控技术栈展开从核心概念讲起逐步拆解服务端安装、被监控端接入、指标配置、告警对接等完整流程。不管你是刚接触监控的运维新人还是已经负责生产环境的工程师都能从里面找到可以直接复用的操作步骤和避坑经验。需要提前说明的是监控领域的版本迭代很快不同操作系统的包管理方式也不同。本文示例以常见的 Linux 环境为例重点演示配置思路和完整链路具体版本号请根据你的实际服务器环境进行调整。1. 背景与核心概念1.1 为什么企业需要监控系统很多初学者会把监控简单理解为“看服务器死了没有”实际上企业级监控远不止这一层。生产环境中的故障往往是缓慢发生的磁盘使用率一点点涨到 95%内存持续泄漏导致 GC 频繁数据库连接数慢慢耗尽API 响应时间从 50ms 恶化到 3s。如果没有监控这些问题通常要等到用户投诉或者服务完全不可用才会被发现。监控系统的核心价值在于三点提前发现风险在故障真正发生之前通过阈值预警让运维有时间介入。快速定位问题当服务异常时通过历史指标数据还原故障时间线缩小排查范围。数据驱动决策容量规划、性能优化、成本控制都依赖长期稳定的监控数据。1.2 Zabbix 是什么Zabbix 是一个老牌的企业级开源监控平台诞生于 2001 年。它采用 C/S 架构核心组件包括 Zabbix Server、Zabbix Proxy、Zabbix Agent 和 Web 前端界面。Zabbix 的特点可以概括为“全而稳”。它原生支持 SNMP、JMX、IPMI、Agent 等多种采集方式几乎可以监控网络设备、服务器硬件、数据库、中间件、虚拟机等一切有 IP 地址的对象。Zabbix 自带告警、图表、报表、权限管理功能开箱即用对传统运维场景非常友好。1.3 Prometheus 是什么Prometheus 是由 SoundCloud 开发、后来捐赠给 CNCF 的开源监控系统也是 Kubernetes 生态中事实上的监控标准。它采用 Pull 模型即 Prometheus Server 主动从目标端点拉取指标数据而不是等待客户端推送。Prometheus 的核心组件包括 Prometheus Server、Exporter、Alertmanager 和 Grafana通常搭配使用。它的数据模型基于时序数据库每一条数据都带有一组标签Label这使得 Prometheus 在多维度数据查询和关联分析上非常灵活配合 PromQL 查询语言可以完成很复杂的聚合计算。1.4 Zabbix 和 Prometheus 怎么选这是运维圈讨论最多的话题之一也是很多新人在技术选型时最纠结的地方。对比维度ZabbixPrometheus架构模型Server/Agent 推送为主Server 主动拉取部署复杂度中等组件多但有完整前端轻量二进制即可运行监控对象服务器、网络设备、传统 IT 基础设施云原生、容器、微服务、应用指标数据存储关系型数据库 内部存储自带时序数据库 TSDB查询语言配置式筛选 预处理PromQL 灵活查询告警能力内置触发器、动作、通知需要搭配 Alertmanager可视化自带 Web UI功能较全一般搭配 Grafana适合场景传统机房、政企、网络设备较多的环境Kubernetes、云原生、DevOps 体系说实话两者不是互相替代的关系而是各有分工。传统物理机、网络交换机、UPS、带外管理卡这些场景Zabbix 的 SNMP 和 Agent 能力非常成熟而容器环境、微服务业务指标、Kubernetes 集群Prometheus 几乎是不二之选。很多中大型企业的实际现状是两套并存Zabbix 负责基础设施底线监控Prometheus 负责应用和容器层监控最后统一在 Grafana 或自研平台上展示。2. 环境准备与版本说明2.1 部署架构规划在开始安装之前先确定你的实验环境。以最小化学习环境为例我们准备两台服务器主机名IP 地址操作系统角色monitor192.168.10.10CentOS 7.9 / Ubuntu 20.04Zabbix Server Prometheus Grafanaweb-server192.168.10.20CentOS 7.9 / Ubuntu 20.04Zabbix Agent Node Exporter生产环境中建议将 Zabbix Server 和 Prometheus 分开部署但在学习阶段合在一起可以节省资源方便理解整体链路。2.2 系统基础配置无论使用哪种 Linux 发行版先完成基础环境配置。这里以 CentOS 为例# 关闭防火墙生产环境按需放行端口这里实验环境直接关闭 systemctl stop firewalld systemctl disable firewalld # 关闭 SELinux setenforce 0 sed -i s/^SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config # 同步系统时间 yum install -y ntpdate ntpdate ntp.aliyun.com需要特别提醒生产环境不要直接关闭防火墙和 SELinux而是按端口粒度放行。Zabbix Server 默认需要 80/443Web、10051Server 接收数据Zabbix Agent 需要 10050Prometheus 默认 9090Grafana 默认 3000。2.3 安装 Docker可选如果你不想在宿主机上直接安装一堆依赖用 Docker Compose 部署 Prometheus Grafana 是很高效的方式。后面 Prometheus 部分的示例会提供 Docker 版本同时也提供二进制版本方便没有 Docker 环境的朋友操作。# 安装 Docker以 CentOS 为例 yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker3. Zabbix 服务端安装与配置3.1 安装 Zabbix ServerZabbix 官方提供了针对不同发行版的软件源安装非常标准化。下面以 Zabbix 6.0 LTS MySQL Nginx 为例演示。# 1. 安装 Zabbix 官方源 rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-4.el7.noarch.rpm yum clean all # 2. 安装 Zabbix Server、Web 前端和 Agent yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-nginx-conf zabbix-agent # 3. 安装 MySQL 并启动CentOS 7 默认 MySQL 分支也可以用 MariaDB yum install -y mariadb-server systemctl start mariadb systemctl enable mariadb3.2 初始化数据库Zabbix 的数据表结构需要单独导入。数据库名称、用户名和密码可以根据实际情况调整但后续配置里要保持一致。# 进入 MySQL创建数据库和用户 mysql -uroot -p # 在 MySQL 命令行中执行 create database zabbix character set utf8mb4 collate utf8mb4_bin; create user zabbixlocalhost identified by Zabbix2026; create user zabbix127.0.0.1 identified by Zabbix2026; grant all privileges on zabbix.* to zabbixlocalhost; grant all privileges on zabbix.* to zabbix127.0.0.1; flush privileges; quit; # 导入初始表结构和数据 zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix注意导入过程可能需要十几秒到几分钟如果出现ERROR提示先检查数据库字符集和用户权限不要反复重复导入。3.3 修改 Zabbix Server 配置编辑 Zabbix Server 主配置文件填写数据库连接信息。vim /etc/zabbix/zabbix_server.conf需要关注并修改以下几项DBHost127.0.0.1 DBNamezabbix DBUserzabbix DBPasswordZabbix2026同时修改 PHP 时区配置vim /etc/php-fpm.d/zabbix.conf # 找到 php_value[date.timezone] 一行取消注释并修改 php_value[date.timezone] Asia/Shanghai3.4 配置 Nginx 并启动Zabbix 6.0 的 Nginx 配置已经集成在zabbix-nginx-conf包中只需要修改监听端口和 server_namevim /etc/nginx/conf.d/zabbix.conf # 修改 listen 端口默认 8080改成 80 或保持 8080 均可 listen 80; server_name monitor.example.com;启动服务systemctl restart zabbix-server zabbix-agent php-fpm nginx systemctl enable zabbix-server zabbix-agent php-fpm nginx3.5 完成 Web 初始化打开浏览器访问http://192.168.10.10进入 Zabbix Web 安装向导。安装向导会检查 PHP 环境、数据库连接、写权限等前置条件。遇到红色报错项时根据提示安装对应的 PHP 扩展或修改配置文件。填写数据库连接信息后向导会自动完成数据表校验。默认管理员账号是Admin密码是zabbix。登录后第一件事是修改密码然后进入Configuration - Hosts开始添加需要监控的主机。4. Prometheus Grafana 部署实战4.1 安装 Prometheus ServerPrometheus 是纯二进制分发不需要依赖额外的运行环境这一点比 Zabbix 要轻量很多。# 下载并解压版本号请到官网查询最新稳定版 cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz mv prometheus-2.53.0.linux-amd64 prometheus创建系统用户并配置启动服务useradd --no-create-home --shell /bin/false prometheus mkdir -p /etc/prometheus mkdir -p /var/lib/prometheus cp /opt/prometheus/prometheus /usr/local/bin/ cp /opt/prometheus/promtool /usr/local/bin/ cp -r /opt/prometheus/consoles /etc/prometheus/ cp -r /opt/prometheus/console_libraries /etc/prometheus/ chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus4.2 编写 Prometheus 主配置/etc/prometheus/prometheus.yml是 Prometheus 的核心配置文件。以下是最小可用配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node_exporter static_configs: - targets: [192.168.10.20:9100]配置项说明scrape_intervalPrometheus 拉取指标的频率。生产环境建议 15s 到 30s不要设置太短否则会对被监控端造成压力。evaluation_intervalPrometheus 评估告警规则的频率。scrape_configs定义采集任务。每个job_name是一组逻辑上相关的采集目标。创建 systemd 服务文件vim /etc/systemd/system/prometheus.service内容如下[Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus/ \ --web.console.templates/etc/prometheus/consoles \ --web.console.libraries/etc/prometheus/console_libraries [Install] WantedBymulti-user.target启动服务systemctl daemon-reload systemctl start prometheus systemctl enable prometheus4.3 部署 Node ExporterNode Exporter 是 Prometheus 生态中最常用的主机指标采集器负责暴露服务器的 CPU、内存、磁盘、网络等指标。在被监控主机上执行# 下载解压 cd /opt wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz mv node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/ # 创建服务用户 useradd --no-create-home --shell /bin/false node_exporter创建 systemd 服务vim /etc/systemd/system/node_exporter.service[Unit] DescriptionNode Exporter Wantsnetwork-online.target Afternetwork-online.target [Service] Usernode_exporter Groupnode_exporter Typesimple ExecStart/usr/local/bin/node_exporter [Install] WantedBymulti-user.target启动并验证systemctl daemon-reload systemctl start node_exporter systemctl enable node_exporter # 验证指标是否正常输出 curl http://192.168.10.20:9100/metrics | head -n 20打开浏览器访问http://192.168.10.20:9100/metrics可以看到node_cpu_seconds_total、node_memory_MemTotal_bytes、node_filesystem_size_bytes等一系列指标。Prometheus 没有任何魔法它本质上就是每隔 15 秒来这个 URL 抓取一次文本数据。4.4 安装配置 GrafanaGrafana 是当前最流行的开源可视化平台虽然 Prometheus 自带了简单的图表功能但在生产环境中几乎没有团队直接使用大家都会选择 Grafana 做统一展示。# 添加 Grafana 官方源 vim /etc/yum.repos.d/grafana.repo[grafana] namegrafana baseurlhttps://rpm.grafana.com repo_gpgcheck1 enabled1 gpgcheck1 gpgkeyhttps://rpm.grafana.com/gpg.key sslverify1 sslcacert/etc/pki/tls/certs/ca-bundle.crtyum install -y grafana systemctl start grafana-server systemctl enable grafana-serverGrafana 默认端口是 3000浏览器访问http://192.168.10.10:3000初始账号和密码都是admin登录后强制修改密码。接下来需要添加 Prometheus 数据源点击左侧齿轮图标 -Data Sources-Add data source。选择Prometheus。在URL一栏填写http://192.168.10.10:9090。点击Save Test看到绿色提示表示连接成功。添加数据源后可以导入官方仪表盘模板。Node Exporter 最常用的模板 ID 是1860在Dashboards - Import中输入 ID选择 Prometheus 数据源并加载即可看到 CPU、内存、磁盘、网络等可视化面板。如果你希望用 Docker Compose 快速部署整套 Prometheus 环境可以参考下面的写法version: 3.8 services: prometheus: image: prom/prometheus container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana container_name: grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin volumes: - grafana_data:/var/lib/grafana restart: unless-stopped volumes: prometheus_data: grafana_data:不过需要提醒Docker 部署适合测试和轻量场景。生产环境里如果是几百台规模的主机监控建议还是二进制方式部署便于 systemd 统一管理和资源控制。5. 配置告警规则与通知对接监控系统只有数据展示是不够的告警才是核心闭环。当服务器 CPU 持续飙高、磁盘即将写满时运维必须第一时间收到通知。5.1 Zabbix 告警配置Zabbix 的告警体系由触发器Trigger和动作Action组成。触发器定义“什么情况下算异常”动作定义“异常后做什么”。以一个常见场景为例监控磁盘根分区使用率超过 90% 并持续 10 分钟。首先在Configuration - Hosts中找到对应主机点击Triggers创建触发器名称Root partition disk usage is too highSeverityWarning表达式last(/Linux server/vfs.fs.size[/,pused])90表达式的含义是取主机Linux server上挂载点/的使用百分比当最近一次取值大于 90 时触发告警。然后配置动作。在Configuration - Actions - Trigger actions中创建动作指定条件为“触发器级别 Warning”操作包括发送邮件、发送钉钉机器人消息等。Zabbix 对接钉钉机器人是一种很流行的通知方式。钉钉群添加自定义机器人后会生成一个 Webhook 地址通过zabbix_server.conf中的 AlertScriptsPath 指定脚本目录把通知脚本放进去即可。# 查看告警脚本目录 grep AlertScriptsPath /etc/zabbix/zabbix_server.conf # 在 AlertScriptsPath 下创建 dingding.py vim /usr/lib/zabbix/alertscripts/dingding.py脚本的核心逻辑是接收告警标题和内容调用钉钉 Webhook 发送 HTTP 请求。也可以直接用 curl 实现Python 脚本在拼接复杂消息时更灵活。脚本写完记得加执行权限并在动作配置的“操作”步骤里填写脚本参数和告警消息模板。5.2 Prometheus 告警规则Prometheus 通过配置rules文件来定义告警规则由 Alertmanager 负责发送通知。首先在/etc/prometheus/下创建规则文件alert_rules.ymlgroups: - name: node_exporter_alerts rules: - alert: HighCPUUsage expr: 100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: CPU 使用率过高实例{{ $labels.instance }} description: CPU 使用率已持续超过 85% 达 10 分钟当前值{{ $value }}%规则字段说明alert告警名称。exprPromQL 表达式当结果为 true 时触发告警。for持续时间。表达式持续满足该时长才触发避免瞬时抖动造成误报。labels附加标签通常用于标记告警级别。annotations告警消息内容支持模板变量。修改主配置引入规则文件rule_files: - alert_rules.yml重启 Prometheus 后在 Web UI 的Status - Rules页面可以看到规则加载状态。5.3 部署 AlertmanagerAlertmanager 负责接收 Prometheus 推送的告警并执行去重、分组、静默、路由和发送通知。wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz tar xvf alertmanager-0.27.0.linux-amd64.tar.gz mv alertmanager-0.27.0.linux-amd64/alertmanager /usr/local/bin/ mv alertmanager-0.27.0.linux-amd64/amtool /usr/local/bin/创建配置文件/etc/alertmanager/alertmanager.ymlglobal: resolve_timeout: 5m smtp_smarthost: smtp.example.com:465 smtp_from: alertexample.com smtp_auth_username: alertexample.com smtp_auth_password: your-password route: group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: email receivers: - name: email email_configs: - to: opsexample.com send_resolved: truesend_resolved: true表示故障恢复后也发送一条通知这能帮助运维确认告警已闭环。同时修改 Prometheus 主配置加入 Alertmanager 地址alerting: alertmanagers: - static_configs: - targets: - localhost:9093启动 Alertmanager 后在 Web UIhttp://192.168.10.10:9093可以看到所有告警状态。新触发且尚未发送通知的告警是Active已发送通知的变为Firing恢复后为Resolved。6. 常见问题与排查思路6.1 Zabbix Server 告警处理器利用率过高有网友反馈 Zabbix Server 日志出现utilization of history syncer processes over 75%。这个问题的本质是历史数据写入数据库太慢后台同步进程处理不过来了。常见原因和解决方向问题现象常见原因解决思路history syncer 利用率高监控项数量太多历史数据写入频繁调整HistoryCacheSize、增加同步进程数数据库性能瓶颈表数据量过大缺少索引定期清理历史数据开启分区表采集频率过高大量监控项设置 10s 或更短间隔合理延长采集间隔非关键指标设为 60s趋势数据保留周期过长housekeeper 清理跟不上调整数据保留策略删除不必要的历史表6.2 Prometheus 指标拉取失败现象Prometheus 的Targets页面显示DOWN。排查步骤在被监控机上执行curl http://IP:9100/metrics确认端口是否监听。检查防火墙是否放行端口。在 Prometheus 服务器上执行telnet IP 9100确认网络连通性。检查目标主机名是否能被解析static_configs中填的是 IP 还是域名。6.3 Grafana 图表显示 No data数据源连接没问题但面板无数据通常有两种情况仪表盘模板的查询语句与实际指标不匹配特别是导入第三方模板时版本不一致。时间范围设置不对。Grafana 默认查看最近 6 小时如果刚部署完可以切换到Last 15 minutes验证。6.4 Zabbix Agent 显示 Host unreachable最常见的原因是 Zabbix Server 到 Agent 的 10050 端口不通或者 Agent 配置里的Server字段没有包含 Zabbix Server 的 IP。注意 Agent 配置文件中有两个容易混淆的项Server允许哪些地址来获取监控数据。ServerActiveAgent 主动向哪些地址汇报数据。只设置了ServerActive而忘了填Server会出现主机状态被标记为不支持的情况。7. 最佳实践与工程建议7.1 监控体系设计原则在部署监控之前先花时间想清楚监控的对象和范围比急着装软件更重要。一个好的监控体系通常分层设计基础设施层服务器 CPU、内存、磁盘、网络通过 Zabbix Agent 或 Node Exporter 采集。中间件层MySQL、Redis、Nginx、Kafka 等组件的连接数、慢查询、延迟、命中率等指标。应用层接口 QPS、错误率、响应时间 P95/P99这类指标通常通过 Prometheus SDK 埋点暴露。业务层订单量、注册转化率、支付成功率等。这类指标最接近公司业务价值也往往最容易被人忽略。7.2 告警策略要克制很多团队的监控系统最终沦为“狼来了”的工具原因是告警太多太滥每个人都处于告警疲劳状态。建议从以下几点控制告警质量所有告警必须配置for/ 持续时间避免瞬时抖动触发。告警级别最多分三级Warning、Critical、Fatal不要搞出七八种颜色。每条告警消息必须包含“谁在什么时候、哪个实例、当前值多少、如何解决”不要只发一句“CPU high”。周期性审查告警规则清理长期不处理或重复的规则。7.3 数据保留与容量规划Prometheus 的 TSDB 存储占用和三个因素相关指标数量、采集频率、保留时间。经验公式是每个样本大约 2 字节存储空间。假设你有 1000 个指标、15s 采集一次、保留 15 天计算公式是1000 × (86400 / 15) × 15 × 2 ≈ 172 MB看起来不大但生产环境指标数量动辄几百万条实际占用会迅速膨胀。建议按指标 importance 调整采集频率核心指标 15s边缘指标 60s。通过--storage.tsdb.retention.time控制保留周期。长期历史数据可以对接 Thanos 或 VictoriaMetrics而不是直接加大磁盘。7.4 安全与权限管理监控系统收集的是整个基础设施的敏感数据其自身安全性往往决定整个运维体系的安全性。Zabbix Web 前端必须开启 HTTPS并限制管理员 IP 白名单。Prometheus 默认没有认证机制生产环境建议在前面加 Nginx 反向代理做 Basic Auth。Grafana 开启匿名访问限制不同团队之间的看板通过 Organization 隔离。所有监控脚本中的数据库密码、Webhook 地址等敏感信息不要明文写在配置文件里使用环境变量或密钥管理工具注入。7.5 监控系统自身的可观测性这里有一个经典悖论监控系统挂了谁来监控监控建议至少做到两点Zabbix Server 和 Prometheus 自身进程使用 systemd 托管配置 Restarton-failure。将 Zabbix Server 和 Prometheus 的关键指标进程存活、数据采集延迟互相监控形成交叉验证。8. 总结与学习路线本文从企业监控的真实需求出发完整拆解了 Zabbix 和 Prometheus 两套主流技术栈从基础概念到服务端安装、被监控端接入、告警规则配置、通知对接、常见问题排查最后补充了监控体系设计的工程建议。学完本文你应该已经掌握了Zabbix 的架构、数据库初始化、Agent 接入流程。Prometheus 的 Pull 模型、Exporter 机制和 PromQL 基础。Grafana 数据源接入和仪表盘导入。两种监控体系的告警配置路径和通知方式。监控数据保留、容量规划和告警质量控制的经验方法。下一阶段建议你按这个路线继续深入学习在真实服务器上完整部署一遍 Zabbix 或者 Prometheus不要只看不练。用 Zabbix SNMP 监控一台真实交换机或路由器理解网络设备监控和服务器监控的区别。学习 PromQL 的高级聚合操作比如rate()、increase()、histogram_quantile()。尝试用 Docker Compose 搭建一套完整的 Prometheus Grafana Alertmanager 环境。阅读 Kubernetes 官方文档中关于 Metrics Server 和 kube-state-metrics 的内容逐步进入云原生监控领域。监控系统的学习曲线确实不短但它是运维工程师最值得投入的方向之一。一个人可能不需要精通所有技术栈但只要能独立把一套监控从零搭起来并稳定运行你对整个系统的理解就会提升一个档次。遇到报错不要慌按日志、端口、配置、权限四个方向去排查大多数问题都能解决。如果本文对你有帮助可以收藏备用也可以转发给身边正在学习监控的朋友。后面我会继续更新 Zabbix 模板定制、Prometheus 云原生监控、Grafana 高级面板设计等实战内容欢迎保持关注。