方法
适用相同的协议Prometheus remote write 协议写入和同样的promQL(query和query_range)用例。由于victormetrics和thanos架构上差异，尽量使用同等的资源，对比两种tsdb方案如何处理相同的工作负载及分配和使用资源的效率如何。
基准测试在虚机中运行，主机节点配置32c64G使用SSD
Prometheus测试工具
使用Prometheus-benchmark工具。
-
使用真实的node-exporter作为指标的来源
-
使用node-exporter告警规则作为查询来源
-
适用node-exporter常见的promQL作为range_query
-
模拟真实场景的指标流失率
通过控制targetsCount、scrapeInterval、scrapeConfigUpdatePercent 、scrapeConfigUpdateInterval 模拟真实的采集场景
通过queryInterval、alerts promQL、range_query promQL列表模拟真实的告警和查询场景
说明：
基准测试中的每个node_exporter目标都会生成大约 1200个（取决于node_exporter运行的硬件）时间序列。 targetsCount=1000并以120k 样本/秒的摄取速率
scrapeInterval=10s生成约120万个活动序列到每个配置的远程存储。 每10分钟生成约 12k个新时间序列的流失率 。
部署
victormetrics 1.91.3 cluster
| 模块 | cpu | mem | disk |
|---|---|---|---|
| vminsert、vmselect | 8 | 16 | |
| vmstorage | 32 | 64 | 2T ssd |
thanos 0.31 Prometheus0.42
| 模块 | cpu | mem | disk |
|---|---|---|---|
| receive | 32 | 64 | 2T ssd |
| store、query | 8 | 16 | |
| s3 | 32*4 | 64*4 | 2T ssd*4 |
| nginx | 4 | 8 |
压测程序
Prometheus-benchmark
| 模块 | 副本 | 说明 |
|---|---|---|
| vmagent-thanos | 1 |
config-updater vmagent node-exporter nginx |
| vmagent-vm | 1 |
config-updater vmagent node-exporter nginx |
| vmalert-thanos | 1 |
vmalert alertmanager press |
| vmalert-vm | 1 |
vmalert alertmanager press |
| vmsingle | 1 |
victoria-metrics 压测客户端监控 |
参数设置：
targetsCount:1000 queryInterval=10s scrapeConfigUpdatePercent=1 scrapeConfigUpdateInterval=10m存储统计
- 摄入速率：36万样本/s
- 活跃时间序列：385万
- 存储样本数：255亿
测试结果
磁盘使用情况：
- victormetrics 16G，相当于每个样本使用0.72字节（16G/255亿）
- thanos receive 50G，相当于每个样本使用2.25字节（50G/255亿）。thanos receive被设计用来存储热数据，未开启压缩、合并，且存有wal日志，存储空间使用是victormetrics 3倍左右，上传S3并启用合并后两者的存储空间的占用会更小
磁盘IO使用情况：
victormetrics会以均值10MB/s速度写入磁盘，thanos receive均值只有2MB/s左右。victormetrics会做文件merge，写入峰值为55MB/s。thanos receive会做head block切割，写入峰值2小时一次为72MB/s。读取方面都较小。
cpu使用率：
victormetrics使用大约2核，thanos receive使用了6个核。
内存使用情况：
victormetrics vmstorage使用了4.5G内存，峰值变化不大，thanos receive使用了大约14G的内存，且峰值高达15G。如果机器没有足够的内存，可能会导致OOM崩溃，在加大target数量时，可以复现这个现象。
结论
victormetrics和thanos receive模式都可以用几个cpu核心的主机承载几千个target数百万的时间序列的摄入。
当前测试用例下，与thanos相比，victormetrics消耗更少的cpu，内存节省接近3倍，磁盘空间节省将近3倍。但是thanos receive被设计用来存储短期数据，如果加上S3和Compactor的加持，thanos的长期的存储优势巨大。
从测试结果看
如果对数据长期存储（半年、1年）有刚性需求，或者对thanos特性（全局视图、历史数据查询、生态）有刚性需求，thanos有优势。
如果是实时监控场景，对性能要求更高，架构简单，则victormetrics更有优势。
