完全可行，关键在于时间基准对齐、指标语义映射与分辨率协调：统一时区、重命名标签、补空值、降采样，并通过label_replace和label_join实现跨源维度匹配。
直接在单个折线图或热力图里同时展示 Prometheus 的实时 QPS 和 Zabbix 的历史磁盘使用率，是完全可行的——关键不是“能不能”，而是“怎么对齐时间、标签和单位”。Grafana 的 Mixed Data Source 功能本身不自动做数据对齐，它只负责把多个查询结果按时间戳拼在一起渲染。真正决定“是否完美混编”的，是你的查询设计、时间范围控制和字段映射逻辑。
确保时间基准一致
混编失败的第一大原因是时间窗口错位。Prometheus 默认以服务器本地时间为基准，Zabbix 数据库（如 MySQL）的时间戳可能受时区或采集延迟影响。
- 在 Grafana 面板右上角统一设置时区为 UTC 或业务所在时区，避免自动转换干扰
- Prometheus 查询中显式加 offset（如
rate(http_requests_total[5m]) offset 1m）来补偿采集延迟，使与 Zabbix 的采样点更贴近 - Zabbix 数据源配置里勾选 “Use local timezone” 或 “Use browser timezone”，并确认 Zabbix Server 的
php.ini中date.timezone与 Grafana 一致
统一指标语义与标签结构
两个系统原始指标命名和维度完全不同：Prometheus 是 node_cpu_seconds_total{mode="idle", instance="10.0.1.5:9100"}，Zabbix 是 system.cpu.util[,idle]，主机标识用 hostid 或 hostname。混编前必须做语义对齐。
- 在 Zabbix 数据源查询中，使用 Alias by 或 Transform → Rename by regex 把 Zabbix 返回的列重命名为与 Prometheus 兼容的 label 名，例如将
hostname列重命名为instance - 对 Prometheus 查询，用
label_replace()补充 Zabbix 侧才有的维度（如env="prod"），便于后续过滤联动 - 若需对比同台机器的 CPU idle 率，Prometheus 查
100 - (100 * avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])))，Zabbix 查system.cpu.util[,idle]，二者都输出单一数值序列，且instance标签可匹配
处理分辨率与空值差异
Prometheus 常以 15s 或 30s 间隔拉取，Zabbix 可能是 60s 或 300s；Zabbix 某些历史时段无数据会返回 null，而 Prometheus 默认插值补点。混绘时容易出现锯齿或断线。
- 在面板 Query Options 中，对 Zabbix 查询启用 “Fill null values”（设为 previous 或 0），避免折线中断
- 对 Prometheus 查询，在 PromQL 末尾加
or vector(0)提供兜底值，保证时间轴连续 - 手动设置面板的 Min interval（如 60s），让 Grafana 对两个数据源做统一降采样，比各自原始频率更平滑
实战：一个订单延迟监控混合图
比如你希望在一个图里看：
- 红线：Prometheus 抓取的 API 平均响应时间（
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))） - 蓝虚线：Zabbix 上同一台应用服务器的
system.cpu.util[,user]（反映负载压力） - 灰背景带：Zabbix 的
vm.memory.size[pavailable]（内存可用率，作为辅助参考）
操作要点：三个查询共用同一个 instance 过滤条件（如 instance =~ "app-.*-prod"）；Zabbix 查询开启 “Multiple series” 模式并按 host 分组；Prometheus 查询加 label_join(..., "host", ",", "instance") 确保 host 字段可被 Zabbix 数据源识别；最终用 Grafana 的 Repeat options 按 host 自动生成多子图，无需手动复制粘贴。
