背景

2022年开始，在公司内部大量的推广落地指标周边系统和相关培训，大量业务、技术都开始使用指标来做可观测，但是随着业务在这两年的不断扩展，加上开发持续完善可观测，造成数据量急剧增长，metrics 数量由最初的几百万上涨至近1亿；为了处理和存储不断增加的指标数据，公司当时选择了thanos作为解决方案，thanos作为prometheus的扩展，旨在提供长时间存储和高扩展性，然而随着数据量的爆炸性增长，Thanos开始暴露出来一些瓶颈和高资源消耗的问题，我们发现系统开始下降，查询响应变长，存储开销增加，甚至在高峰期出现了服务不可用的情况；

尝试对thanos做了很多优化和治理，但是还是会存在问题，为了进一步提升系统的性能和灵活，我们根据社区的开源产品做了测试和对比，最终我们决定将监控存储系统从thanos切换到VictoriaMetrics；

下面我们将分享一下我们是如何选择vms的以及迁移的预期收益等，这是一个连续的文章系列，接下来我们还有切换的过程和我们对监控做了那些建设，大家敬请期待。

VictoriaMetrics 简介

metrics在监控领域已一统江湖，那么指标的存储组件tsdb比较多，各个组件的性能、高可用性、维护成本等各有差异；在这几年vms在社区的崛起和快速的迭代速度受到了光大社区开源爱好者和企业的青睐，我们今天主要是来介绍这款产品为什么在社区那么火热，首先我们先了解VictoriaMetrics是什么，它是一个快速、高效和可扩展的时序数据库，可作为Prometheus的长期存储。查询promql，使用grafana看图时，可以直接用VictoriaMetrics源替换掉prometheus源。并旨在提供较低的资源消耗（如CPU、内存和存储）同时维护较快的数据查询速度。VictoriaMetrics 不仅仅是时序数据库，它的优势主要体现在以下几点。

• 完全兼容prometheus相关协议

• 高性能：拥有同类型产品数十倍的性能优势，对存储引擎做了优化，减少了对Cpu、内存和存储的消耗。

• 高压缩率：采用了先进的时序数据压缩算法，存储空间利用率更低，大大降低了存储成本。

• 易运维：设计简单，容易部署，在保证了功能强大的同时，减少了组件之间的依赖。

• 高可用：节点之间支持数据冗余和故障转移，某节点故障致数据不丢失，且快速的恢复运行。

• 全局查询：多个 Prometheus 实例或任何其他数据源可能会将数据摄取到 VictoriaMetrics。

• 开放的社区：拥有强大的社区，定期发布更新和新的特性，并且提供了详细的文档和技术支持。

VictoriaMetrics 技术原理流程

VictoriaMetrics架构

VictoriaMetrics 存储引擎特性

VictoriaMetrics 是一个高性能、可扩展的时间序列数据库（TSDB），其存储引擎在处理大规模数据时表现尤为出色。在 VictoriaMetrics 中，TSID、LSM 和 SSTable 是存储引擎的关键组成部分。它们各自发挥着重要作用，共同解决了时间序列数据存储的多种挑战。以下是它们在存储引擎中的详细作用。

LSM 树（Log-Structured Merge-Tree）

LSM 树是一种适合高写入负载的索引数据结构，通过将写操作转换为顺序写入来提高写入性能。这种数据结构特别适用于时间序列数据的存储。

• 写入流程：当新数据写入 VictoriaMetrics 时，首先被写入内存中的 Memtable。这是一种内存中的数据结构，可以快速地处理写操作。当 Memtable 达到一定大小后，它会被“刷入”磁盘生成不可变的 SSTable 文件。

• 合并操作：随着时间的推移，系统会有多个 SSTable 文件。为了防止查询性能下降，后台进程会定期将这些 SSTable 文件合并为更大的 SSTable 文件。这个过程称为 Compaction，能够减少磁盘碎片，并提高查询效率。

SSTable（Sorted String Table）

SSTable 是一种不可变的数据文件，包含有序的键值对。每个 SSTable 文件内的数据都是按键排序的，这使得查找和区间查询非常高效。

• 写入和存储：当 Memtable 被刷入磁盘时，将其数据写入一个新的 SSTable 文件。由于 SSTable 是不可变的，所有更新操作都会生成新的 SSTable 文件。

• 索引和查找：SSTable 内部包含多个层次的索引结构，能够快速定位键值对。通过使用布隆过滤器（Bloom Filter）和稀疏索引（Sparse Index），可以快速判断某个键是否存在以及其在文件中的位置。

• 合并和压缩：多个 SSTable 文件的合并操作不仅提高了查询效率，还通过重复数据删除和压缩算法进一步减少了存储空间。

TSID（Time Series ID）

TSID 是时间序列数据的唯一标识符，是根据数据的标签（labels）生成的唯一哈希值。它在数据写入和读取过程中都起到了核心作用。

• 唯一标识：通过为每个时间序列生成唯一的 TSID，确保数据在存储和索引过程中能够正确区分不同的时间序列。

• 高效索引：基于 TSID 进行数据存储和检索可以显著提高索引和查找的效率。

• 分布式存储优化：TSID 有助于在分布式存储系统中均匀地分布数据，减少单节点负载和避免热点问题。

VictoriaMetrics 数据写入流程

数据接收 ( vminsert)

• 数据接收入口: 所有新的监控数据首先被发送到 vminsert 组件。 vminsert 是专门负责接收和处理写入请求的组件。

• 数据解析和 TSID 计算:

• 数据解析: vminsert 解析接收到的数据，将其转换为内部表示格式。

• TSID 计算: vminsert 通过标签（labels）的哈希函数来计算每个时间序列的 TSID（时间序列 ID）。TSID 是根据时间序列的标签生成的唯一标识符，确保相同标签的时间序列能够高效索引和存储。

• 选择 vmstorage 节点:

• 一致性哈希算法: 基于计算得到的 TSID， vminsert 使用一致性哈希算法选择合适的 vmstorage 节点进行数据存储，确保数据均匀地分布在集群中。

数据存储 ( vmstorage)

• 写前日志和内存缓冲区:

• 写入 Memtable: 数据被发送到 vmstorage 节点后，首先写入内存中的 Memtable，基于 TSID 进行组织和索引。

• 记录 Write-Ahead Log (WAL): 为了保证数据的持久性，所有写入操作先记录到 Write-Ahead Log（WAL），即使系统崩溃，也可通过重放 WAL 恢复数据，确保数据一致性。

• LSM 树结构:

• 数据排序和索引: Memtable 中的数据根据 TSID 进行排序和索引，确保高效的写入和快速的查找。

• 生成和合并 SSTable 文件:

• 刷入磁盘: 当 Memtable 达到预定大小或时间间隔时，数据会被批量刷入磁盘，生成不可变的 SSTable 文件，确保持久存储。

• 后台合并: 在后台，多个 SSTable 文件会定期合并，以减少文件数量，同时优化查询性能，更高效地进行数据检索。

VictoriaMetrics 数据读取流程

发起查询请求 ( vmselect)

• 查询处理入口: 用户（例如，通过 Grafana）发起的查询请求首先到达 vmselect 组件， vmselect 负责处理查询请求并返回查询结果。

• 查询解析和 TSID 获取:

• 查询解析: vmselect 解析查询语句，将其转换为内部可处理格式。

• TSID 获取: 根据查询条件中的标签， vmselect 通过与 vminsert 类似的哈希计算生成对应的 TSID，以便确定需要访问的 vmstorage 节点。

数据检索和处理 ( vmstorage)

• 内存查找: vmselect 发出的查询请求到达指定的 vmstorage 节点，首先在内存中的 Memtable 中查找数据。如果 Memtable 中包含符合查询条件的数据，会立即返回。

• 磁盘查找: 如果 Memtable 中的数据不足以满足查询，系统会进一步查找 SSTable 文件。

• 基于 TSID 的查找: vmstorage 使用多级索引，特别是稀疏索引和布隆过滤器，通过 TSID 快速定位数据块，从而减少磁盘 I/O 操作，提高查询速度。

• 并行处理: vmselect 可以并行从多个 vmstorage 节点和 SSTable 文件中读取数据，加快数据检索速度。

数据合并和聚合 ( vmselect)

• 多源数据合并: vmselect 从多个 vmstorage 节点获取数据后，需要合并这些数据，以生成完整的查询结果。

• 基于 TSID 合并: 在合并过程中， vmselect 基于 TSID 对数据进行去重和整合。

• 实时聚合: 如果查询请求包含聚合操作（如 sum, average 等）， vmselect 会在合并过程中进行实时计算，完成聚合处理。

• 返回结果: 最终处理好查询结果后， vmselect 会将数据返回给用户（通常通过 Grafana 等监控工具显示）。

VictoriaMetrics vs thanos

架构设计对比

Thanos

Thanos 是一个基于 Prometheus 的高可用性监控解决方案，主要组件包括：

• Thanos Sidecar：与 Prometheus 一起运行，负责从 Prometheus 内部存储中获取样本数据，并将其上传到对象存储。

• Thanos Store Gateway：用于读取对象存储中的时间序列数据，并提供查询服务。

• Thanos Compactor：处理对象存储中的块数据，进行压缩、合并和垃圾收集。

• Thanos Querier：允许通过 PromQL 进行全局查询，整合来自多个存储源的数据。

• Thanos Receive：接收 Prometheus 的远程写入数据，并保存到对象存储。

优点：

• 高可用性和容错性强。

• 支持水平扩展，对于全局查询和长时间存储特别有优势。

缺点：

• 架构复杂，需要管理多个组件。

• 配置和运维成本较高。

VictoriaMetrics

VictoriaMetrics 是一个高性能、可扩展的时间序列数据库，主要组件包括：

• vminsert：处理数据写入请求，将数据分发到适当的存储节点。

• vmstorage：存储实际的数据，基于 LSM 树和 SSTable 实现高效存储和查询。

• vmselect：处理查询请求，从多个存储节点读取并聚合数据。

优点：

• 架构简洁，相对于 Thanos，组件数量少，管理更容易。

• 高性能，特别是在写入和查询方面表现优异。

• 易于扩展，通过增加存储节点实现水平扩展。

缺点：

• 生态系统和开源社区规模较小，相较于 Thanos，第三方工具和社区支持可能少一些。

数据写入

Thanos

• 流程：Prometheus 将数据写入本地存储后，Thanos Sidecar 会定期将数据上传到对象存储（如 S3），同时将数据推送到 Thanos Receive（如配置了远程写入）。

• 性能：由于需要经过 Prometheus 本地存储和对象存储的中间环节，写入时可能存在一定的延迟。

• 复杂性：涉及多个组件的交互，配置和监控较为复杂。

VictoriaMetrics

• 流程：数据通过 vminsert 接受并直接写入到 vmstorage，使用 TSID 标识数据，并采用 LSM 树将数据写入 Memtable，同时记录到 WAL，然后定期刷入磁盘生成 SSTable。

• 性能：高性能写入路径，通过 LSM 树和顺序写入优化，写入速度快，延迟低。

• 复杂性：写入流程简洁，只有少量组件参与，配置和管理较为简单。

数据读取

Thanos

• 流程：用户发起查询请求时，Thanos Querier 会从多个 Thanos Store Gateway 中检索数据，整合来自对象存储和 Prometheus 实例的数据。

• 性能：由于涉及远程对象存储的访问和多个组件的通信，查询延迟可能较高，特别是在处理历史数据时，并且thanos会去读prometheus实例，这样大量的查询会到负责收集和上传的Sidecar上面，从严格意义上面没有真正的做到读写分离

• 功能：支持 PromQL 全局查询，能够整合多个 Prometheus 实例的数据，适合大规模分布式查询。

VictoriaMetrics

• 流程：用户发起查询请求时， vmselect 会解析查询语句，通过 TSID 定位需要访问的 vmstorage 节点，并从每个节点中检索数据，通过多级索引和布隆过滤器快速定位。

• 性能：查询速度快，通过并行处理和高效的索引结构，数据合并和聚合快速响应，并且对比与thanos从远程检索数据，这种本地连接的具有更高的可靠性和可用性

• 功能：支持 PromQL 查询，并能够处理大规模数据的实时和历史查询。

运维成本

Thanos

• 硬件和存储成本：需要运行多个组件（Sidecar、Store Gateway、Compactor、Querier、Receive），每个组件都需要计算和存储资源，且依赖外部对象存储（如 S3），存储和带宽成本较高。

• 维护成本：由于组件繁多，配置和维护的工作量较大，需要专业运维团队进行管理和优化。

VictoriaMetrics

• 硬件和存储成本：架构简洁，主要组件为 vminsert、 vmstorage 和 vmselect，整体计算和存储资源需求较低。由于高效的压缩和存储机制（LSM 树和 SSTable），内存和存储空间利用率高，成本较低。

• 维护成本：配置和运维较为简单，组件较少，管理方便。升级和扩展相对容易，减少运维负担。

总结

• 架构：Thanos 架构复杂，VictoriaMetrics 架构简洁。

• 数据写入：VictoriaMetrics 写入路径优化更好，延迟低；Thanos 写入路径较长，延迟较高。

• 数据读取：VictoriaMetrics 查询性能更优，特别是高并发和大规模数据；Thanos 查询涉及多个组件，延迟较高。

• 托管成本：VictoriaMetrics 资源需求和运维成本较低；Thanos 资源需求和运维成本较高。