一、VictoriaMetrics 分布式架构
二、角色介绍
1. vmagent
vmagent是高性能数据采集组件，支持从多种数据源（如Prometheus exporters等）采集指标，并通过远程写入协议传输到VictoriaMetrics或其他兼容存储系统。
2. vminsert
vminsert是无状态的数据写入入口，负责将接收的指标数据按时间序列标签哈希分发到vmstorage节点，实现水平扩展的数据写入负载均衡。
分布式路由：基于一致性哈希算法，确保同一时间序列的数据始终路由到固定vmstorage节点，避免数据冗余。
水平扩展：可通过增加vminsert实例提升写入吞吐量，适用于高并发数据摄入场景。
3. vmstorage
vmstorage是VictoriaMetrics集群的核心存储组件，负责时序数据的持久化存储与快速检索。
1. 存储引擎优化：基于LSM树（Log-Structured Merge-Tree）和列式存储的结构，实现高效的数据写入与压缩，存储空间占用少。
2. 水平扩展：支持动态添加节点，数据按分片分布，单节点故障不影响集群整体可用性。
3. 查询优化：通过TSID（时间序列唯一标识）快速定位数据块，支持毫秒级响应海量数据查询。
4. vmselect
vmselect是分布式查询引擎，负责解析用户查询请求（如PromQL），从多个vmstorage节点聚合数据并返回结果。
5. vmalert
vmalert是告警管理组件，兼容Prometheus告警规则，定期从VictoriaMetrics读取数据并触发告警。
三、vminsert 原理
vminsert是无状态的数据写入入口，负责将接收的指标数据按时间序列标签哈希分发到vmstorage节点，实现水平扩展的数据写入负载均衡。
这里Metric raw name，做hash决定发往哪个vmstorage节点，将此时间序列填充到对应的vmstorage的待发buffer中，攒批并压缩发送给vmstorage。
重新路由(Rerouting)
vminsert 会维护每个和它交互的vmstorage的状态，通过不同的状态来决定是否触发重新路由
Ready：节点运行状况良好，可以接收数据，并且其缓冲区有足够的空间容纳新数据。
Overloaded：传入数据过多。当节点在其缓冲区中处理超过 30 KB 的未发送数据时，该节点被视为过载。
Broken （损坏）：节点暂时运行状况不佳。这可能是由于网络问题、vmstorage 端的并发限制或导致其拒绝数据的任何错误。
Readonly：节点处于 readonly 模式，通常是由于磁盘空间不足。它不会接受新数据，但会使用 readonly 响应确认 vminsert。
处于Overloaded、Broken、Readonly 状态一段时间后，都会触发进行重新路由。
目前社区分布式暴露的问题
vm遵循的原则是 “相同的时间序列将始终转到同一个vmstorage节点”。但是通过重新路由，打乱了vmstorage原来负责的时间序列，最终都需要注册这些新的时间序列。此过程非常耗费资源，并且会给系统带来很大的压力。
四、vmstorage 原理
几个重要的概念
时间序列，样本
1. 什么是TSID
Metric name raw 是 Metric name + Labels 的 byte[]形式，Canonical Name(标准名称) lables 经过字典序排序
一旦生成了Canonical Name具有这个排序的规范名称，它就会为该时间序列查找或创建一个唯一标识符，称为TSID（TimeSeries ID）。
type TSID struct { // AccountID is the id of the registered account. AccountID uint32 // ProjectID is the id of the project. // // The ProjectID must be unique for the given AccountID. ProjectID uint32 // MetricGroupID is the id of metric group inside the given project. // // MetricGroupID must be unique for the given (AccountID, ProjectID). // // Metric group contains metrics with the identical name like // 'memory_usage', 'http_requests', but with different // labels. For instance, the following metrics belong // to a metric group 'memory_usage': // // memory_usage{datacenter="foo1", job="bar1", instance="baz1:1234"} // memory_usage{datacenter="foo1", job="bar1", instance="baz2:1234"} // memory_usage{datacenter="foo1", job="bar2", instance="baz1:1234"} // memory_usage{datacenter="foo2", job="bar1", instance="baz2:1234"} MetricGroupID uint64 // JobID is the id of an individual job (aka service) // for the given project. // // JobID must be unique for the given (AccountID, ProjectID). // // Service may consist of multiple instances. // See https://prometheus.io/docs/concepts/jobs_instances/ for details. JobID uint32 // InstanceID is the id of an instance (aka process) // for the given project. // // InstanceID must be unique for the given (AccountID, ProjectID). // // See https://prometheus.io/docs/concepts/jobs_instances/ for details. InstanceID uint32 // MetricID is the unique id of the metric (time series). // // All the other TSID fields may be obtained by MetricID. MetricID uint64}2. MetricID 的生成规则服务启动时刻的纳秒值，在此基础上每次metricID 原子加1
func generateTSID(dst *TSID, mn *MetricName) { dst.AccountID = mn.AccountID dst.ProjectID = mn.ProjectID dst.MetricGroupID = xxhash.Sum64(mn.MetricGroup) mn.Tags[1] if len(mn.Tags) > 0 { dst.JobID = uint32(xxhash.Sum64(mn.Tags[0].Value)) } if len(mn.Tags) > 1 { dst.InstanceID = uint32(xxhash.Sum64(mn.Tags[1].Value)) } dst.MetricID = generateUniqueMetricID()}var nextUniqueMetricID = uint64(time.Now().UnixNano())// Returns local unique MetricID.func generateUniqueMetricID() uint64 { return atomic.AddUint64(&nextUniqueMetricID, 1)}3. 什么是indexdb？什么是索引？
indexdb 存储了时间序列的元数据索引
每日索引: 查询涵盖40天或更短的范围
全局索引：用于更长的范围
1. Tag -> metric IDs （Global index 全局索引）
– 这会将特定Tag映射到metric ID。例如，1 method=GET 49,53 或 1 status=200 67,99,100,120,130。它是用于查找指标 ID 的主要映射之一。
2. metric ID -> TSID （Global index 全局索引）
– 从第一个映射中找到metric ID 后，此映射将每个metric ID 链接到其 TSID。示例：2 49 TSID{metricID=49,...}。
3. Metric ID -> metric name （Global index 全局索引）
– 将metric ID 连接到我们存储的实际时间序列。示例：3 http_request_total{method="GET",status="200"}。
4. 已删除的指标 ID
– 是已删除指标 ID 的列表。示例：4 152。
5. Date -> metric ID （Per-day index 每日索引）
– 将特定日期映射到metric ID，从而帮助快速确定该日期是否存在指标。示例：5 2024-01-01 152， 5 2024-01-01 153。
6. Date + tag -> metric ID （Per-day index 每日索引）
– 与第一个映射类似，但范围限定为特定日期，以便更快地查找。示例：6 2024-01-01 method=GET 152,156,201。
7. Date + metric name -> TSID （Per-day index 每日索引）
– 此指标将查找特定日期的特定指标的 TSID。示例：7 2024-01-01 http_request_total{method="GET",status="200"} TSID{metricID=49,...}
如何写入？
这里引入了LSM的概念，数据会通过TSID 做hash，打散到若干的shard里面，之所以是多个shard是因为需要减少，shard 转入pending rows的时间，pinging rows 中会每5s将rows flush 到 in-memory parts中，parts中是由若干block组成的。
会在内存中做一次分组和归并，再刷到磁盘中。
如何查找？
如：http_request_total{status="500"} 中搜索2024-01-01和2024-01-02两天内的指标：
五、vmselect原理
vmselect 会将 用户的查询请求，发送给所有的vmstorage节点（MPP），并将vmstroage返回的查询结果进行合并去重后，返回给用户。
1. 分布式查询：并行向所有vmstorage节点下发查询指令，合并结果后返回。
2. 缓存机制：内置Rollup Result Cache，对常见聚合查询（如
sum、avg）结果缓存，降低重复计算开销。3. 查询优化：支持查询下推（Pushdown），将过滤条件提前到存储层执行，减少数据传输量。
4. 多租户支持：通过
AccountID实现租户级查询隔离，保障多团队共用集群时的数据安全性。