在 Kubernetes 上基于 VictoriaMetrics Cluster 构建高可用监控复制与去重实战指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本篇指南以 VictoriaMetrics 集群版Cluster version为对象讲解如何在 Kubernetes 中通过 Helm 部署一套高可用HA监控体系利用vminsert的replicationFactor: 2复制写入配合vmselect的dedup.minScrapeInterval去重读取并借助vmagent的服务发现能力采集 Kubernetes 组件指标。读完本文你将掌握 VictoriaMetrics 复制与去重机制的工作原理、完整部署命令与配置参数、查询验证方法以及如何通过故障演练证明数据在单节点宕机时依然可用。高可用原理复制写入 去重读取在本方案中高可用通过配置vminsert的replicationFactor: 2实现。这意味着每条进入的数据点都会被写入两次分别落到两个不同的vmstoragePod 上只要某个时间序列的至少一个副本可达数据就始终可用。该方案需要两倍的存储空间因为vminsert会把每次写入扇出fan out到两个vmstoragePod。复制带来的直接副作用是vmselect查询时会读到每个样本的两份拷贝导致聚合结果被放大——例如sum或count这类聚合会把结果翻倍。因此必须在vmselectPod 上启用去重deduplication将每个抓取间隔内的副本折叠为单个样本。关于复制与数据安全机制的官方说明可进一步阅读 Cluster-VictoriaMetrics.md 中的 Replication and data safety 章节其中明确指出复制通过在vminsert上传递-replicationFactorN命令行标志启用指示vminsert将每条摄入样本存储 N 份到 N 个不同的vmstorage节点上从而保证最多有N-1个vmstorage节点不可用时数据依然可查询集群至少需要2*N-1个vmstorage节点N 为复制因子才能在N-1个存储节点不可用时依然为新摄入数据维持给定的复制因子复制会使 CPU、内存、磁盘空间、网络带宽等资源占用提升最多N倍因此如果底层存储本身是带复制能力的高可用持久化卷将复制下推到底层存储往往更经济复制不能替代备份——文档明确建议仍需定期执行备份。前置条件本指南在 GCP 的 GKE 集群v1.35上验证但同样适用于任何 Kubernetes 集群例如 Amazon EKS 或自建集群。开始前请准备好以下工具一个可用的 Kubernetes 集群如 GKEHelm 包管理器kubectl命令行工具jq工具用于格式化 JSON 查询输出。1. 添加 VictoriaMetrics Helm 仓库执行以下命令添加 VictoriaMetrics 的 Helm 仓库并更新索引helm repo add vm https://victoriametrics.github.io/helm-charts/ helm repo update随后验证图表是否可用helm search repo vm/输出应类似如下图表版本随发布迭代而变化此处为参考示例NAME CHART VERSION APP VERSION DESCRIPTION vm/victoria-metrics-cluster 0.35.0 v1.136.0 VictoriaMetrics Cluster version - high-performa... vm/victoria-metrics-agent 0.32.0 v1.136.0 VictoriaMetrics Agent - collects metrics from v... vm/victoria-metrics-common 0.0.46 VictoriaMetrics Common - contains shared templa... ...(list continues)...本指南将用到两个图表vm/victoria-metrics-cluster部署集群版核心组件vminsert、vmstorage、vmselectvm/victoria-metrics-agent部署vmagent负责抓取 Kubernetes 组件指标并写入集群。2. 通过 Helm Chart 安装 VictoriaMetrics 集群版VictoriaMetrics 集群版由三个服务组成vminsert接收进入的指标通过基于指标名和标签的一致性哈希consistent hashing将数据分布到各个vmstorage节点并负责按复制因子扇出写入vmstorage存储原始数据并按时间范围与标签过滤来服务查询vmselect跨所有配置的vmstorage节点拉取数据执行查询。创建高可用配置文件victoria-metrics-cluster-values.ymlcat EOF victoria-metrics-cluster-values.yml vmselect: extraArgs: dedup.minScrapeInterval: 1ms replicationFactor: 2 podAnnotations: prometheus.io/scrape: true prometheus.io/port: 8481 replicaCount: 3 vminsert: extraArgs: replicationFactor: 2 podAnnotations: prometheus.io/scrape: true prometheus.io/port: 8480 replicaCount: 3 vmstorage: podAnnotations: prometheus.io/scrape: true prometheus.io/port: 8482 replicaCount: 3 EOF下面逐项拆解这份配置是如何实现高可用的replicaCount: 3为vmselect、vminsert、vmstorage各创建 3 个副本Pod。vmstorage的 3 个副本满足复制因子为 2 时对节点数2*N-1 3的最低要求replicationFactor: 2为vminsert和vmselect启用复制vminsert利用replicationFactor扇出写入——每个样本写入两份并分发到不同的vmstoragePodvmselect也需要replicationFactor这样它才知道期望读到多少个副本以及何时将响应视为部分partial结果后文详述dedup.minScrapeInterval: 1ms为vmselect配置去重避免从多个vmstoragePod 读取数据时对样本重复计数。VictoriaMetrics 的时间戳精度为毫秒因此复制启用时-dedup.minScrapeInterval1ms是必须传给vmselect的配置如果你同时运行了多份配置完全相同的vmagent或 Prometheus 实例抓取同一批数据则应把该值设为抓取配置中的scrape_interval以便跨实例去重。官方文档同时建议在vmselect与vmstorage上设置相同的-dedup.minScrapeInterval值以保证查询结果一致性即使存储层尚未完成去重podAnnotations: prometheus.io/scrape: true开启指标抓取注解让集群自身可以被监控podAnnotations: prometheus.io/port: some_port指定抓取端口——vminsert为 8480、vmselect为 8481、vmstorage为 8482。执行安装以下命令在 default 命名空间部署集群helm install vmcluster vm/victoria-metrics-cluster -f victoria-metrics-cluster-values.yml安装成功的输出会包含各服务的访问方式大致如下NAME: vmcluster LAST DEPLOYED: Mon Mar 2 12:50:25 2026 NAMESPACE: default STATUS: deployed REVISION: 1 DESCRIPTION: Install complete TEST SUITE: None NOTES: Write API: The VictoriaMetrics write api can be accessed via port 8480 with the following DNS name from within your cluster: vmcluster-victoria-metrics-cluster-vminsert.default.svc.cluster.local. Get the Victoria Metrics insert service URL by running these commands in the same shell: export POD_NAME$(kubectl get pods --namespace default -l appvminsert -o jsonpath{.items[0].metadata.name}) kubectl --namespace default port-forward $POD_NAME 8480 You need to update your Prometheus configuration file and add the following lines to it: prometheus.yml remote_write: - url: http://insert-service/insert/0/prometheus/ for example - inside the Kubernetes cluster: remote_write: - url: http://vmcluster-victoria-metrics-cluster-vminsert.default.svc.cluster.local:8480/insert/0/prometheus/ Read API: The VictoriaMetrics read api can be accessed via port 8481 with the following DNS name from within your cluster: vmcluster-victoria-metrics-cluster-vmselect.default.svc.cluster.local. Get the VictoriaMetrics select service URL by running these commands in the same shell: export POD_NAME$(kubectl get pods --namespace default -l appvmselect -o jsonpath{.items[0].metadata.name}) kubectl --namespace default port-forward $POD_NAME 8481 You need to specify the service URL in your Grafana: NOTE: you need to use the Prometheus Data Source Input this URL field into Grafana http://select-service/select/0/prometheus/ for example - inside the Kubernetes cluster: http://vmcluster-victoria-metrics-cluster-vmselect.default.svc.cluster.local.:8481/select/0/prometheus/注意这里的 URL 格式写路径是/insert/0/prometheus/读路径是/select/0/prometheus/其中0是默认租户 ID集群版支持多租户。验证集群各 Pod 均已就绪kubectl get pods -l app.kubernetes.io/instancevmcluster预期输出vmstorage以 StatefulSet 形式按序创建因此 AGE 略有差异NAME READY STATUS RESTARTS AGE vmcluster-victoria-metrics-cluster-vminsert-788c76b69b-lphnn 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vminsert-788c76b69b-lxg2w 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vminsert-788c76b69b-qmtkp 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vmselect-65796bc88d-29cwm 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vmselect-65796bc88d-lz58p 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vmselect-65796bc88d-t42pr 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vmstorage-0 1/1 Running 0 106s vmcluster-victoria-metrics-cluster-vmstorage-1 1/1 Running 0 91s vmcluster-victoria-metrics-cluster-vmstorage-2 1/1 Running 0 76s3. 通过 Helm Chart 安装 vmagent为了从 Kubernetes 抓取指标并写入集群需要安装 vmagent 并为其配置附加设置。执行安装使用官方示例 values 文件helm install vmagent vm/victoria-metrics-agent -f https://docs.victoriametrics.com/guides/examples/guide-vmcluster-vmagent-values.yaml该示例 values 文件的完整内容已保存在本仓库中可直接查看docs/guides/examples/guide-vmcluster-vmagent-values.yaml。下面解析该 values 文件中的关键配置项。remoteWrite指向 vminsert 的写入端点remoteWrite定义了vmagent将遥测数据发送到的vminsert端点其值必须与第 2 步安装输出中remote_write的 URL 完全一致remoteWrite: - url: http://vmcluster-victoria-metrics-cluster-vminsert.default.svc.cluster.local:8480/insert/0/prometheus/metric_relabel_configs指标标签重写规则metric_relabel_configs定义对抓取到的指标执行标签重写的规则。示例文件在kubernetes-nodes-cadvisor任务中使用了如下规则metric_relabel_configs: - action: replace source_labels: [pod] regex: (.) target_label: pod_name replacement: ${1} - action: replace source_labels: [container] regex: (.) target_label: container_name replacement: ${1} - action: replace target_label: name replacement: k8s_stub - action: replace source_labels: [id] regex: ^/system\.slice/(.)\.service$ target_label: systemd_service_name replacement: ${1}规则含义依次为把pod标签复制为pod_name、把container标签复制为container_name、为指标补充固定标签namek8s_stub、从 cAdvisor 的id标签中提取 systemd 服务名到systemd_service_name。服务发现抓取 Kubernetes 组件指标示例 values 文件通过kubernetes_sd_configs配置了多种抓取角色覆盖 Kubernetes 常见指标源kubernetes-apiserversrole: endpoints抓取 API Server 指标使用 service account 的 CA 与 token 进行 HTTPS 认证kubernetes-nodesrole: node抓取 kubelet 暴露的节点级指标并利用labelmap将节点标签映射到指标标签kubernetes-nodes-cadvisorrole: nodemetrics_path: /metrics/cadvisor抓取节点上的容器运行时指标kubernetes-service-endpointsrole: endpoints抓取带有prometheus.io/scrape: true注解的 Service 端点kubernetes-servicesrole: service对带有prometheus.io/probe: true注解的服务执行黑盒探测metrics_path: /probe模块http_2xxkubernetes-podsrole: pod抓取带有prometheus.io/scrape: true注解的 Pod并通过relabel_configs将 Pod 名转换为kubernetes_pod_name标签——这正是后文验证查询中使用的标签。其中kubernetes-pods任务的典型 relabel 逻辑包括跳过 init 容器、通过keep_if_equal校验注解端口与容器端口一致、根据prometheus.io/scrape注解决定是否保留目标、将prometheus.io/path注解映射到__metrics_path__、修正抓取地址并最终把命名空间、Pod 名、节点名等元数据转换为kubernetes_namespace、kubernetes_pod_name、kubernetes_node标签。验证vmagentPod 已正常运行kubectl get pod -l app.kubernetes.io/instancevmagent预期输出NAME READY STATUS RESTARTS AGE vmagent-victoria-metrics-agent-6848c6b58d-87rf6 1/1 Running 0 32s4. 验证集群高可用状态先确认各 Service 已就绪kubectl get svc -l app.kubernetes.io/instancevmcluster预期输出NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vmcluster-victoria-metrics-cluster-vminsert ClusterIP 10.43.157.170 none 8480/TCP 4m41s vmcluster-victoria-metrics-cluster-vmselect ClusterIP 10.43.222.181 none 8481/TCP 4m41s vmcluster-victoria-metrics-cluster-vmstorage ClusterIP None none 8482/TCP,8401/TCP,8400/TCP 4m41s其中vmstorage的 Cluster-IP 为None属于无头服务Headless Service每个存储节点拥有独立的 DNS 名称。接着把vmselect的端口转发到本地以便通过 curl 查询kubectl port-forward svc/vmcluster-victoria-metrics-cluster-vmselect 8481:8481在另一个终端执行查询统计集群中vmselectPod 的数量curl -sg http://127.0.0.1:8481/select/0/prometheus/api/v1/query?querycount(up{kubernetes_pod_name~.*vmselect.*}) | jq命令拆解http://127.0.0.1:8481/select/0/prometheus/api/v1/query?query使用 VictoriaMetrics 查询 API兼容 Prometheus HTTP API获取指标数据querycount(up{kubernetes_pod_name~.*vmselect.*})指定查询表达式统计kubernetes_pod_name匹配vmselect的up指标数量即当前存活的vmselectPod 数管道到jq让输出更易读。预期结果中value应为3即我们配置的副本数{ status: success, isPartial: false, data: { resultType: vector, result: [ { metric: {}, value: [ 1773419630, 3 ] } ] }, stats: { seriesFetched: 3, executionTimeMsec: 3 } }也可以直接在浏览器中打开http://localhost:8481/select/0/vmui/使用 VMUI 界面执行同样查询0为默认租户 ID。输入count(up{kubernetes_pod_name~.*vmselect.*})并点击Execute query还可以通过ExplorePrometheus metrics浏览从 Kubernetes 集群采集到的指标例如 CPU 利用率5. 高可用故障演练现在通过模拟故障来验证高可用是否真正生效——直接关停一个vmstoragePod。将vmstorage副本数从 3 缩到 2kubectl scale sts vmcluster-victoria-metrics-cluster-vmstorage --replicas2确认集群中现在只有两个存活的vmstoragePodkubectl get pods -l appvmstorage预期输出NAME READY STATUS RESTARTS AGE vmcluster-victoria-metrics-cluster-vmstorage-0 1/1 Running 0 3h20m vmcluster-victoria-metrics-cluster-vmstorage-1 1/1 Running 0 3h20m用查询确认vmstorage节点数为 2curl -sg http://127.0.0.1:8481/select/0/prometheus/api/v1/query?querycount(up{kubernetes_pod_name~.*vmstorage.*}) | jq输出应显示 2 个节点{ status: success, isPartial: false, data: { resultType: vector, result: [ { metric: {}, value: [ 1773437033, 2 ] } ] }, stats: { seriesFetched: 2, executionTimeMsec: 5 } }由于每个数据点都存储在两个存储 Pod 上丢失单个 Pod 不会影响查询结果——只要每个时间序列至少有一个副本可达数据就始终可用。读懂响应中的isPartial判断查询结果是否完整可以检查响应中的isPartial字段当isPartial: false时表示响应在请求的时间范围和序列上是完整的即已经有足够数量的存储副本做出了响应依据所配置的replicationFactor当isPartial: true时表示vmselect未能从vmstorage取回它预期的全部数据返回的序列与数值可能不完整或不正确。这与 Cluster-VictoriaMetrics.md 中关于集群可用性的说明一致vmselect通过-replicationFactorN标志被告知只要不可用的vmstorage节点少于N个就返回完整响应因为剩余的存储节点被假定包含全部数据。同时-search.denyPartialResponse标志可用于在追求一致性优先于可用性的场景中让vmselect在任一存储节点不可用时直接返回错误。其余副本不受影响继续执行其他查询例如count(up{kubernetes_pod_name~.*vmselect.*})结果仍应为 3curl -sg http://127.0.0.1:8481/select/0/prometheus/api/v1/query?querycount(up{kubernetes_pod_name~.*vmselect.*}) | jq{ status: success, isPartial: false, data: { resultType: vector, result: [ { metric: {}, value: [ 1773437137, 3 ] } ] }, stats: { seriesFetched: 3, executionTimeMsec: 5 } }这说明查询与指标写入都不受单个存储 Pod 故障的影响。演练结束后将vmstorage扩回 3 个副本恢复正常运行kubectl scale sts vmcluster-victoria-metrics-cluster-vmstorage --replicas36. 总结与后续方向至此你已完成在 Kubernetes 上部署了一套高可用的 VictoriaMetrics 集群通过vmagent从运行中的服务采集指标并写入集群数据库为集群配置了dedup.minScrapeInterval与replicationFactor: 2以实现高可用通过关停一个vmstorage节点的故障演练验证了指标依然可用。需要牢记的要点复制因子为N时集群至少需要2*N-1个vmstorage节点本示例为N2、节点数 3复制会带来最多N倍的 CPU、内存、磁盘与网络开销如果底层已使用带复制能力的持久化存储可优先将复制下推到底层以降低成本复制不等于备份仍需配合 vmbackup 等工具定期备份数据vmselect与vmstorage应设置相同的-dedup.minScrapeInterval保证查询结果一致性。后续可以进一步探索深入阅读集群版完整文档了解多级集群、vmstorage分组与-globalReplicationFactor等高级用法使用 vmctl 将已有的指标数据迁移进 VictoriaMetrics参照 k8s-monitoring-via-vm-cluster 指南 部署 Grafana 并通过 Prometheus 数据源连接vmselect搭建完整的可视化监控大盘。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考