原文：https://docs.victoriametrics.com/guides/vm-architectures/。作者／维护方：VictoriaMetrics 文档贡献者。中文翻译整理与校注：未完纪；源文核对日期：2026-10-05。
监控系统需要多复杂，取决于两个问题：它要承受多大范围的故障，以及它要处理多大的负载。单实例、多副本集群、跨可用区部署和 cell 架构并不是一条必然要走到尽头的升级路线。更合理的做法，是先确定不能接受的故障范围，再选择相应的数据副本、路由和查询策略。
本文完整翻译整理 VictoriaMetrics 官方的 VictoriaMetrics topologies，按原文顺序讨论可用性、单可用区与跨区域架构、缓冲、读路径、告警和租户隔离。原文中的概念性保证与成本估算，都需要结合具体配置理解；涉及前提的地方加入了明确校注。本指南讨论架构选择，不是一套开箱可用的部署配置。
先定义故障范围，再谈可用性
可用性不只是一个百分比，它还应该说明系统针对什么风险作出承诺。例如，99.9% 可用性在一个月内约允许 44 分钟停机。决定是否追求更多个“9”之前，应先判断：在已定义的风险范围内，这些停机时间是否能接受？原文指出，可用性目标继续提高，系统复杂度和运维成本往往会急剧增加。
这里的故障影响范围，也称 blast radius，可能是一台进程所在的主机、一个 Kubernetes 集群、一整个可用区，或者一个地理区域。不同架构解决的是不同范围的问题：
- 基础单实例：适合非关键系统，没有内建冗余，实例本身就是故障边界。
- 单可用区集群：通过多副本应对个别节点或实例故障，但无法抵御整个可用区停摆。
- 多集群、多可用区：把完整集群放入独立故障域，用于应对整个集群、可用区或数据中心故障。
- 超大规模 cell 架构：把路由和存储组织为多个单元，在单元或可用区故障时尽量维持服务，并可将整套架构复制到另一地域。
- 逻辑层：叠加在上述任意物理架构上，处理多团队或多客户的数据访问隔离；它不是另一级物理容灾。
还要把两个目标分开：韧性解决“故障发生后能否继续工作”，主要依靠组件和数据的副本；扩展性解决“如何处理更多负载”，主要依靠在各层增加组件来分摊工作。后面的拓扑就是这两种手段针对不同故障范围的组合。
基础架构：一个实例承担全部工作
基础方案适合个人项目、开发测试和非关键系统监控。一个 VictoriaMetrics 实例负责存储、检索和提供指标，安装可参考 VictoriaMetrics Single。
它的优点是直接：部署快，不需要额外的分布式组件；同一份数据不必重复写入或传输，也无需保存额外副本，因此计算、网络和存储开销较低。代价是这个实例成为单点。这里的“没有高可用能力”是指没有内建故障冗余，并非说一个健康的单实例没有正常可用时间。
一旦节点失效，数据可能暂时不可用，直到实例重启或存储恢复；若存储损坏，也可能丢失数据。可以在硬件、虚拟化、持久卷或应用层建立备份与恢复机制，VictoriaMetrics 也提供 备份工具。但备份的恢复时间和恢复点需要单独设计，不能把备份等同于在线副本。
单可用区集群：应对节点级故障
只部署在一个可用区的系统，无论规模大小，都可以选择完整的 VictoriaMetrics 集群。它通常运行在一个 Kubernetes 集群中，vminsert、vmselect 和 vmstorage 均部署多个实例。数据在存储节点间分片，并通过 vminsert 的 -replicationFactor 设置复制份数；查询侧也必须按官方要求了解对应复制因子。部署入口见 VictoriaMetrics Cluster。
如果副本放置和路由正确，某个组件失效时可由其余实例继续工作。但这仍是一套位于同一故障域的系统：整个 Kubernetes 集群、可用区或数据中心不可用时，这一监控系统也会整体不可用。复制因子增加的是数据副本成本，原文用 RF=2、RF=3 近似说明存储量分别变为两倍、三倍；vminsert、vmselect 的横向扩展则主要增加吞吐。这些倍数不是整套服务总成本的精确报价。
应用层复制与存储层复制
应用层复制：使用 -replicationFactor=N，让 VictoriaMetrics 负责把数据写入不同 vmstorage 节点的 N 个副本。集群知道这些副本的存在，因此在部分存储节点故障时，可以通过其余副本满足查询。原文以故障节点数小于复制因子作为可承受范围的说明。
它的优势是复制逻辑由应用掌握，在自建机房和不同云平台上遵循同一套机制。代价是需要多节点写入，慢节点或过载节点可能增加写入延迟；参与的节点越多，遇到异常节点的机会也越多。应用层复制的查询完整性依赖副本确实已写入、路由和查询复制参数正确、所需数据未因保留期或其他操作而消失，不能推导为对任意历史时刻都保证全量数据。
存储层复制：把 VictoriaMetrics 的复制因子设为 1，底层改用云平台提供的复制卷，例如可用区内复制的 AWS EBS 或 Google Zonal Persistent Disk。数据复制的 CPU 与网络工作更多由存储基础设施承担。
不过，复制卷不等于第二个在线 vmstorage 查询实例。某个存储进程重启、维护或故障时，它负责的分片仍可能暂时不可查询。节点或磁盘失效后，还可能需要把持久卷重新挂载到另一节点。原文列出正常卸载/挂载约 10–60 秒、强制卸载情形最长约 5 分钟的示意；实际时间取决于平台、存储类型和故障状态，不是服务承诺。
查询要返回部分结果，还是返回错误
分布式系统中的局部失败很常见。当只能拿到部分数据时，可以优先让查询继续返回，也可以要求它失败。这是读取可用性与完整性的取舍。
默认情况下，即使部分 vmstorage 节点不可用，vmselect 仍会从健康节点取回结果。当无法响应的节点数达到复制因子等条件、无法确认结果完整时，响应中的 isPartial 会标为 true。这样仍能查看可用的那部分数据，系统可以降级运行；风险是调用者忽略部分结果标记，依据不完整曲线做出错误判断。
另一种做法是给 vmselect 配置 -search.denyPartialResponse。如果不能按复制布局获得完整结果，就返回错误而不是部分数据。此时成功响应不会是查询引擎已知的部分响应，但读取可用性会下降。原文前后对节点数使用了“达到复制因子”与“超过复制因子”的不同措辞；判断应以实际副本布局和完整性条件为准，不能从这两句概括推导新的故障阈值。
校注：isPartial=false 与“禁止部分响应”并不是强一致性证明。未采集、未成功摄入、仍在发送队列中、已过期或已丢失的数据，不会因为这个标记就自动补齐。查询成功的语义应限定在已正确存储、可由当前查询路径取得的数据范围。
vmagent 缓冲：持久性与资源消耗
在 vmagent 与单机或集群存储之间，还需要决定：后端暂时不可用时，未发送样本存在哪里？默认情况下，vmagent 会把压缩后的未发送数据写入本地文件系统，形成发送队列。每个目标 URL 的磁盘使用上限由 -remoteWrite.maxDiskUsagePerURL 控制。原文有一处用了排版用长横线，复制参数时应使用 ASCII 连字符。
持久缓冲：原文指出，Operator 默认给队列使用临时存储。生产环境如果要求 Pod 重建后继续保留队列，必须显式配置 PersistentVolumeClaim（PVC），并确认持久卷确实挂载到队列目录。队列尚未达到容量限制、底层卷仍完好的前提下，未发送数据可以在进程或 Pod 恢复后重新发送。
这种方式需要磁盘容量和 I/O，把部署变成有状态系统。后端恢复时积压队列会集中回放，也可能给存储带来额外写压力。企业版还可把排队工作交给 Kafka 等外部消息代理，由 vmagent 读写 Kafka；这是有产品许可与配置条件的能力，不能假定所有部署都具备。
内存缓冲：如果把缓冲目录挂载到 tmpfs，I/O 发生在内存中；Kubernetes 中可用 emptyDir: { medium: "Memory" } 表达这种卷。它可以吸收短时网络中断，减少磁盘 I/O，但队列受内存容量约束，不具备持久介质的恢复能力。
原文把风险简述为重启丢失未发送数据。精确地说，应按卷生命周期判断：Pod 被删除重建或节点失效时，内存卷数据会丢失；同一个 Pod 内仅容器重启是否保留目录，则取决于挂载和运行方式。不能把所有“重启”混为一谈，也不能承诺短时网络中断一定没有性能影响。
单可用区里的故障会怎样传播
- 实例或 Pod 故障：应用层 RF≥2 且有效副本仍足够时，其余副本可继续工作；RF=1、仅依赖复制卷时，相应数据可能在重新挂载与调度期间不可用。
- 节点故障：Pod 重新调度，影响取决于复制模式、容量和存储恢复条件。
- 采集侧重启：PVC 队列在持久卷可恢复时保留；临时队列按其生命周期处理。
- 写入组件或存储暂时不可用：仍保留在队列中的样本可在重连后回放；已经因容量、内存卷销毁等原因丢失的样本不在此列。
- 整个可用区或数据中心故障：这一拓扑没有跨可用区保护，会整体中断。
多集群、多可用区：把完整集群放进独立故障域
对于必须承受整个数据中心或可用区失效的大规模服务，可以在不同可用区或地域部署两个或更多相互独立、能自行工作的 VictoriaMetrics 集群。全局无状态路由层负责分配写入和查询请求。无论采用 Active-Active 还是 Active-Passive，基本组件关系相似，但流量切换和容量规划必须符合所选运行方式。
每个参与故障接管的可用区都需要留出足以承担目标负载的容量。不能只验证正常情况下的一半流量能跑通，就认为另一个可用区失效后也能接管全部请求。
vmagent 为每个 -remoteWrite.url 目标设置独立的数据队列和工作池，这是隔离慢目标影响的机制。一个后端变慢时，发往其他后端的数据不必排在同一队列后面。但这些队列仍可能共享进程、磁盘、CPU 和网络，因此它减少相互牵制，并不意味着一个目标永远不会通过资源耗尽影响另一个目标。
优点是故障域分离：一个地点的故障、维护或配置问题通常不会直接摧毁其他地点的集群。代价是更多计算、存储和网络成本，而且为了接管故障流量，平时需要保留闲置容量。原文用两个可用区各按全量容量配置时约 50% 利用率、约 100% 额外容量的例子说明这一点；其他组件还可以考虑 VPA 或 HPA。这个数字只是容量模型，不是所有组件都必然翻倍的账单。
Active-Passive 主地域故障后，需要等待 DNS、负载均衡或 BGP 等路径切换，原文以分钟级说明可能的中断；切换完成前可能读到旧数据。Active-Active 可以把请求重路由到健康集群，但各目标写入进度不一致时，查询结果仍可能短暂不同。跨地域链路断开时，写入依赖 vmagent 缓冲，读取则可能持续返回落后数据，直到连接恢复并追上积压。
Cell 架构：把路由层和存储层分别扩展
更大规模的系统可以把存储组织成逻辑单元（cell），并把路由与存储路径分开。多个可用区组成逻辑存储组，其中每个单元运行基础集群。存储组之间可以保留完整副本，也可以分片并保留若干份副本。
例如，四个 cell 中为每条时间序列选择三个副本，均匀分布时每个 cell 约保存全部指标的 75%。这是副本放置的理想化比例，不是每个实际分片必然完全均衡。原方案在每个存储 cell 内把集群 -replicationFactor 设为 1，由全局路由层负责跨 cell 冗余。
独立的路由 cell 只负责接收与分发写入、查询流量，可以随着访问量扩展；存储 cell 则随着数据量扩展。为了应对整个地域不可用，还需要在第二个地理区域复制这整套架构。其优势是能够将节点、存储 cell 或可用区故障限制在较小范围内，并尽量降级运行；代价是组件多、冗余成本高，需要相当的自动化与控制面能力来维护路由和数据放置。
读路径 A：全局 vmselect 合并多个 cell 的数据
第一种组合优先追求能够取得的完整数据。写入侧用 vmagent 的 -remoteWrite.shardByURL 与 -remoteWrite.shardByURLReplicas 把时间序列分发到若干 cell，例如四选三。冗余发生在 cell 之间，因此比向所有 cell 写完整数据更省存储。
读取侧使用两级 vmselect：全局实例接收查询，再查询各存储 cell 的本地 vmselect，最后合并结果。逻辑路径是 Global vmselect → Local vmselects。原文解释，尤其在 Kubernetes 中，不一定能直接连接本地 cell 的 vmstorage；vmstorage 也不是对外的普通 HTTP 查询端点，因此使用本地 vmselect 暴露查询层更合适，不能随意用 NodePort 代替设计。
如果一个副本写入落后，全局查询有机会从另一个已收到数据的副本补齐缺口。代价是跨 cell 查询、重复读取、合并和聚合，需要更多 CPU、内存与网络，通常也增加延迟。它能补的是别处确实存在的数据，不能补从未摄入任何副本的样本；“有全局 vmselect”本身并不保证所有查询始终完整。
读路径 B：vmauth 的 first_available 选择一个可用 cell
另一种组合优先降低查询开销。全局 vmauth 以 first_available 策略把请求送到一个可用 cell，再由该 cell 内的 vmselect 执行查询。逻辑路径是 Global vmauth → Cell → vmselect，不做跨 cell 结果合并。
这要求每个候选 cell 都保存完整数据副本。写入侧应通过多个 -remoteWrite.url 把全部写入发送给每个 cell，而不是使用前一种只给部分 cell 分片的布局。如果读路径只选一个后端，却给它不完整的数据，查询自然缺失其余分片。
其优势是避免全局合并，查询资源消耗较低，跨 cell 的读取流量也少。代价是每个 cell 都存一份完整数据，而且存在数据新鲜度陷阱：某个目标写入变慢时，vmagent 会为它积压发送队列；该 cell 的查询服务可能仍然健康，因此 first_available 仍可能选中它，返回落后的结果。“能响应”并不等于“已追上最新写入”。
可以设计自动化，根据写入积压或其他新鲜度指标暂时移除落后 cell 的读取资格，但这需要额外状态和判定逻辑，不能从负载均衡策略名字中自动获得。
告警放在本地，还是放在全局
本地 vmalert：在每个存储 cell 内部署 vmalert，查询本地 vmselect，再把触发的告警发送给全局 Alertmanager 集群。本地查询路径短，规则计算延迟低。如果规则需要全局数据，这种方式要求每个 cell 持有完整副本；分片写入时，单个 cell 看不到全貌，不能正确计算需要全局数据的规则。只针对该 cell 自身数据的规则则应另行设计和限定范围。
原文还指出，每个 vmalert 向 Alertmanager 集群的各实例发送告警，会随着 cell 和 Alertmanager 数量增加而产生较多跨可用区、跨区域流量，网络成本需要计入。
全局 vmalert：把规则计算实例放入全局计算 cell，使用与用户相同的全局 vmselect 或 vmauth 入口读取，再把告警发往同一计算 cell 内的 Alertmanager。这样告警投递可以保持本地通信，也更适合通过全局 vmselect 汇总分片数据。
代价是每次规则计算都可能发起跨 cell 查询，提高延迟；在实际系统里，告警规则经常贡献大量读取负载。还要注意，如果其入口使用 first_available，告警同样继承该读路径的新鲜度风险。把 vmalert 搬到全局层，不会自动把旧数据变成新数据。
Cell 与地域故障时的表现
单个 cell 内的节点失效，可能降低该 cell 性能，由其他副本或单元继续承担全局服务。一个 cell 整体失效时，全局 vmselect 路径会尝试从健康副本合并数据，可能更慢，能否保持完整仍取决于有效副本是否足够；first_available 路径则切到健康 cell，但要检查新目标是否写入落后。整个地域故障时，另一个地域的复制架构接管，路由完成前可能出现暂时降级。以上均需要事先准备足够容量、路由与恢复流程。
多租户逻辑层：数据隔离与性能隔离分别设计
服务多个内部团队或外部客户时，可以在任何物理拓扑上增加多租户层。不同租户拥有自己的数据集合，也可能要求不同保留期。VictoriaMetrics 以 URL 路径中的租户标识（例如 AccountID）把数据从摄入到查询分入各自的命名空间。
在采集侧，vmagent 可以根据重标签规则识别数据所属租户，再按支持的多租户摄入方式传递相应标识；vminsert 与 vmstorage 按租户隔离数据。查询到达时，配置正确的 vmauth 验证访问者是否可以请求该租户，把获准请求交给 vmselect 查询对应数据。
校注：AccountID 只是命名空间，不是凭据。不能因为 URL 中包含租户 ID，就认为用户已经通过认证或授权。访问策略、允许的租户映射和绕过认证层的网络入口都需要单独控制。保留期能力也应结合产品版本和许可核对。
资源安排有两种基本方式。共享所有集群组件最节省资源、成本最低，但租户可能相互竞争：某个租户大量发送数据，会拖慢共享摄入层，形成“吵闹邻居”问题。
对于重要租户，可以单独建立 vmagent、vminsert、vmselect 等处理层实例，给它们更清楚的容量和调度边界。这样能增强处理层性能隔离，但组件池更多、成本和管理复杂度更高。原文将优点概括为完全性能隔离；实际若仍共享存储节点、磁盘、网络或宿主机，就不能承诺其他租户绝不会造成影响。
把架构承诺落实到可核验的条件
选择拓扑时，应把几个条件放在一起核对：需要承受哪一级故障；副本在什么故障域；查询从一个副本读取还是合并多个副本；写入落后时怎样判定新鲜度；发送队列能保留多久；告警看到的是全局数据还是局部数据；租户标识如何与真实权限绑定。
这些条件匹配时，架构才能兑现预期的可用性。备份、恢复和灾难切换仍需要单独演练。节点数、复制因子或一次成功查询，都不能替代对已摄入数据、有效副本和恢复状态的核实。
原文、引用与核验说明
原文：VictoriaMetrics topologies；作者／维护方为 VictoriaMetrics 文档贡献者。本文保留原文六幅拓扑图，图题和替代文本使用中文。有关复制、分片、缓冲和多租户的详细参数，请继续核对官方 集群文档、vmagent 文档、vmauth 文档 与 vmalert 文档。
本次读取的是 2026-10-05 可访问的滚动指南，原页没有固定软件版本号或可确认的个人署名。文中没有可执行脚本，参数和配置片段只做静态核对，没有部署集群、注入故障或测试性能。时间、成本和容量数字均作为上游示例保留，不构成 SLA。原页未见独立的文章转载许可说明；不以项目开源许可替代文章授权。
暂无评论内容