在企业级 IT 运维中Zabbix 和 Prometheus 是当前出现频率最高的两套监控体系。Zabbix 擅长对传统服务器、虚拟机、数据库和网络设备做集中式采集与告警Prometheus 则面向 Kubernetes、微服务和时序指标天生适合云原生场景。运维工程师如果不是只负责某一种固定环境通常迟早要同时接触这两套工具。很多入门同学容易卡在同一个地方看着教程装完 Zabbix 或 Prometheus却不知道模板、监控项、抓取任务、告警规则之间到底是什么关系一旦监控没数据或告警不触发只能反复重启服务碰运气。这篇教程会按“定位差异 - 安装部署 - 落地配置 - 参数调优 - 故障排查 - 生产实践”的顺序把两套体系从零讲清楚并给出可以直接照做的最小案例。学完后你至少能独立完成一次完整的 Zabbix 主机监控、一次 PrometheusGrafana 的指标监控与告警配置并具备排查常见监控问题的基本思路。1. 先搞清楚 Zabbix 与 Prometheus 的定位差异再决定学哪一套1.1 为什么企业监控需要两套体系一个常见的误解是“学了 Zabbix 就不需要 Prometheus或者 Prometheus 会取代 Zabbix”。实际上两者解决的问题在很多时候是互补的。Zabbix 是典型的“集中式采集 主动推送 数据库存储”模型。它通过 agent 或 SNMP 把数据收集到 server并写入关系型数据库MySQL/PostgreSQL界面里可以直接配置主机组、模板、触发器、告警动作。这种设计非常适合传统 IDC 环境比如几十台 Windows/Linux 服务器、核心交换机、路由器、UPS、数据库实例它们需要稳定、可预期的采集周期以及复杂的告警依赖关系。Prometheus 采用拉模式pull和时序数据库TSDB服务端按固定间隔主动抓取目标暴露的 HTTP 指标端点并直接在内存和本地磁盘中保存时序数据。它还内置服务发现可以与 Kubernetes、Consul、云平台联动自动发现新增的 Pod 或节点。对于容器化业务、Spring Boot 应用、Redis、MySQL 这类需要暴露大量业务指标的场景Prometheus 生态更自然。实际企业的监控拓扑往往是“Zabbix 管底座Prometheus 管云原生和业务”两套系统并存最后通过统一告警平台或展示大屏合并到一起。1.2 核心架构和数据模型对比要理解两者差异最有效的方式是放在一张表里对比关键维度。对比项ZabbixPrometheus监控模式集中式 server/proxy/agent拉模式 服务发现数据存储MySQL/PostgreSQL 等关系库本地 TSDB可扩展远端存储数据模型监控项 item以 key 标识指标名 标签label采集方式Agent 主动/被动、SNMP、IPMI、JMXHTTP 指标端点 exporter查询语言界面筛选、聚合无统一查询语言PromQL告警机制触发器 动作 告警媒介告警规则 Alertmanager适合场景传统服务器、虚拟机、网络设备Kubernetes、微服务、应用业务指标扩展生态模板丰富偏传统基础设施exporter 和云原生集成丰富学习难点模板、触发器、宏、动作概念多PromQL、标签设计、抓取任务划分从这个表可以看出Zabbix 更像“监控平台”开箱即用把设备、采集、存储、告警全包了Prometheus 则更像“监控核心”需要你主动设计指标入口、抓取目标和告警规则。二者不是二选一的关系而是适用场景不同。还有一个容易忽略的差异是数据可靠性。Zabbix 历史数据写入数据库后查询和报表非常直观但数据库膨胀和写并发是大问题。Prometheus 把数据压缩在本地 TSDB查询通过 PromQL 完成单体模式下不依赖外部数据库部署更轻但在多副本、长期存储、权限隔离方面需要额外组件配合。1.3 选型建议与组合方式在实际企业里建议按环境现状选型而不是按“哪个更流行”选型。如果公司有几十台 Linux/Windows 服务器、多个机房、大量网络设备和 UPSZabbix 的静态配置和模板体系能显著降低日常维护成本。如果核心业务已经容器化跑在 Kubernetes 之上需要按 Pod、Service、Ingress 粒度观察那么 Prometheus 几乎是标配。两者都有的时候可以把 Zabbix 作为基础设施监控底座把 Prometheus Grafana 作为云原生和业务指标展示层。告警统一推送到同一个钉钉群或企业微信机器人避免运维人员在多个平台之间来回切换。组合架构并不复杂关键是先把各自的边界画清楚Zabbix 负责“设备在不在、网络通不通、磁盘空间够不够”Prometheus 负责“接口延迟、Pod 重启次数、JVM 堆内存、Redis 命中率”。边界清晰后后续的告警规则和值班响应才不会互相干扰。2. 环境准备安装部署不是越快越好要先把条件确认清楚2.1 最小学习环境与生产环境要求监控系统本身也是基础设施安装前先确认资源。作为学习环境一台 8C16G 的 Linux 虚拟机可以同时跑 Zabbix、Prometheus、Grafana 和若干 exporter。生产环境不建议这样混装至少要把 Zabbix Server 和 Prometheus 拆开数据库单独规划。环境建议配置说明学习环境1 台虚拟机8C16G磁盘 100G装完所有组件跑通最小案例Zabbix Server 生产4C8G 起步磁盘按历史数据量规划数据库建议独立实例开启定时备份Prometheus 生产4C8G 起步本地磁盘预留 30 天以上抓取目标越多内存和磁盘占用越大监控对象按需安装 agent/exporter注意采集端口安全暴露范围操作系统方面Zabbix 官方对主流 Linux 发行版都有仓库支持文中以 Rocky Linux 9 / AlmaLinux 9 为例Prometheus 是 Go 编写的单二进制官方提供 linux-amd64 包任何主流发行版都能运行。如果手头是 Ubuntu命令风格略有差异但思路一致。2.2 安装 Zabbix Server 与 Agent以 Rocky Linux 9 为例安装 Zabbix 最省事的方式是使用官方仓库。下面命令是一套最小安装过程实际版本以安装当天的官方仓库为准。# 安装 Zabbix release 包会注册官方 yum 仓库 dnf install -y https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-1.el9.noarch.rpm # 安装 Zabbix Server、Web 前端、PostgreSQL 相关组件和 agent2 dnf install -y zabbix-server-pgsql zabbix-web-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2Zabbix 7.0 默认支持 PostgreSQL使用独立数据库能避免 MySQL 权限和编码问题。初始化数据库的常用方式如下# 安装并初始化 PostgreSQL dnf install -y postgresql-server postgresql-setup --initdb # 启动 PostgreSQL systemctl enable --now postgresql # 创建 Zabbix 数据库用户和库 sudo -u postgres psql -c CREATE USER zabbix WITH PASSWORD zabbix_pwd; sudo -u postgres createdb -O zabbix zabbix然后导入 Zabbix 自带的数据表结构。不同版本导入命令略有不同通常是在 zabbix-sql-scripts 包内zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix导入完成后编辑/etc/zabbix/zabbix_server.conf配置数据库连接信息并确认时区配置DBHostlocalhost DBNamezabbix DBUserzabbix DBPasswordzabbix_pwd接着配置 Nginx 提供 Web 界面。修改/etc/nginx/conf.d/zabbix.conf中的listen和server_name把默认值改成实际 IP 或域名然后启动服务systemctl enable --now zabbix-server zabbix-agent2 nginx php-fpm安装完成后浏览器访问http://服务器IP/zabbix。首次进入会要求选择语言、连接数据库、确认配置最后生成前端配置文件。整个安装过程不算复杂但最容易出错的是数据库导入失败或 Nginx 配置没有生效。Zabbix Agent 不一定只在被监控机器上单独安装。为了验证最小链路可以在同一台机器上让 agent2 连接 server。生产环境则需要在每台目标主机上安装 agent并开放10050端口让 Zabbix Server 能主动访问。2.3 安装 Prometheus、node_exporter 和 GrafanaPrometheus 的安装更轻量。先到官方 Release 页面找到当前稳定版本推荐设置一个变量来统一版本号这样后续升级命令也容易维护。export PROM_VERSION2.53.0 wget https://github.com/prometheus/prometheus/releases/download/v${PROM_VERSION}/prometheus-${PROM_VERSION}.linux-amd64.tar.gz tar -xzf prometheus-${PROM_VERSION}.linux-amd64.tar.gz cd prometheus-${PROM_VERSION}.linux-amd64 # 先看一眼默认配置再启动 ./prometheus --config.fileprometheus.yml默认配置已经有一个prometheusjob会抓取 Prometheus 自身的指标。浏览器访问http://服务器IP:9090能看到 Prometheus Web UI说明部署成功。node_exporter 是采集主机指标的标准 exporter同样从官方 Release 页面下载。为了便于管理可以复制到/usr/local/bin并用 systemd 托管。export NODE_EXPORTER_VERSION1.8.2 wget https://github.com/prometheus/node_exporter/releases/download/v${NODE_EXPORTER_VERSION}/node_exporter-${NODE_EXPORTER_VERSION}.linux-amd64.tar.gz tar -xzf node_exporter-${NODE_EXPORTER_VERSION}.linux-amd64.tar.gz cp node_exporter-${NODE_EXPORTER_VERSION}.linux-amd64/node_exporter /usr/local/bin/ # 创建 systemd 服务 cat /etc/systemd/system/node_exporter.service EOF [Unit] DescriptionNode Exporter Afternetwork.target [Service] Userroot ExecStart/usr/local/bin/node_exporter --web.listen-address:9100 Restartalways [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now node_exporter访问http://服务器IP:9100/metrics会看到大量node_前缀的指标。这个过程建议手动跑一遍能帮助理解“exporter 暴露指标Prometheus 定期过来抓取”的基本链路。Grafana 可以单独安装。官方仓库方式最常用cat /etc/yum.repos.d/grafana.repo EOF [grafana] namegrafana baseurlhttps://packages.grafana.com/oss/rpm repo_gpgcheck1 enabled1 gpgcheck1 EOF dnf install -y grafana systemctl enable --now grafana-server安装完成后访问http://服务器IP:3000默认账号密码是admin/admin首次登录会提示修改密码。Grafana 本身不采集数据它负责把 Prometheus 或 Zabbix 的数据可视化。2.4 安装完成后的联通性检查服务全部启动后不要急着开始配置。先用一组命令确认链路通了# 检查端口监听状态 ss -lntp | grep -E 10051|10050|9090|9100|3000|80 # 检查 Prometheus target 是否正常 curl http://127.0.0.1:9090/api/v1/targets | head -n 50 # 检查 node_exporter 指标 curl http://127.0.0.1:9100/metrics | head -n 20 # 检查 Zabbix Server 日志是否有数据库错误 tail -n 100 /var/log/zabbix/zabbix_server.log如果端口没监听先看服务状态再查日志。运维职业习惯里不要只看服务是否 active要确认端口、数据、页面三个层面都正常。3. Zabbix 实际落地从添加第一台主机到收到告警3.1 添加主机并验证 Agent 数据Zabbix Web 界面安装成功后需要先配置默认语言和时区。然后在左侧菜单进入“数据采集 - 主机”点击“创建主机”。创建主机时需要填写几个关键字段主机名称建议与服务器主机名一致便于定位。模板选择Linux by Zabbix agent active模板会自动带上 CPU、内存、磁盘、网络等监控项。主机组先建一个业务组例如“生产服务器”。接口添加 Agent 接口IP 写被监控机器地址端口默认10050。保存后主机状态如果是灰色说明还没有收到数据。可以等 1 到 2 个刷新周期然后进入“监测 - 最新数据”按主机名筛选如果看到 CPU、内存、磁盘等指标有值说明 Agent 到 Server 的链路已经通了。这里最容易犯的错误是模板选成了Linux by Zabbix agent active但 Agent 配置文件里的ServerActive没写对或 agent 服务没起来。Zabbix Server 与 Agent 的通信方式分为被动检查和主动检查模板名称里的 active 意味着 Agent 主动连接 Server而不是 Server 主动轮询。如果是主动模式Agent 配置里必须指定ServerActive和Hostname并且Hostname要与 Web 界面创建的“主机名称”完全一致。3.2 使用模板和自定义监控项监控 Linux 与交换机模板是 Zabbix 最核心的使用方式。模板把监控项、触发器、图形、应用集打包在一起一个模板可以同时链接到多台主机。生产环境里有几十台同类服务器时不必一台一台配置监控项只需要统一链接模板。如果模板自带的监控项不满足业务需求可以自己创建监控项。例如要监控根分区可用百分比可以在主机上添加一个 Zabbix Agent主动类型的监控项名称根分区可用百分比类型Zabbix Agent主动Keyvfs.fs.size[/,pfree]信息类型浮点数更新间隔60s这种自定义监控项会在“最新数据”里产生一个值为百分比的数据点可以继续为它创建触发器例如低于 10% 时告警。监控交换机与监控服务器不同需要走 SNMP。以常见 H3C/华为交换机为例先打开 SNMP 只读社区名并允许监控服务器访问# H3C 示例具体命令以设备型号为准 snmp-agent snmp-agent sys-info version v2c snmp-agent community read monitor2026 snmp-agent sys-info contact engineer在 Zabbix 中给交换机创建主机时不再添加 Agent 接口而是添加 SNMP 接口填入管理 IP 和端口 161。模板选择Networks H3C SNMP或Networks by SNMP。配置完成后去“最新数据”里看接口流量、CPU、内存是否有值。SNMP 监控最容易出现的问题是设备返回大量接口索引导致数据过多建议先只启用需要的模板项再逐步扩展。3.3 配置邮件与钉钉告警并验证触发器Zabbix 的告警链路是“触发器 - 动作 - 告警媒介 - 用户/群组”。没有动作和媒介触发器即使在“问题”状态也不会发出通知。先配置告警媒介。在“用户 - 用户”里选择一个用户点击“告警媒介 - 添加”。邮件媒介最简单的配置是使用 SMTP 服务器也可以使用 Zabbix 自带的脚本媒介。钉钉告警更常见方法是先在钉钉群添加一个自定义机器人获取 Webhook 地址然后在 Zabbix 中新增媒介类型调用一个发消息脚本。下面是一个最简化的 Zabbix 钉钉通知脚本示例实际生产脚本需要补充异常处理和日志#!/bin/bash # /usr/lib/zabbix/alertscripts/dingtalk.sh message$1 webhookhttps://oapi.dingtalk.com/robot/send?access_tokenREPLACE_YOUR_TOKEN curl -s -H Content-Type: application/json \ -d {\msgtype\: \text\, \text\: {\content\: \${message}\}} \ $webhook脚本写入后要设置执行权限chmod x /usr/lib/zabbix/alertscripts/dingtalk.sh然后在 Zabbix“告警 - 媒介类型”里添加“钉钉”类型设置脚本参数为{ALERT.MESSAGE}。接着创建用户并关联媒介最后在“告警 - 动作”里创建触发器动作条件是“触发器严重性高于一般”操作里选择发送给对应的用户或群组。验证告警最简单的方式是手动停止一个 Agent 或关掉被监控机的网络等触发器状态变成“PROBLEM”观察动作日志里是否出现“已发送”。如果发送失败Zabbix 的动作日志会显示具体错误这是排查告警的首选入口。3.4 多主机批量添加与 Proxy 扩展当主机数量超过两三百台Zabbix Server 单独轮询所有节点会出现网络和进程压力。官方推荐部署 Zabbix Proxy把采集压力分散到各机房或网段。安装 Proxy 的思路与 Server 类似需要独立的数据库然后配置/etc/zabbix/zabbix_proxy.confServerZABBIX_SERVER_IP Hostnameproxy-01 DBNamezabbix_proxy DBUserzabbix_proxy DBPasswordproxy_pwd代理部署完后在 Web 界面“数据采集 - 代理”里添加代理并在创建主机时选择“由代理监控”。这样所有 Agent 数据先汇集到 Proxy再由 Proxy 转发给 Zabbix Server适合多地机房场景。批量添加主机可以通过“自动发现”规则也可以使用 Zabbix API。下面是一个极简 API 调用示例先获取 token再创建主机curl -s -X POST http://127.0.0.1/zabbix/api_jsonrpc.php \ -H Content-Type: application/json \ -d {jsonrpc:2.0,method:user.login,params:{username:Admin,password:zabbix},id:1}拿到 token 后继续调用host.create等接口。实际脚本中用到的 URL、认证信息和主机参数建议通过配置文件或变量管理不要把密码写死在命令行里。4. Prometheus 实际落地从配置抓取到 Grafana 大盘4.1 理解 prometheus.yml 的三个核心段落Prometheus 的配置集中在prometheus.yml。新手首要任务不是背配置而是理解三个核心段落global全局抓取间隔、评估间隔。rule_files告警规则和预计算规则文件。scrape_configs需要抓取的目标列表。一个最小配置如下global: scrape_interval: 15s evaluation_interval: 15s rule_files: - rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node-exporter static_configs: - targets: [192.168.1.10:9100, 192.168.1.11:9100]抓取目标里的 IP 和端口等价于告诉 Prometheus“每隔 15 秒去这些地址的/metrics路径读取一次指标”。如果服务部署在 Kubernetes可以把static_configs替换成kubernetes_sd_configs让 Prometheus 自动发现 Pod 和 Node。配置修改后不要直接 kill 进程。推荐先用promtool做一次校验./promtool check config prometheus.yml校验通过后通过kill -HUP prometheus_pid或systemctl reload prometheus热加载配置。4.2 用 node_exporter 采集主机指标并配置磁盘告警node_exporter 暴露的指标很多磁盘相关核心指标包括node_filesystem_size_bytes文件系统总大小。node_filesystem_avail_bytes文件系统可用大小。node_filesystem_readonly文件系统是否只读。磁盘使用率通常用如下 PromQL 计算(1 - node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100要配置磁盘告警需要创建告警规则文件rules/disk.ymlgroups: - name: disk-alerts rules: - alert: DiskUsageHigh expr: | (1 - node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100 80 for: 5m labels: severity: warning annotations: summary: Root partition usage high on {{ $labels.instance }} description: Current value is {{ $value }}%这里for: 5m的意思是持续 5 分钟超过阈值才触发告警避免磁盘容量瞬时抖动造成误报。{{ $labels.instance }}会动态替换成实际抓取目标是告警文案中最常用的模板变量。配置完成后在prometheus.yml里通过rule_files引入这个文件然后在 Prometheus Web UI 的“Alerts”页面可以看到规则状态。当表达式持续满足 5 分钟该规则会从inactive变为pending再到firing。只有firing状态才会交给 Alertmanager 发送通知。4.3 Alertmanager 接入钉钉或邮件并避免告警风暴Alertmanager 是独立的二进制组件负责接收 Prometheus 推送过来的告警然后做分组、抑制、静默最后通过 webhook、邮件等方式发送出去。最小配置alertmanager.yml如下route: receiver: default-receiver group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receivers: - name: default-receiver email_configs: - to: opsexample.com from: alertexample.com smarthost: smtp.example.com:465 auth_username: alertexample.com auth_password: SMTP_PASSWORD send_resolved: trueAlertmanager 的分组机制很关键。group_by: [alertname, instance]会把同一告警名和同一实例的告警合并成一条通知避免在集群故障时几百台机器同时发声。repeat_interval: 4h表示已经通知过的告警每隔 4 小时再重复一次不是每次评估都重复发。钉钉接入同样使用 webhook。可以把webhook_configs指向一个本地转发脚本或钉钉官方机器人地址receivers: - name: dingtalk-receiver webhook_configs: - url: http://127.0.0.1:8899/alert/send如果直接使用钉钉机器人 Webhook需要把告警 JSON 转换成钉钉要求的消息格式。很多团队会在本地写一个小 http 服务专门做格式转换和加签名这样 Prometheus 侧只负责把告警事件传给本地服务安全性和可维护性更好。4.4 扩展到 Redis 集群与 Kubernetes 监控主机监控只是 Prometheus 的起点。同样的抓取逻辑可以覆盖中间件和云原生应用。监控 Redis 集群可以使用 redis_exporter每个 Redis 节点暴露9121端口然后在prometheus.yml里增加一个 jobscrape_configs: - job_name: redis-exporter static_configs: - targets: - 192.168.1.20:9121 - 192.168.1.21:9121 - 192.168.1.22:9121如果 redis_exporter 以 sidecar 方式部署在 Kubernetes Pod 里可以通过 Pod 注解自动发现配置方式又会不同。这里最重要的是理解“任何暴露/metrics的端点都可以通过 scrape_configs 接入 Prometheus”中间件监控因此变得标准化。Kubernetes 监控通常使用 kube-prometheus-stack 或 prometheus-operator。这套方案把 Prometheus、Alertmanager、Grafana、node_exporter、kube-state-metrics 等组件打包成 Helm Chart部署后自带 K8s 核心组件监控。在真实生产环境里K8s 集群监控很少手动下载二进制去部署而是用 Operator 管理配置、服务发现和告警规则。如果只是学习可以先在一台虚拟机里用 Kind 或 K3s 模拟集群再安装 kube-prometheus-stack。重点观察 kube-state-metrics 提供的数据例如 Pod 重启次数、Deployment 副本数和 Node 状态# 过去 10 分钟内 Pod 重启次数 increase(kube_pod_container_status_restarts_total[10m])这类查询对排查容器频繁重启问题非常有用。5. 关键参数深度解读出现告警别急着加机器先看这些参数5.1 Zabbix 历史同步进程过高很多 Zabbix 维护人员在日志里看到过这样一条告警Zabbix server: utilization of history syncer processes over 75%。这个告警并不是说磁盘满了而是历史数据写入数据库的速度跟不上服务端接收数据的速度。Zabbix Server 的 data sender 进程会把监控项历史数据批量写入数据库历史同步进程由StartHistoryPollers和StartDBSyncers等参数控制。默认值偏保守当监控项数量很多、Agent 主机大量使用主动模式时数据同步队列容易被占满。先检查 Zabbix Server 日志看看是否频繁出现如下关键行history syncer #1 reached 75% of read lock timeout检查当前参数grep -E ^StartHistoryPollers|^StartPollers|^CacheSize /etc/zabbix/zabbix_server.conf常见调整方向如下表参数默认值影响调优建议StartPollers5被动agent采集线程数主机较多时增大到 20-50StartPollersUnreachable1不可达网络轮询线程数网络不稳定时可增大StartHistoryPollers4历史数据写入线程数历史同步告警时增大到 8-16CacheSize8M配置缓存大小主机、监控项多时增大到 512MHistoryCacheSize64M历史数据缓存数据量大时增大到 256M 以上调完参数后要重启zabbix-serversystemctl restart zabbix-server注意单纯调大参数只解决临时瓶颈。如果数据库磁盘性能差、历史数据保留太久、每台主机的监控项过多就算调大线程数据迟早还是会积压。更合理的做法是减少无用监控项、调整历史数据保留天数、把低频指标改成主动模式或者拆分多个 Zabbix Proxy。5.2 Prometheus 的抓取间隔、评估间隔和存储参数Prometheus 的关键参数表面上没有 Zabbix 那么多但一样需要理解。scrape_interval控制抓取频率。抓得越短数据点越密占用的磁盘和内存越多抓得太长可能出现指标突变捕捉不到。通用建议是主机层用 15s关键业务接口用 10s 到 30s不重要的指标降低到 60s。不要所有 job 都用 1s成本会线性上升。evaluation_interval控制告警规则的计算频率一般和抓取间隔保持一致即可。存储相关参数在启动命令中配置./prometheus \ --config.fileprometheus.yml \ --storage.tsdb.path/data/prometheus \ --storage.tsdb.retention.time30d \ --storage.tsdb.retention.size100GBretention.time和retention.size一旦配置Prometheus 会尽量同时满足两个限制。只配置 time磁盘可能被写满只配置 size历史时间可能没有达到预期天数就被删除。建议两个参数都设置给生产环境设定一个上限。5.3 从默认值到生产调优的取舍学习环境用默认参数不会出大问题但生产环境至少要做好三件事第一监控项和指标数量要可控。Zabbix 每台主机关联模板后可能有几十上百个监控项Prometheus 一个 node_exporter 默认暴露上千条指标。要定期整理不需要的指标减少存储压力。第二历史数据周期要明确。Zabbix 默认保留历史 90 天趋势 365 天Prometheus 默认保留 15 天。保留时间越长对存储和查询性能的要求越高。建议先确认业务到底需要回看多长的监控数据再配置保留策略。第三容量评估要留余量。监控数据是持续写入的生产环境启动前就要规划好磁盘比如按“每天约 2GB”估算是可能出现的。实际容量取决于指标数量和采样频率上线后观察一周再对保留周期做调整。6. 监控故障排查从没数据、不告警到误报的处理思路6.1 Zabbix 常见问题与排查步骤Zabbix 告警不触发或没数据很多人第一件事就是重启服务但更好的顺序是“先看数据再看日志再改配置”。问题现象常见原因检查方式处理建议Agent 显示红色无数据Agent 未启动、防火墙挡 10050、接口配置错systemctl status zabbix-agent2ss -lntp修复端口启动 agent主动模式无数据ServerActive或Hostname不匹配查看 agent 日志确认配置修改 agent 配置并重启SNMP 交换机无数据团体名错误、设备禁用 SNMP、防火墙挡 UDP 161snmpwalk -v2c -c monitor2026 IP在设备上开启 SNMP触发器状态一直正常表达式阈值单位不对到“最新数据”看实际值调整触发器表达式历史同步进程超 75%监控项多、数据库慢、线程不足看 server 日志调节StartHistoryPollers告警动作没发送用户没关联媒介、动作条件不匹配看“动作日志”修正动作和用户配置最直接的数据链路测试命令是zabbix_get。在 Zabbix Server 上手动跑一次能立刻判断 agent 是否可达zabbix_get -s 192.168.1.10 -k system.cpu.load如果这条命令能返回值说明 agent 和 server 网络层是通的问题多半在 Web 界面配置如果命令超时优先排查防火墙和安全组。6.2 Prometheus 常见问题与排查步骤Prometheus 的核心排查入口在 Web UI 的两个页面/targets和/alerts。问题现象常见原因检查方式处理建议Target DOWNexporter 没启动、端口不通、抓取路径不对看 target 页面的 error 信息修复 exporter确认监听地址图表无数据指标名错误、标签不匹配、时间范围不对在 Graph 页手动输入 PromQL用curl检查 metrics 内容告警不触发规则未加载、表达式结果为空、for 未满足看/alerts页面规则状态promtool check rules调整表达式PromQL 查询超时数据量过大、标签基数过高检查查询时长缩小时间范围增加准确标签磁盘写满样本量超过预期、保留策略没配置查看磁盘df -h配置 retention或接入远端存储Prometheus 配置加载失败会直接导致启动异常运行时修改配置也容易引入语法错误。因此修改配置后一定要先跑./promtool check config prometheus.yml ./promtool check rules rules/disk.yml6.3 日志、端口与测试命令检查清单无论用哪套监控系统排错顺序都可以固定为输入 - 网络 - 服务 - 配置 - 数据。输入是指被监控对象是否真的产生了指标或数据网络是指采集端口是否可达服务是指 agent、server、exporter 进程是否正常配置是指模板、规则、触发器是否匹配数据是指最终库里有没有最新记录。一个可复用的检查清单如下检查被监控对象状态ping、systemctl status。检查端口ss -lntp | grep -E 10050|10051|9090|9100|3000。检查 HTTP 端点curl http://IP:9100/metrics。检查日志Zabbix 看/var/log/zabbix/Prometheus 看启动输出的日志和 web 页面。检查配置promtool check configZabbix Web 配置页检查模板和宏。检查数据Zabbix 看“最新数据”Prometheus 用promql查询。这套清单在生产环境里可以固化成操作手册避免每次故障都从零开始猜。7. 企业级监控最佳实践稳定、安全、可运维7.1 区分测试、生产设计监控数据生命周期测试环境可以随便折腾生产环境要提前设计。监控数据生命周期至少包含采集、存储、归档、清理四个阶段。Zabbix 的 housekeeper 会自动清理超过保留期限的历史数据Prometheus 根据 retention 策略清理 TSDB 数据。生产环境上线前就要明确“历史 30 天趋势、保留关键月份报表”这类需求否则运行半年后磁盘会被写满。建议把监控数据按重要程度分两层实时告警数据保留短周期如 30 天周报月报依赖的统计数据单独汇总到报表系统。不要让所有原始数据无限期存在同一个存储里。7.2 告警治理分级、分组、抑制、静默监控做得越全告警越多。没有分级的告警体系最终会让人对告警麻木。在 Zabbix 中触发器可以设置“灾难、严重、一般、警告”等严重性。动作可以按严重性分别处理例如“灾难”发短信和电话“警告”只发邮件。在 Prometheus 中告警规则里的labels.severity承担同样的作用Alertmanager 路由可以根据 severity 走不同的 receiver。告警分组和抑制是减少告警风暴的利器。当同一个交换机宕机时下面几十台服务器可能同时不可达如果不分组值班手机会被刷爆。Alertmanager 通过group_by合并相同告警Zabbix 通过配置“依赖触发器”让同一网络下的主机在根因设备故障时不再重复告警。静默机制也很重要。计划内维护、发布窗口期间主动静默相关告警避免误报。Zabbix 可以在维护期间停止发送通知Alertmanager 可以使用 Silences 页面创建静默规则。7.3 安全加固SNMP、认证、TLS 与 Webhook 签名监控系统涉及大量网络入口如果不加固很容易被当作资产扫描和攻击的入口。至少做到以下几条SNMP 不要使用public或private这类默认团体名监控目标建议限制只允许监控服务器 IP 访问。Zabbix Web 界面不要使用默认密码生产环境应该启用强密码策略并通过 HTTPS 访问。Prometheus 如果暴露在非安全网络需要在前面加认证。可以用 Nginx 做 basic auth或启用 Prometheus 的--web.config.file配置内置认证和 TLS。Alertmanager 的 webhook 地址要避免放在公开配置里最好通过本地转发服务并加入签名或 token。被监控主机上的 agent/exporter 端口应尽量限定在运维网段不要将9100暴露到公网。安全属于监控体系里最容易被忽略的部分但它决定监控系统本身会不会成为事故扩大器。7.4 备份、升级与回滚方案监控系统挂了不会影响业务数据但会影响故障发现能力所以同样需要备份。Zabbix 的配置和告警状态都在数据库里备份 MySQL/PostgreSQL 即可。Prometheus 的多数配置是 YAML 文件把文件纳入版本管理告警规则可以走 Git 评审流程。指标数据量通常很大不推荐常规备份建议通过保留策略和远端存储解决长期保存问题。升级前至少做两件事备份配置和数据库快照记录当前版本与升级目标版本之间的兼容性说明。无论是 Zabbix 还是 Prometheus升级后都要重点验证“数据采集是否正常、告警是否触发、图表是否还能查到历史数据”。回滚方案不是上线才写而是从第一次部署到生产环境时就要准备好。8. 从入门到精通给运维工程师的练习路径8.1 六周练习清单把零散教程变成能力最有效的方法是给自己安排一个固定练习周期。周次练习目标完成标准第 1 周安装 Zabbix Server Agent能在 Web 界面看到一台 Linux 主机的 CPU、内存、磁盘数据第 2 周配置模板和触发器手动停掉 Agent 后能在 5 分钟内收到邮件或钉钉告警第 3 周安装 Prometheus node_exporter Grafana能通过 Grafana