前言
在多集群监控场景下，传统多Prometheus部署模式存在数据孤岛问题。
业界主流有Thanos、VictoriaMetrics两种分布式时序解决方案，可实现监控指标统一汇聚与全局查询。
【老方案：多Prometheus，分散存储】
集群A → Prometheus-A（抓取+本地TSDB存储）
集群B → Prometheus-B（抓取+本地TSDB存储）
Grafana需要分别连A、B两个Prometheus，无法统一全局视图
【方案1：Thanos 分布式扩展方案（必须依赖Prometheus）】
集群A → Prometheus-A + Thanos Sidecar
集群B → Prometheus-B + Thanos Sidecar
Sidecar热数据本地留存，冷数据上传对象存储(S3/MinIO)
Thanos Querier统一聚合所有Prometheus本地数据 + 对象存储历史数据
Grafana ← 查询 Thanos Querier（一套入口查看全部指标）
【方案2：VM聚合方案（A和B两条可选路线，二选一）】
方案2-A路线（无Prometheus）
集群业务 → vmagent（直接抓取各Exporter暴露的指标信息） → VictoriaMetrics自研引擎统一存储
方案2-B路线（存量改造，保留原有Prometheus做汇聚）
集群A → Prometheus-A remote_write → VictoriaMetrics
集群B → Prometheus-B remote_write → VictoriaMetrics
Grafana ← 查询 VictoriaMetrics（一套入口查看全部指标）
一、VictoriaMetrics架构
VictoriaMetrics（简称 VM）是一套开源、高性能、可扩展的Metrics监控数据平台，不仅提供高性能的时序数据库能力，还涵盖Metrics数据的采集、传输、存储、查询和告警等功能，专为云原生时代的大规模监控场景打造，可作为 Metrics 数据的长期存储、查询和分析后端。
与传统时序数据库相比，VM提供了极高的写入和查询性能，同时能够大幅降低存储成本和运维复杂度。
从数据模型层面看，VictoriaMetrics与Prometheus 保持较高的生态兼容性。
Prometheus定义并广泛采用 Counter、Gauge、Histogram、Summary等指标类型以及相应的指标暴露格式，因此，VictoriaMetrics可以直接接入Prometheus Exporter和符合 Prometheus exposition格式的指标数据，同时通过 MetricsQL提供查询与分析能力。
与此同时VictoriaMetrics兼容Prometheus的生态（remote_write/remote_read API），因而在各类Kubernetes、大型数据中心系统和云计算平台被越来越多地采纳。
VictoriaMetrics系统架构分为采集客户端和存储服务端2大部分：
1.Metrics数据收集端(vmagent)
vmagent是轻量采集代理可以替代Prometheus-server，主动抓取各Exporter暴露的指标；
Metrics 数据源 ┌────────────┼────────────┐ │ │ │ 应用服务 主机 Kubernetes │ │ │ └────────────┼────────────┘ │ 暴露 Metrics │ ▼ ┌─────────────────┐ │ vmagent │ │ 采集 / 过滤 / │ │ Relabel │ └────────┬────────┘ │ Remote Write │ ▼ ┌─────────────────────────────┐ │ VictoriaMetrics Cluster │ │ │ │ ┌──────────┐ │ │ │vminsert │ │ │ └────┬─────┘ │ │ │ │ │ 数据分片/副本 │ │ │ │ │ ┌───────┼───────┐ │ │ ▼ ▼ ▼ │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │vmstorage│ │vmstorage│ │vmstorage│ │ └───────┘ └───────┘ └───────┘ │ │ │ ┌──────────┐ │ │ │ vmselect │ │ │ └────┬─────┘ │ └─────────────┼───────────────┘ │ PromQL │ ▼ Grafana
支持指标过滤、Relabel 标签修改，通过remote_write协议把采集到的时序数据转发给VM集群写入层，存储不可用时本地持久队列缓存，防止丢数据。
vmagent通过pull方式从各个被监控目标(Target)采集指标数据推送(remote_write)到远端的时序数据存储集群/单机。
[root@bj1-ecs-wkerp-t-3781 ~]$kubectl get pod -n victoria-metrics
NAME READY STATUS RESTARTS AGE
kube-state-metrics-57c678fdcd-xj4l9 3/3 Running 0 158d
vmagent-victoria-metrics-agent-0 2/2 Running 0 58d
vmoperator-victoria-metrics-operator-58c49bd676-zpzv8 1/1 Running 74 (45h ago) 158d
当前集群采用VictoriaMetrics监控架构
Exporter（包括 kube-state-metrics 等）负责暴露Prometheus格式的Metrics
VMagent负责主动Pull指标并通过remote_write转发至VictoriaMetrics进行长期存储；
vmoperator则负责通过Operator机制管理VictoriaMetrics相关资源。
[root@bj1-ecs-wkerp-t-3781 ~]$kubectl get vmservicescrape -A
NAMESPACE NAME AGE
victoria-metrics app-metrics 158d
victoria-metrics coredns 158d
victoria-metrics hami-device-plugin 158d
victoria-metrics kube-apiserver 158d
victoria-metrics kube-controller-manager 158d
victoria-metrics kube-scheduler 158d
victoria-metrics kube-state-metrics 158d
victoria-metrics kubelet 158d
victoria-metrics release-name-dcgm-exporter 158d
victoria-metrics vmagent-victoria-metrics-agent 158d
victoria-metrics vmoperator-victoria-metrics-operator 158d
2.Metrics数据存储端(VictoriaMetrics)
如下图VictoriaMetrics远端TSDB由以下3个独立组件构成
vminsert（写入网关，无状态）
接收vmagent推送的指标，基于时序名称 + 标签做一致性哈希分片，分发到各个vmstorage 节点，负责集群写入。
vmstorage（存储节点，有状态）
持久保存原始时序数据；收到vmselect的查询请求广播，vmstorage执行本地查询，返回分片局部结果。
vmselect（查询网关，无状态）
接收 Grafana/VMUI 的 PromQL 查询，广播查询至全部vmstorage；收集各存储节点返回的局部结果，完成跨分片聚合，将最终结果返回前端；重查询可利用本地文件系统做临时计算与本地文件系统缓存。
浙公网安备 33010602011771号