1. 这不是选“谁更好”而是搞清“谁在解决什么问题”Prometheus 和 Zabbix这两个词最近在运维、SRE、云原生工程师的聊天记录里出现频率高得离谱。我上个月帮三家客户做监控体系重构有家传统金融公司刚把 Zabbix 从 4.0 升到 6.4结果发现容器指标采集延迟严重、告警风暴压垮数据库另一家互联网创业公司用 Prometheus Grafana 搭了整套 K8s 监控但业务部门反馈“看图很炫查个 Java 应用 GC 频次要翻 5 个面板”第三家是混合云环境物理机、VM、K8s 集群、边缘网关全都有他们直接把两个平台并存靠脚本做数据桥接——结果告警规则维护成本翻了三倍。这不是技术站队而是两种设计哲学的碰撞。Zabbix 是从 2001 年就扎根在物理服务器时代的“老派工程师”它信奉“所有设备都该被统一建模、统一纳管、统一告警”所以它的 Web 界面自带资产台账、自动发现、模板继承、宏变量、历史趋势图、SLA 报表——你甚至能用它给打印机卡纸发微信通知。而 Prometheus 是 2012 年诞生于 SoundCloud 的“云原生原住民”它只相信一件事指标必须是拉取pull的、时序的、带标签的、可聚合的。它不关心你服务器型号只关心http_request_duration_seconds_sum{jobapi-gateway, instance10.2.3.4:8080, status_code500}这个指标在过去 5 分钟涨了多少。关键词里反复出现的prometheus、zabbix、监控平台、容器监控、K8s其实已经划出了分水岭如果你的系统里还有大量 Windows Server、IBM AIX、H3C 交换机、海康威视摄像头Zabbix 的 SNMP/ICMP/JMX/ODBC 插件生态就是你的护城河但如果你的交付物是 Helm Chart、CI/CD 流水线里跑着kubectl apply -f prometheus-rules.yaml那 Prometheus 的 ServiceMonitor、PodMonitor、Relabeling 机制就是你呼吸的空气。我见过太多团队踩坑不是因为技术差而是没想清楚一个问题你到底是在监控“基础设施”还是在监控“服务行为”前者关注“CPU 是否超 85%”“磁盘剩余是否少于 10G”“端口是否通”后者关注“订单创建接口 P99 延迟是否突破 800ms”“支付成功率是否低于 99.95%”“库存扣减失败率是否突增”。Zabbix 天然擅长前者Prometheus 天然擅长后者。这篇文章不给你标准答案而是带你拆开两台“监控发动机”的活塞、曲轴和油路让你自己判断哪台更适合你正在跑的那辆卡车。2. 架构基因决定能力边界从数据模型到扩展方式2.1 数据模型标签 vs 属性这是根本分歧Zabbix 的数据模型是典型的“关系型思维”。每个监控项item属于一个主机host主机属于一个主机组host group主机又关联多个模板template。指标本身是扁平的system.cpu.util[,idle]、net.if.in[eth0]、vm.memory.size[available]。这些字符串背后没有结构化语义只是约定俗成的命名规范。你要查“所有 Web 服务器的 5 分钟平均 CPU 使用率”得写 SQL 式查询select avg(value) from history where itemid in (select itemid from items where hostid in (select hostid from hosts_groups where groupid xxx) and key_ system.cpu.util[,avg5]) and clock unix_timestamp() - 300。Zabbix 5.0 虽然引入了“低级别发现LLD”生成动态键值但本质仍是静态模板的批量克隆。Prometheus 则彻底拥抱“多维数据模型”。每个指标是一个时间序列由指标名称metric name和一组键值对标签label set唯一标识。http_requests_total{jobprometheus, instancelocalhost:9090, code200, handler/graph}这个字符串本身就是完整语义它不是一个孤立数字而是一条带上下文的“事件流”。你可以用sum by (job, handler) (rate(http_requests_total{code~5..}[5m]))一句话算出所有服务中各接口的 5xx 错误率并按服务名和路径聚合。这种能力不是靠后台 SQL 实现的而是存储引擎TSDB原生支持的倒排索引时间窗口计算。提示Zabbix 的“宏”如{$SNMP_COMMUNITY}和 Prometheus 的“relabeling”看起来都是变量替换但逻辑完全不同。Zabbix 宏是配置时的文本替换发生在数据入库前Prometheus relabeling 是采集时的实时标签重写发生在 scrape 到 target 之后、存入 TSDB 之前且支持正则提取、哈希计算、条件跳过等复杂逻辑。这是架构层级的差异无法通过插件弥补。2.2 数据采集拉取Pull与推送Push的哲学之争Zabbix 支持两种模式Agent 主动上报push和 Server 主动轮询pull。但实际生产中90% 的场景用的是 Agent 模式。Zabbix Agent 安装在被监控主机上定期执行脚本、读取/proc、调用 WMI然后把结果打包发给 Server。这种方式的好处是网络穿透简单只需 Agent 出向连接、资源占用可控Agent 自身内存10MB、兼容性极强Windows/Linux/AIX 全支持。坏处也很明显Agent 版本升级需逐台操作、自定义监控项要写脚本并分发、大规模部署时 Agent 心跳包可能压垮 Server 数据库。Prometheus 只认一种模式Server 主动拉取pull。它不接受任何主动上报的数据除非通过 Pushgateway 这个妥协方案。它的核心假设是现代云环境里服务发现Service Discovery比静态 IP 列表更可靠HTTP 接口比二进制协议更易调试拉取比推送更利于故障隔离。当你在 K8s 里部署一个新 PodPrometheus 通过 API Server 发现它检查其/metrics端点发起 HTTP GET 请求拿到文本格式的指标如# HELP http_requests_total The total number of HTTP requests.\n# TYPE http_requests_total counter\nhttp_requests_total{methodpost,code200} 1027\nhttp_requests_total{methodget,code200} 3042解析后存入本地 TSDB。整个过程无需在目标端安装任何代理只要暴露一个 HTTP 端点即可。注意很多人误以为 “Prometheus 不支持 Windows”其实是误解。Prometheus 官方提供了 windows_exporter它就是一个标准的 HTTP 服务监听localhost:9182/metrics返回 Windows 性能计数器数据。你不需要在每台 Windows 服务器上配 Zabbix Agent只需起一个轻量级 exporterPrometheus 自动发现并拉取。这才是云原生的“解耦”思想。2.3 存储与扩展单体嵌入式 vs 分布式可插拔Zabbix Server 的核心是 C 写的 server 进程 MySQL/PostgreSQL 数据库。所有逻辑发现、采集、告警、前端都跑在这个进程里。它的扩展方式是“垂直扩容”加 CPU、加内存、换 SSD、调优数据库参数如innodb_buffer_pool_size设为物理内存 70%。Zabbix 6.0 虽然支持 proxy 分担采集压力但 proxy 本身不存数据只是把采集结果转发给 Server真正的瓶颈仍在 Server 进程和数据库。我们曾帮一家银行压测当监控主机数超过 8000 台、每秒写入指标点超 15 万时MySQL 的InnoDB row lock等待时间飙升告警延迟从秒级变成分钟级。Prometheus Server 是 Go 编写的单体进程但它把存储、采集、查询、告警全部内聚在一个二进制里。它的 TSDB 是自研的针对时序数据做了极致优化数据按 2 小时一个 block 存储block 内部用倒排索引加速 label 查询压缩算法Chu-12能把原始浮点数序列压缩到 1/10 大小。单实例轻松支撑 100 万 series时间序列和每秒 5 万样本写入。它的扩展方式是“水平分片”用 Thanos 或 Cortex 做长期存储和全局查询用 Prometheus Federation 实现多集群指标聚合用 Alertmanager 独立部署实现高可用告警。比如你有 10 个 K8s 集群可以每个集群部署一个 Prometheus再用 Thanos Query 统一查询数据存在对象存储S3/MinIO里既解决了单点瓶颈又保留了 Prometheus 的低延迟优势。3. 实战场景深度拆解从安装到告警的每一步选择3.1 容器与 K8s 监控为什么 Prometheus 是事实标准先说结论在纯 K8s 环境下Zabbix 不是不能用而是每一步都在对抗云原生范式。我们以监控一个 Spring Boot 微服务为例对比两种方案Zabbix 方案在每个 Pod 里注入 Zabbix Agent 容器sidecar 模式或在 Node 上部署 Agent 并通过hostNetwork访问 Pod配置 Agent 的UserParameter让它调用curl http://localhost:8080/actuator/prometheus并解析指标需要写 shell 脚本在 Zabbix Web 界面创建“模板”定义 item key 为spring.boot.jvm.memory.used触发器表达式为{Template App Spring Boot:vfs.fs.size[/,pused].last(0)}90为每个 Deployment 创建“主机”关联模板手动填入 Pod IP或依赖 LLD 动态发现但 LLD 规则复杂告警发送到钉钉需配置 Media Type 调用 Webhook还要处理签名验签。Prometheus 方案在服务代码里引入micrometer-registry-prometheus依赖暴露/actuator/prometheus端点部署prometheus-operator创建ServiceMonitor资源apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: spring-boot-app spec: selector: matchLabels: app: spring-boot-app endpoints: - port: web interval: 30s path: /actuator/prometheusPrometheus Operator 自动发现带有appspring-boot-app标签的 Service并配置 scrape job告警规则写在PrometheusRuleCRD 里用 PromQL 表达业务语义- alert: HighJVMLatency expr: histogram_quantile(0.95, sum by (le, job) (rate(jvm_gc_pause_seconds_bucket[1h]))) 0.5 for: 10m labels: severity: warning annotations: summary: High JVM GC latency on {{ $labels.job }}Alertmanager 通过wechat_configs直接发到企业微信配置仅需 3 行 YAML。实操心得我在一个 200 微服务的 K8s 集群里做过对比测试。Zabbix 方案上线后Agent 容器占用了 15% 的集群 CPU且每次发布新版本都要手动更新 Zabbix Agent 镜像Prometheus 方案里prometheus-operator控制器内存稳定在 300MB新增服务只需加一个ServiceMonitor5 分钟内指标就出现在 Grafana 里。这不是工具好坏而是 Zabbix 的“主机中心化”模型和 K8s 的“服务中心化”模型存在根本冲突。3.2 物理设备与传统系统监控Zabbix 的不可替代性反过来如果你要监控一台 H3C S5130 交换机、一台 Dell R740 服务器、一台 Windows Server 2016 域控、一台 Oracle 12c 数据库Prometheus 就会显得力不从心。原因很简单这些设备不提供/metricsHTTP 接口也没有标准的 REST API。Zabbix 的解决方案是成熟的、开箱即用的对交换机内置 SNMP v2c/v3 支持预置 H3C、Cisco、Juniper MIB 模板一键导入就能看到端口流量、错误包、CPU 温度对 Dell 服务器通过 iDRAC 的 WS-Man 接口获取硬件状态Zabbix 自带ipmi.sensor.getkey对 WindowsAgent 支持 WMI 查询system.cpu.util[,system]直接返回系统级 CPU对 Oracle用 ODBC 连接执行SELECT value FROM v$sysstat WHERE nameexecute count就能拿到 SQL 执行次数。Prometheus 要做到同等效果你需要为交换机部署snmp_exporter手写snmp.yml配置文件定义ifHCInOctetsOID 的 metrics 名称和标签为 Dell 服务器部署ipmi_exporter配置 BMC 地址和凭据为 Windows 部署windows_exporter启用logical_disk、os、service等 collectors为 Oracle 部署oracledb_exporter配置 TNS 连接串和查询 SQL。这还没完。Zabbix 的“自动发现”能扫描整个子网找到所有 SNMP 设备并自动添加主机Prometheus 的file_sd_configs需要你手动维护一个 JSON 文件列出所有 target 的 IP 和端口。当网络里有 500 台设备时Zabbix 的发现规则可能只需配置一次而 Prometheus 的 target 列表就是一份需要持续同步的“配置负债”。实操心得我在某省交通厅项目里遇到过真实案例。他们有 3000 路侧单元RSU设备全部通过 SNMP 管理。用 Zabbix 部署时一个 discovery rule 扫描192.168.100.0/24网段10 分钟内自动创建 3000 个主机每个主机自动应用“RSU 基础监控”模板。换成 Prometheus我们写了 Python 脚本定时调用 Zabbix API 导出设备列表再生成targets.json最后用curl -X POST http://prometheus:9090/-/reload重载配置——这套流程成了运维团队每周的固定作业稍有疏忽就会丢监控。Zabbix 在这里不是“更简单”而是“更符合物理世界的管理逻辑”。3.3 告警与通知从“阈值触发”到“根因分析”的演进Zabbix 的告警引擎基于“触发器Trigger”本质是布尔表达式{host:system.cpu.util[,avg1].last(0)} 90。它强大在于组合逻辑{host:system.cpu.util[,avg1].last(0)} 90 and {host:system.mem.pused[used].last(0)} 95。但它的短板也在此所有判断都基于单个指标的瞬时值缺乏时间维度和上下文关联。你收到一条“CPU 90%”告警但不知道这是毛刺还是持续恶化更不知道它和 3 分钟前的“磁盘 IO wait 50%”有没有因果关系。Prometheus 的告警基于 PromQL天然支持时间窗口和聚合rate(http_requests_total{jobapi}[5m]) 100过去 5 分钟 QPS 低于 100absent(up{jobdb} 1)数据库实例已失联count by (job) (rate(http_requests_total{code~5..}[1h])) / count by (job) (rate(http_requests_total[1h])) 0.01各服务 5xx 错误率超 1%。更重要的是Alertmanager 提供了企业级告警路由按标签severityemergency路由到 PagerDuty按服务名jobpayment路由到支付组企业微信对同一告警去重deduplication10 分钟内只发一次支持静默silence和抑制inhibition当“K8s Node NotReady”告警触发时自动抑制其上所有 Pod 的“Container Down”告警避免告警风暴。我在某电商大促保障中亲历过这个差异。Zabbix 配置了“API 响应时间 2s”触发器大促开始后由于缓存击穿大量请求打到 DB导致所有 API 接口 P95 延迟飙升Zabbix 在 2 分钟内发了 1200 条告警运维电话被打爆。而 Prometheus 的告警规则是histogram_quantile(0.95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) 2配合 Alertmanager 的分组group_by:[service]和抑制inhibit_rules最终只合并为 3 条告警“user-service 延迟高”、“order-service 延迟高”、“payment-service 延迟高”并附带了sum by (service) (rate(http_requests_total{code500}[5m]))的错误率辅助判断让值班工程师 30 秒内定位到是 payment-service 的 DB 连接池耗尽。4. 工具链与生态从部署到可视化的完整闭环4.1 部署与运维命令行 vs 图形化效率的分水岭Zabbix 的部署是“图形化优先”。官方提供 RPM/DEB 包、Docker 镜像、甚至 Windows Installer。安装后打开http://your-zabbix-server/zabbix向导式界面引导你完成数据库初始化、管理员密码设置、时区配置。日常运维也重度依赖 Web UI添加主机、绑定模板、配置触发器、查看最新数据、生成报表全部点点点完成。这对习惯 GUI 的传统 IT 运维非常友好。Prometheus 的部署是“配置驱动优先”。官方推荐方式是下载二进制、写prometheus.yml配置文件、启动进程。虽然也有 Docker Compose 和 Helm Chart但核心逻辑不变global: scrape_interval: 15s scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true这个文件就是 Prometheus 的“大脑”任何修改如增加一个 scrape job都需要kill -HUP或curl -X POST http://localhost:9090/-/reload重载。没有 Web 界面让你“点一下添加监控项”。但这恰恰是优势。Zabbix 的 Web 配置最终会写入数据库形成hosts、items、triggers等几十张表备份恢复极其复杂Prometheus 的配置是纯文本可以用 Git 管理配合 CI/CD 实现配置变更的审计、回滚、灰度发布。我们在某证券公司落地时把prometheus.yml和alert.rules.yml放进 GitLab每次 merge request 都触发测试环境部署确保生产配置永远和代码仓库一致。而 Zabbix 的配置同步我们只能靠zabbix_get导出 SQL再mysql导入过程中稍有不慎就会丢配置。注意Zabbix 6.0 引入了 Configuration Export/Import 功能支持 JSON 格式导出模板和主机但导出的 JSON 是 Zabbix 内部格式无法用 diff 工具对比也无法做 Code Review。Prometheus 的 YAML 是人类可读的git diff一眼就能看出谁改了哪个 job 的scrape_timeout。4.2 可视化Grafana 的统治力与 Zabbix 的原生局限Zabbix 自带的图表功能足够应付基础需求折线图、饼图、拓扑图。但它有两个硬伤图表复用难每个图表绑定到特定主机或模板无法跨主机聚合如“所有数据库的连接数总和”交互体验弱不支持变量下拉筛选、不支持时间范围联动、不支持点击钻取。Prometheus 几乎和 Grafana 形成了“默认搭档”。Grafana 的数据源原生支持 Prometheus且深度集成变量Variable可直接用 PromQL 查询生成下拉选项如label_values(job)面板支持Legend format用{{instance}}显示实例名Dashboard 支持Templating一个变量控制多个面板可以用Explore模式直接调试 PromQL所见即所得。我在某物流公司的监控大屏项目中用 Grafana 实现了“全国分拨中心实时热力图”数据源Prometheus 中node_cpu_seconds_total{modeidle}的1 - rate(...[5m])计算 CPU 使用率变量region华东/华北/华南和center上海分拨/北京分拨/广州分拨面板GeoMap 插件坐标从locations.csv文件加载颜色映射 CPU 使用率交互点击地图上的“上海分拨”自动过滤所有相关指标下方表格显示该中心所有服务器的详细负载。这套方案在 Grafana 里 2 小时搞定。如果用 Zabbix 原生图表我们需要写 SQL 查询每个分拨中心的主机列表 → 为每个主机创建独立图表 → 手动拼接 HTML 页面 → 用 JavaScript 实现点击联动。这不是技术不行而是工具链的设计初衷不同。4.3 社区与学习曲线文档质量决定落地速度Zabbix 的文档是“百科全书式”的。官网有完整的用户手册、管理指南、API 文档、模板库。搜索“Zabbix 如何监控 Redis”你能立刻找到官方 Wiki 页面步骤清晰下载redis.conf模板 → 修改 Agent 配置 → 在 Web 界面导入模板 → 关联主机。适合快速上手。Prometheus 的文档是“开发者导向”的。官网文档侧重概念解释如relabelling、federation而非具体操作。搜索“Prometheus 监控 Redis”你得到的是redis_exporterGitHub README里面只有 Docker 启动命令和配置参数说明没有告诉你如何在 K8s 里用 Helm 部署、如何配置 ServiceMonitor、如何处理 Redis 密码认证。你需要交叉阅读 Prometheus 官网、Exporter 文档、K8s 文档、Helm 文档才能拼出完整方案。但这正是它的力量所在。Zabbix 的“开箱即用”意味着你被锁死在它的抽象层里Prometheus 的“需要组装”意味着你可以自由选择组件用VictoriaMetrics替代 Prometheus Server 做更高性能存储用Grafana Loki替代 ELK 做日志用OpenTelemetry Collector统一收集 traces/metrics/logs。它的学习曲线陡峭但一旦掌握你就拥有了构建任意监控栈的能力。5. 常见问题与避坑指南来自 12 个真实项目的血泪总结5.1 Zabbix 常见问题速查表问题现象根本原因解决方案我的实操心得Zabbix Server 启动失败报错access denied for user zabbixlocalhostMySQL 用户权限未正确授予或密码在zabbix_server.conf中未更新1. 登录 MySQLCREATE USER zabbixlocalhost IDENTIFIED BY your_password;2.GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost;3. 检查zabbix_server.conf中DBPassword是否匹配这个错误在 Rocky Linux 9.8 上尤其常见因为默认 MySQL 8.0 用caching_sha2_password插件而 Zabbix 6.0 默认用mysql_native_password。解决方案是创建用户时指定CREATE USER zabbixlocalhost IDENTIFIED WITH mysql_native_password BY your_password;Zabbix Agent 在 Windows 上无法获取 WMI 数据日志报Cannot obtain WMI dataWMI 服务未启动或 Zabbix Agent 服务未以 Administrator 权限运行1.services.msc中启动Windows Management Instrumentation服务2. 在服务属性中将 Zabbix Agent 的登录身份改为Local System或域管理员账户切记不要用普通用户账户运行 AgentWMI 的Win32_Processor类需要 SeSystemProfilePrivilege 权限普通用户无法获取。我们曾为此排查 3 天最后发现是服务登录账户配置错了。Zabbix Web 界面显示“Not supported”或“No data”Agent 未运行、防火墙阻断 10050 端口、或 Item Key 配置错误1.telnet your-host 10050测试连通性2.zabbix_agentd -t system.cpu.util在目标主机上测试 Key3. 查看 Agent 日志tail -f /var/log/zabbix/zabbix_agentd.log最容易忽略的是 SELinux。在 CentOS/Rocky 上setsebool -P zabbix_can_networkon必须执行否则 Agent 无法建立出向连接。这个开关默认是 off 的。5.2 Prometheus 常见问题速查表问题现象根本原因解决方案我的实操心得Prometheus Web 界面显示server returned HTTP status 401 UnauthorizedKubernetes 集群启用了 RBACPrometheus ServiceAccount 缺少clusterrolebinding1. 创建 ClusterRolekubectl create clusterrole prometheus --verbget,list,watch --resourcenodes,nodes/metrics,pods,services2. 绑定到 ServiceAccountkubectl create clusterrolebinding prometheus --clusterroleprometheus --serviceaccountdefault:prometheus这个错误在 K8s 1.24 版本更常见因为NodeMetricsAPI 被移到metrics.k8s.io/v1beta1组需要额外授权。别忘了在 ClusterRole 中加上--resourcenodes/metrics。Grafana 中 Prometheus 数据源测试成功但查询无数据Prometheus 的scrape_configs中job_name和 Grafana 查询中的job标签不匹配或relabel_configs过滤掉了关键标签1. 在 Prometheus/targets页面确认 target 状态为 UP2. 点击 target 查看Labels确认job、instance等标签存在3. 在 Prometheus/graph页面用count({jobyour-job-name})测试新手常犯的错误是在ServiceMonitor中设置了namespaceSelector但忘记把 Prometheus 的 ServiceAccount 放到对应 namespace。结果是 target 显示为DOWN但错误信息是context deadline exceeded让人误以为是网络问题。Prometheus 内存持续增长最终 OOM KillTSDB 中 series 数量过多或scrape_interval设置过短如 5s导致样本爆炸1. 用prometheus_tsdb_head_series指标监控 series 数量2. 用topk(10, count by (__name__) ({__name__~.}))查找最“肥”的指标3. 在scrape_configs中增加sample_limit或target_limit我们曾遇到一个 Java 应用Micrometer 默认为每个Timer生成 10 个 histogram bucket 指标加上uri、method、status标签一个 endpoint 就产生 5000 series。解决方案是在 Micrometer 配置中关闭不必要的 percentile或用drop_relabel_configs过滤掉uri标签。5.3 混合部署避坑当不得不同时用两者时很多团队最终走向混合架构Zabbix 管物理设备Prometheus 管容器。这时最大的陷阱是告警重复和数据割裂。避坑技巧 1用 Zabbix Proxy 做数据桥接不要让 Prometheus 直接拉取 Zabbix 数据需zabbix_exporter而是让 Zabbix Proxy 把采集到的指标推送到 Prometheus Pushgateway。这样 Zabbix 仍负责发现和采集Prometheus 只负责存储和查询职责清晰。避坑技巧 2统一告警入口用 Alertmanager 做仲裁把 Zabbix 的告警通过 Webhook 发送到 Alertmanager而不是直接发钉钉。在 Alertmanager 配置route让 Zabbix 告警和 Prometheus 告警走同一套抑制和静默规则。例如当 Zabbix 告警Host Unreachable触发时抑制所有来自该主机的 Prometheus 告警。避坑技巧 3用 Grafana 统一可视化但明确数据来源在 Grafana Dashboard 中为 Zabbix 数据源的面板加前缀[ZBX]为 Prometheus 数据源的面板加前缀[PROM]。这样值班工程师一眼就知道该查哪个系统的日志。我们甚至在 Dashboard JSON 中加了注释字段说明“此面板数据来自 Zabbix 的 SNMP 发现更新周期 60s”。最后分享一个真实教训某客户在迁移期同时运行两套系统Zabbix 监控物理机Prometheus 监控 K8s。他们把两个系统的告警都配置到同一个钉钉群。结果某天 Zabbix 因数据库慢导致告警延迟 15 分钟而 Prometheus 告警准时到达。运维看到 Prometheus 告警“Node CPU 90%”立刻登录 K8s 查看发现是某个批处理 Job 占满 CPU10 分钟后 Zabbix 告警才到内容却是“物理服务器 CPU 90%”指向完全错误的根因。从此我们规定混合架构下告警必须有唯一可信源其他系统只做数据补充不做告警决策。
Prometheus与Zabbix核心差异：监控对象决定技术选型
1. 这不是选“谁更好”而是搞清“谁在解决什么问题”Prometheus 和 Zabbix这两个词最近在运维、SRE、云原生工程师的聊天记录里出现频率高得离谱。我上个月帮三家客户做监控体系重构有家传统金融公司刚把 Zabbix 从 4.0 升到 6.4结果发现容器指标采集延迟严重、告警风暴压垮数据库另一家互联网创业公司用 Prometheus Grafana 搭了整套 K8s 监控但业务部门反馈“看图很炫查个 Java 应用 GC 频次要翻 5 个面板”第三家是混合云环境物理机、VM、K8s 集群、边缘网关全都有他们直接把两个平台并存靠脚本做数据桥接——结果告警规则维护成本翻了三倍。这不是技术站队而是两种设计哲学的碰撞。Zabbix 是从 2001 年就扎根在物理服务器时代的“老派工程师”它信奉“所有设备都该被统一建模、统一纳管、统一告警”所以它的 Web 界面自带资产台账、自动发现、模板继承、宏变量、历史趋势图、SLA 报表——你甚至能用它给打印机卡纸发微信通知。而 Prometheus 是 2012 年诞生于 SoundCloud 的“云原生原住民”它只相信一件事指标必须是拉取pull的、时序的、带标签的、可聚合的。它不关心你服务器型号只关心http_request_duration_seconds_sum{jobapi-gateway, instance10.2.3.4:8080, status_code500}这个指标在过去 5 分钟涨了多少。关键词里反复出现的prometheus、zabbix、监控平台、容器监控、K8s其实已经划出了分水岭如果你的系统里还有大量 Windows Server、IBM AIX、H3C 交换机、海康威视摄像头Zabbix 的 SNMP/ICMP/JMX/ODBC 插件生态就是你的护城河但如果你的交付物是 Helm Chart、CI/CD 流水线里跑着kubectl apply -f prometheus-rules.yaml那 Prometheus 的 ServiceMonitor、PodMonitor、Relabeling 机制就是你呼吸的空气。我见过太多团队踩坑不是因为技术差而是没想清楚一个问题你到底是在监控“基础设施”还是在监控“服务行为”前者关注“CPU 是否超 85%”“磁盘剩余是否少于 10G”“端口是否通”后者关注“订单创建接口 P99 延迟是否突破 800ms”“支付成功率是否低于 99.95%”“库存扣减失败率是否突增”。Zabbix 天然擅长前者Prometheus 天然擅长后者。这篇文章不给你标准答案而是带你拆开两台“监控发动机”的活塞、曲轴和油路让你自己判断哪台更适合你正在跑的那辆卡车。2. 架构基因决定能力边界从数据模型到扩展方式2.1 数据模型标签 vs 属性这是根本分歧Zabbix 的数据模型是典型的“关系型思维”。每个监控项item属于一个主机host主机属于一个主机组host group主机又关联多个模板template。指标本身是扁平的system.cpu.util[,idle]、net.if.in[eth0]、vm.memory.size[available]。这些字符串背后没有结构化语义只是约定俗成的命名规范。你要查“所有 Web 服务器的 5 分钟平均 CPU 使用率”得写 SQL 式查询select avg(value) from history where itemid in (select itemid from items where hostid in (select hostid from hosts_groups where groupid xxx) and key_ system.cpu.util[,avg5]) and clock unix_timestamp() - 300。Zabbix 5.0 虽然引入了“低级别发现LLD”生成动态键值但本质仍是静态模板的批量克隆。Prometheus 则彻底拥抱“多维数据模型”。每个指标是一个时间序列由指标名称metric name和一组键值对标签label set唯一标识。http_requests_total{jobprometheus, instancelocalhost:9090, code200, handler/graph}这个字符串本身就是完整语义它不是一个孤立数字而是一条带上下文的“事件流”。你可以用sum by (job, handler) (rate(http_requests_total{code~5..}[5m]))一句话算出所有服务中各接口的 5xx 错误率并按服务名和路径聚合。这种能力不是靠后台 SQL 实现的而是存储引擎TSDB原生支持的倒排索引时间窗口计算。提示Zabbix 的“宏”如{$SNMP_COMMUNITY}和 Prometheus 的“relabeling”看起来都是变量替换但逻辑完全不同。Zabbix 宏是配置时的文本替换发生在数据入库前Prometheus relabeling 是采集时的实时标签重写发生在 scrape 到 target 之后、存入 TSDB 之前且支持正则提取、哈希计算、条件跳过等复杂逻辑。这是架构层级的差异无法通过插件弥补。2.2 数据采集拉取Pull与推送Push的哲学之争Zabbix 支持两种模式Agent 主动上报push和 Server 主动轮询pull。但实际生产中90% 的场景用的是 Agent 模式。Zabbix Agent 安装在被监控主机上定期执行脚本、读取/proc、调用 WMI然后把结果打包发给 Server。这种方式的好处是网络穿透简单只需 Agent 出向连接、资源占用可控Agent 自身内存10MB、兼容性极强Windows/Linux/AIX 全支持。坏处也很明显Agent 版本升级需逐台操作、自定义监控项要写脚本并分发、大规模部署时 Agent 心跳包可能压垮 Server 数据库。Prometheus 只认一种模式Server 主动拉取pull。它不接受任何主动上报的数据除非通过 Pushgateway 这个妥协方案。它的核心假设是现代云环境里服务发现Service Discovery比静态 IP 列表更可靠HTTP 接口比二进制协议更易调试拉取比推送更利于故障隔离。当你在 K8s 里部署一个新 PodPrometheus 通过 API Server 发现它检查其/metrics端点发起 HTTP GET 请求拿到文本格式的指标如# HELP http_requests_total The total number of HTTP requests.\n# TYPE http_requests_total counter\nhttp_requests_total{methodpost,code200} 1027\nhttp_requests_total{methodget,code200} 3042解析后存入本地 TSDB。整个过程无需在目标端安装任何代理只要暴露一个 HTTP 端点即可。注意很多人误以为 “Prometheus 不支持 Windows”其实是误解。Prometheus 官方提供了 windows_exporter它就是一个标准的 HTTP 服务监听localhost:9182/metrics返回 Windows 性能计数器数据。你不需要在每台 Windows 服务器上配 Zabbix Agent只需起一个轻量级 exporterPrometheus 自动发现并拉取。这才是云原生的“解耦”思想。2.3 存储与扩展单体嵌入式 vs 分布式可插拔Zabbix Server 的核心是 C 写的 server 进程 MySQL/PostgreSQL 数据库。所有逻辑发现、采集、告警、前端都跑在这个进程里。它的扩展方式是“垂直扩容”加 CPU、加内存、换 SSD、调优数据库参数如innodb_buffer_pool_size设为物理内存 70%。Zabbix 6.0 虽然支持 proxy 分担采集压力但 proxy 本身不存数据只是把采集结果转发给 Server真正的瓶颈仍在 Server 进程和数据库。我们曾帮一家银行压测当监控主机数超过 8000 台、每秒写入指标点超 15 万时MySQL 的InnoDB row lock等待时间飙升告警延迟从秒级变成分钟级。Prometheus Server 是 Go 编写的单体进程但它把存储、采集、查询、告警全部内聚在一个二进制里。它的 TSDB 是自研的针对时序数据做了极致优化数据按 2 小时一个 block 存储block 内部用倒排索引加速 label 查询压缩算法Chu-12能把原始浮点数序列压缩到 1/10 大小。单实例轻松支撑 100 万 series时间序列和每秒 5 万样本写入。它的扩展方式是“水平分片”用 Thanos 或 Cortex 做长期存储和全局查询用 Prometheus Federation 实现多集群指标聚合用 Alertmanager 独立部署实现高可用告警。比如你有 10 个 K8s 集群可以每个集群部署一个 Prometheus再用 Thanos Query 统一查询数据存在对象存储S3/MinIO里既解决了单点瓶颈又保留了 Prometheus 的低延迟优势。3. 实战场景深度拆解从安装到告警的每一步选择3.1 容器与 K8s 监控为什么 Prometheus 是事实标准先说结论在纯 K8s 环境下Zabbix 不是不能用而是每一步都在对抗云原生范式。我们以监控一个 Spring Boot 微服务为例对比两种方案Zabbix 方案在每个 Pod 里注入 Zabbix Agent 容器sidecar 模式或在 Node 上部署 Agent 并通过hostNetwork访问 Pod配置 Agent 的UserParameter让它调用curl http://localhost:8080/actuator/prometheus并解析指标需要写 shell 脚本在 Zabbix Web 界面创建“模板”定义 item key 为spring.boot.jvm.memory.used触发器表达式为{Template App Spring Boot:vfs.fs.size[/,pused].last(0)}90为每个 Deployment 创建“主机”关联模板手动填入 Pod IP或依赖 LLD 动态发现但 LLD 规则复杂告警发送到钉钉需配置 Media Type 调用 Webhook还要处理签名验签。Prometheus 方案在服务代码里引入micrometer-registry-prometheus依赖暴露/actuator/prometheus端点部署prometheus-operator创建ServiceMonitor资源apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: spring-boot-app spec: selector: matchLabels: app: spring-boot-app endpoints: - port: web interval: 30s path: /actuator/prometheusPrometheus Operator 自动发现带有appspring-boot-app标签的 Service并配置 scrape job告警规则写在PrometheusRuleCRD 里用 PromQL 表达业务语义- alert: HighJVMLatency expr: histogram_quantile(0.95, sum by (le, job) (rate(jvm_gc_pause_seconds_bucket[1h]))) 0.5 for: 10m labels: severity: warning annotations: summary: High JVM GC latency on {{ $labels.job }}Alertmanager 通过wechat_configs直接发到企业微信配置仅需 3 行 YAML。实操心得我在一个 200 微服务的 K8s 集群里做过对比测试。Zabbix 方案上线后Agent 容器占用了 15% 的集群 CPU且每次发布新版本都要手动更新 Zabbix Agent 镜像Prometheus 方案里prometheus-operator控制器内存稳定在 300MB新增服务只需加一个ServiceMonitor5 分钟内指标就出现在 Grafana 里。这不是工具好坏而是 Zabbix 的“主机中心化”模型和 K8s 的“服务中心化”模型存在根本冲突。3.2 物理设备与传统系统监控Zabbix 的不可替代性反过来如果你要监控一台 H3C S5130 交换机、一台 Dell R740 服务器、一台 Windows Server 2016 域控、一台 Oracle 12c 数据库Prometheus 就会显得力不从心。原因很简单这些设备不提供/metricsHTTP 接口也没有标准的 REST API。Zabbix 的解决方案是成熟的、开箱即用的对交换机内置 SNMP v2c/v3 支持预置 H3C、Cisco、Juniper MIB 模板一键导入就能看到端口流量、错误包、CPU 温度对 Dell 服务器通过 iDRAC 的 WS-Man 接口获取硬件状态Zabbix 自带ipmi.sensor.getkey对 WindowsAgent 支持 WMI 查询system.cpu.util[,system]直接返回系统级 CPU对 Oracle用 ODBC 连接执行SELECT value FROM v$sysstat WHERE nameexecute count就能拿到 SQL 执行次数。Prometheus 要做到同等效果你需要为交换机部署snmp_exporter手写snmp.yml配置文件定义ifHCInOctetsOID 的 metrics 名称和标签为 Dell 服务器部署ipmi_exporter配置 BMC 地址和凭据为 Windows 部署windows_exporter启用logical_disk、os、service等 collectors为 Oracle 部署oracledb_exporter配置 TNS 连接串和查询 SQL。这还没完。Zabbix 的“自动发现”能扫描整个子网找到所有 SNMP 设备并自动添加主机Prometheus 的file_sd_configs需要你手动维护一个 JSON 文件列出所有 target 的 IP 和端口。当网络里有 500 台设备时Zabbix 的发现规则可能只需配置一次而 Prometheus 的 target 列表就是一份需要持续同步的“配置负债”。实操心得我在某省交通厅项目里遇到过真实案例。他们有 3000 路侧单元RSU设备全部通过 SNMP 管理。用 Zabbix 部署时一个 discovery rule 扫描192.168.100.0/24网段10 分钟内自动创建 3000 个主机每个主机自动应用“RSU 基础监控”模板。换成 Prometheus我们写了 Python 脚本定时调用 Zabbix API 导出设备列表再生成targets.json最后用curl -X POST http://prometheus:9090/-/reload重载配置——这套流程成了运维团队每周的固定作业稍有疏忽就会丢监控。Zabbix 在这里不是“更简单”而是“更符合物理世界的管理逻辑”。3.3 告警与通知从“阈值触发”到“根因分析”的演进Zabbix 的告警引擎基于“触发器Trigger”本质是布尔表达式{host:system.cpu.util[,avg1].last(0)} 90。它强大在于组合逻辑{host:system.cpu.util[,avg1].last(0)} 90 and {host:system.mem.pused[used].last(0)} 95。但它的短板也在此所有判断都基于单个指标的瞬时值缺乏时间维度和上下文关联。你收到一条“CPU 90%”告警但不知道这是毛刺还是持续恶化更不知道它和 3 分钟前的“磁盘 IO wait 50%”有没有因果关系。Prometheus 的告警基于 PromQL天然支持时间窗口和聚合rate(http_requests_total{jobapi}[5m]) 100过去 5 分钟 QPS 低于 100absent(up{jobdb} 1)数据库实例已失联count by (job) (rate(http_requests_total{code~5..}[1h])) / count by (job) (rate(http_requests_total[1h])) 0.01各服务 5xx 错误率超 1%。更重要的是Alertmanager 提供了企业级告警路由按标签severityemergency路由到 PagerDuty按服务名jobpayment路由到支付组企业微信对同一告警去重deduplication10 分钟内只发一次支持静默silence和抑制inhibition当“K8s Node NotReady”告警触发时自动抑制其上所有 Pod 的“Container Down”告警避免告警风暴。我在某电商大促保障中亲历过这个差异。Zabbix 配置了“API 响应时间 2s”触发器大促开始后由于缓存击穿大量请求打到 DB导致所有 API 接口 P95 延迟飙升Zabbix 在 2 分钟内发了 1200 条告警运维电话被打爆。而 Prometheus 的告警规则是histogram_quantile(0.95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) 2配合 Alertmanager 的分组group_by:[service]和抑制inhibit_rules最终只合并为 3 条告警“user-service 延迟高”、“order-service 延迟高”、“payment-service 延迟高”并附带了sum by (service) (rate(http_requests_total{code500}[5m]))的错误率辅助判断让值班工程师 30 秒内定位到是 payment-service 的 DB 连接池耗尽。4. 工具链与生态从部署到可视化的完整闭环4.1 部署与运维命令行 vs 图形化效率的分水岭Zabbix 的部署是“图形化优先”。官方提供 RPM/DEB 包、Docker 镜像、甚至 Windows Installer。安装后打开http://your-zabbix-server/zabbix向导式界面引导你完成数据库初始化、管理员密码设置、时区配置。日常运维也重度依赖 Web UI添加主机、绑定模板、配置触发器、查看最新数据、生成报表全部点点点完成。这对习惯 GUI 的传统 IT 运维非常友好。Prometheus 的部署是“配置驱动优先”。官方推荐方式是下载二进制、写prometheus.yml配置文件、启动进程。虽然也有 Docker Compose 和 Helm Chart但核心逻辑不变global: scrape_interval: 15s scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true这个文件就是 Prometheus 的“大脑”任何修改如增加一个 scrape job都需要kill -HUP或curl -X POST http://localhost:9090/-/reload重载。没有 Web 界面让你“点一下添加监控项”。但这恰恰是优势。Zabbix 的 Web 配置最终会写入数据库形成hosts、items、triggers等几十张表备份恢复极其复杂Prometheus 的配置是纯文本可以用 Git 管理配合 CI/CD 实现配置变更的审计、回滚、灰度发布。我们在某证券公司落地时把prometheus.yml和alert.rules.yml放进 GitLab每次 merge request 都触发测试环境部署确保生产配置永远和代码仓库一致。而 Zabbix 的配置同步我们只能靠zabbix_get导出 SQL再mysql导入过程中稍有不慎就会丢配置。注意Zabbix 6.0 引入了 Configuration Export/Import 功能支持 JSON 格式导出模板和主机但导出的 JSON 是 Zabbix 内部格式无法用 diff 工具对比也无法做 Code Review。Prometheus 的 YAML 是人类可读的git diff一眼就能看出谁改了哪个 job 的scrape_timeout。4.2 可视化Grafana 的统治力与 Zabbix 的原生局限Zabbix 自带的图表功能足够应付基础需求折线图、饼图、拓扑图。但它有两个硬伤图表复用难每个图表绑定到特定主机或模板无法跨主机聚合如“所有数据库的连接数总和”交互体验弱不支持变量下拉筛选、不支持时间范围联动、不支持点击钻取。Prometheus 几乎和 Grafana 形成了“默认搭档”。Grafana 的数据源原生支持 Prometheus且深度集成变量Variable可直接用 PromQL 查询生成下拉选项如label_values(job)面板支持Legend format用{{instance}}显示实例名Dashboard 支持Templating一个变量控制多个面板可以用Explore模式直接调试 PromQL所见即所得。我在某物流公司的监控大屏项目中用 Grafana 实现了“全国分拨中心实时热力图”数据源Prometheus 中node_cpu_seconds_total{modeidle}的1 - rate(...[5m])计算 CPU 使用率变量region华东/华北/华南和center上海分拨/北京分拨/广州分拨面板GeoMap 插件坐标从locations.csv文件加载颜色映射 CPU 使用率交互点击地图上的“上海分拨”自动过滤所有相关指标下方表格显示该中心所有服务器的详细负载。这套方案在 Grafana 里 2 小时搞定。如果用 Zabbix 原生图表我们需要写 SQL 查询每个分拨中心的主机列表 → 为每个主机创建独立图表 → 手动拼接 HTML 页面 → 用 JavaScript 实现点击联动。这不是技术不行而是工具链的设计初衷不同。4.3 社区与学习曲线文档质量决定落地速度Zabbix 的文档是“百科全书式”的。官网有完整的用户手册、管理指南、API 文档、模板库。搜索“Zabbix 如何监控 Redis”你能立刻找到官方 Wiki 页面步骤清晰下载redis.conf模板 → 修改 Agent 配置 → 在 Web 界面导入模板 → 关联主机。适合快速上手。Prometheus 的文档是“开发者导向”的。官网文档侧重概念解释如relabelling、federation而非具体操作。搜索“Prometheus 监控 Redis”你得到的是redis_exporterGitHub README里面只有 Docker 启动命令和配置参数说明没有告诉你如何在 K8s 里用 Helm 部署、如何配置 ServiceMonitor、如何处理 Redis 密码认证。你需要交叉阅读 Prometheus 官网、Exporter 文档、K8s 文档、Helm 文档才能拼出完整方案。但这正是它的力量所在。Zabbix 的“开箱即用”意味着你被锁死在它的抽象层里Prometheus 的“需要组装”意味着你可以自由选择组件用VictoriaMetrics替代 Prometheus Server 做更高性能存储用Grafana Loki替代 ELK 做日志用OpenTelemetry Collector统一收集 traces/metrics/logs。它的学习曲线陡峭但一旦掌握你就拥有了构建任意监控栈的能力。5. 常见问题与避坑指南来自 12 个真实项目的血泪总结5.1 Zabbix 常见问题速查表问题现象根本原因解决方案我的实操心得Zabbix Server 启动失败报错access denied for user zabbixlocalhostMySQL 用户权限未正确授予或密码在zabbix_server.conf中未更新1. 登录 MySQLCREATE USER zabbixlocalhost IDENTIFIED BY your_password;2.GRANT ALL PRIVILEGES ON zabbix.* TO zabbixlocalhost;3. 检查zabbix_server.conf中DBPassword是否匹配这个错误在 Rocky Linux 9.8 上尤其常见因为默认 MySQL 8.0 用caching_sha2_password插件而 Zabbix 6.0 默认用mysql_native_password。解决方案是创建用户时指定CREATE USER zabbixlocalhost IDENTIFIED WITH mysql_native_password BY your_password;Zabbix Agent 在 Windows 上无法获取 WMI 数据日志报Cannot obtain WMI dataWMI 服务未启动或 Zabbix Agent 服务未以 Administrator 权限运行1.services.msc中启动Windows Management Instrumentation服务2. 在服务属性中将 Zabbix Agent 的登录身份改为Local System或域管理员账户切记不要用普通用户账户运行 AgentWMI 的Win32_Processor类需要 SeSystemProfilePrivilege 权限普通用户无法获取。我们曾为此排查 3 天最后发现是服务登录账户配置错了。Zabbix Web 界面显示“Not supported”或“No data”Agent 未运行、防火墙阻断 10050 端口、或 Item Key 配置错误1.telnet your-host 10050测试连通性2.zabbix_agentd -t system.cpu.util在目标主机上测试 Key3. 查看 Agent 日志tail -f /var/log/zabbix/zabbix_agentd.log最容易忽略的是 SELinux。在 CentOS/Rocky 上setsebool -P zabbix_can_networkon必须执行否则 Agent 无法建立出向连接。这个开关默认是 off 的。5.2 Prometheus 常见问题速查表问题现象根本原因解决方案我的实操心得Prometheus Web 界面显示server returned HTTP status 401 UnauthorizedKubernetes 集群启用了 RBACPrometheus ServiceAccount 缺少clusterrolebinding1. 创建 ClusterRolekubectl create clusterrole prometheus --verbget,list,watch --resourcenodes,nodes/metrics,pods,services2. 绑定到 ServiceAccountkubectl create clusterrolebinding prometheus --clusterroleprometheus --serviceaccountdefault:prometheus这个错误在 K8s 1.24 版本更常见因为NodeMetricsAPI 被移到metrics.k8s.io/v1beta1组需要额外授权。别忘了在 ClusterRole 中加上--resourcenodes/metrics。Grafana 中 Prometheus 数据源测试成功但查询无数据Prometheus 的scrape_configs中job_name和 Grafana 查询中的job标签不匹配或relabel_configs过滤掉了关键标签1. 在 Prometheus/targets页面确认 target 状态为 UP2. 点击 target 查看Labels确认job、instance等标签存在3. 在 Prometheus/graph页面用count({jobyour-job-name})测试新手常犯的错误是在ServiceMonitor中设置了namespaceSelector但忘记把 Prometheus 的 ServiceAccount 放到对应 namespace。结果是 target 显示为DOWN但错误信息是context deadline exceeded让人误以为是网络问题。Prometheus 内存持续增长最终 OOM KillTSDB 中 series 数量过多或scrape_interval设置过短如 5s导致样本爆炸1. 用prometheus_tsdb_head_series指标监控 series 数量2. 用topk(10, count by (__name__) ({__name__~.}))查找最“肥”的指标3. 在scrape_configs中增加sample_limit或target_limit我们曾遇到一个 Java 应用Micrometer 默认为每个Timer生成 10 个 histogram bucket 指标加上uri、method、status标签一个 endpoint 就产生 5000 series。解决方案是在 Micrometer 配置中关闭不必要的 percentile或用drop_relabel_configs过滤掉uri标签。5.3 混合部署避坑当不得不同时用两者时很多团队最终走向混合架构Zabbix 管物理设备Prometheus 管容器。这时最大的陷阱是告警重复和数据割裂。避坑技巧 1用 Zabbix Proxy 做数据桥接不要让 Prometheus 直接拉取 Zabbix 数据需zabbix_exporter而是让 Zabbix Proxy 把采集到的指标推送到 Prometheus Pushgateway。这样 Zabbix 仍负责发现和采集Prometheus 只负责存储和查询职责清晰。避坑技巧 2统一告警入口用 Alertmanager 做仲裁把 Zabbix 的告警通过 Webhook 发送到 Alertmanager而不是直接发钉钉。在 Alertmanager 配置route让 Zabbix 告警和 Prometheus 告警走同一套抑制和静默规则。例如当 Zabbix 告警Host Unreachable触发时抑制所有来自该主机的 Prometheus 告警。避坑技巧 3用 Grafana 统一可视化但明确数据来源在 Grafana Dashboard 中为 Zabbix 数据源的面板加前缀[ZBX]为 Prometheus 数据源的面板加前缀[PROM]。这样值班工程师一眼就知道该查哪个系统的日志。我们甚至在 Dashboard JSON 中加了注释字段说明“此面板数据来自 Zabbix 的 SNMP 发现更新周期 60s”。最后分享一个真实教训某客户在迁移期同时运行两套系统Zabbix 监控物理机Prometheus 监控 K8s。他们把两个系统的告警都配置到同一个钉钉群。结果某天 Zabbix 因数据库慢导致告警延迟 15 分钟而 Prometheus 告警准时到达。运维看到 Prometheus 告警“Node CPU 90%”立刻登录 K8s 查看发现是某个批处理 Job 占满 CPU10 分钟后 Zabbix 告警才到内容却是“物理服务器 CPU 90%”指向完全错误的根因。从此我们规定混合架构下告警必须有唯一可信源其他系统只做数据补充不做告警决策。