VictoriaMetrics 开发者笔记：团队内关于 Distributed Tracing 的调研，对比 Tempo 和 ClickHouse

谈到可观测性，人们总是会提起它的三大支柱：Metrics, Tracing, 和 Logging 。在 VictoriaMetrics，我们已经有了 Metrics 和 Logging 的解决方案 VictoriaMetrics 和 VictoriaLogs 。同时我们也一直听到很多声音，其中之一就是：VictoriaTraces 什么时候发布。

如果你也关心这个问题，那么相信这篇博客可以让你了解我们内部对 Distributed Tracing 解决方案的调研情况：会不会有 VictoriaTraces？它和竞品比起来怎么样？

1. 什么数据库适合 Trace Span

一个 Trace 是由许多 Span 组成的，所以要打造一个 VictoriaTraces ，我们首先思考的是，Span 长什么样子，什么数据库适合存储这种数据。

以下是一个 Span 的例子：

{ "name": "/v1/sys/health", "context": { "trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d", "span_id": "086e83747d0e381e" }, "parent_id": "", "start_time": "2021-10-22 16:04:01.209458162 +0000 UTC", "end_time": "2021-10-22 16:04:01.209514132 +0000 UTC", "status_code": "STATUS_CODE_OK", "status_message": "", "attributes": { "http.method": "GET", "http.target": "/v1/sys/health", "http.server_name": "mortar-gateway", }, "events": [ { "name": "", "message": "OK", "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" } ] } 

很容易留意到，它就是一系列 Key-Value 的组合，大部分 Key-Value 仅作展示，小部分（如 trace_id、attributes）可以被用作查询条件。

如果你恰好也有了解过 Logging 的一些解决方案，你会发现 Trace Span 和 Structured Log 很像：

1. Structured Log 和 Trace Span 都是由一系列的 Key-Values （或者 Fields ，Attributes ，Tags ，不管怎么称呼它们都行）组成，而这些 Key-Values 中有很多重复的内容。
2. 它们对写入量需求很大，一个企业每天可以轻松采集数 TB 甚至 PB 的 Logs ，Traces 也是一样。
3. 这些被保存下来的数据只有很少一部分会被查阅，所以围绕这个特点产生了很多采样方案。

当前，几乎没有数据结构能同时针对读性能、写性能、磁盘空间进行优化，在这个三个考察标准中通常只能满足其中一或两项。对于 Structured Logs 和 Trace Spans ，它们很显然更强调写入吞吐量以及磁盘空间。所以：

1. 基于 LSM-Tree 的数据结构比基于 B+Tree 的数据结构更合适。前者通常能提供更好的写入性能，而后者更强调查询性能。
2. Column-oriented 数据库比 Row-oriented 数据库提供更好的空间利用率，因为 Column （或 Field ）中数据的相似性更高，更易于压缩。反之，数据按 Row 存储时更容易获取一行内的数据，这对高性能的查询有帮助。

那么到这里，我们的目标稍微明确了一些：VictoriaTraces 可能是一个基于 LSM-Tree 的列式存储数据库。

2. 造新轮子？

在造轮子之前，我们需要先了解满足这些要求的数据库都有哪些。如果你是 Jaeger 的用户，你一定熟悉它的其中一种存储方案：ClickHouse。ClickHouse 在 Jaeger v1 中以 plugin 形式存在。到了 Jaeger v2 ，社区希望对其提供原生支持，这再一次说明基于 LSM-Tree 的列式存储非常契合 Trace Span 数据。

题外话：谁在用 ClickHouse 作为 Traces 存储？

• 当我还在 Shopee 工作的时候，内部 Tracing 平台是基于 Jaeger 改造的，它的存储最初是 Elasticsearch ，当规模逐步扩大后，被替换为 ClickHouse 。
• 后来，我入职了富途牛牛，尽管时间很短只有 3 个月，我与可观测团队还是有过一些简单的交流。它们的 Tracing 平台使用的是 Zipkin ，并且刚从 Cassandra 迁移到 ClickHouse 。
• 在加入 VictoriaMetrics 前，我在 TT 语音工作，当时使用的是腾讯云的 Tracing 平台。从一次数据导出中，我观察到很多地方有 ClickHouse 的身影，例如表名、数据结构等，所以腾讯云应该也是 ClickHouse 用户之一。

在 VictoriaLogs v1.0.0 版本发布后不久，我们发现它似乎也满足存储 Trace Span 的要求。它是为 Structured Logs 设计的，而我们前面说过，Structured Logs 和 Trace Spans 在方方面面都很相似。

所以，我们打算在从 0 开始构建 VictoriaTraces 之前，用 VictoriaLogs 先做一次 PoC （ Proof Of Concept ，概念验证），万一它能用，万一它很好用呢？

3. VictoriaLogs 数据模型 与 Trace Span

在 VictoriaLogs 中，每条 Log 是由多个 Fields 组成的，包含几个特殊 Fields 以及其余的普通 Fields：

1. Stream Fields：数据首先是按照 Stream Fields 来组织的，这可以用来缩小查询范围，它就像索引一样存在，例如 {application_name="...", env="..."}。一些高基数的 Value （例如 ip、user_id、trace_id）不适合作为 Stream Fields 存在。
2. Time Field：每条 Log 都应该带有时间，这个 Field 同样是为减少需要扫描的数据范围而设计的。
3. 普通 Fields：任何内容都可以以 Key-Value 的形式作为普通 Field 存在，它可以帮助优化查询。

要将 Trace Span 存储到 VictoriaLogs 中，思路也很简单：把所有的内容都平铺为 Fields ，并在其中挑选出特定的 Fields 作为 Stream Fields 即可。

考虑到 Service Name 和 Span Name（在 Jaeger 中也称为 Operation Name）通常都会被用作搜索 Traces 的首要条件，并且它们也不包含高基数的 Value ，所以它们就被设计为了 Stream Fields ，其余 Span Attributes 都被平铺成普通 Fields 。

4. Data Ingestion 性能

我们最关注的是 VictoriaLogs 的 Data Ingestion 性能与其他竞品比起来怎么样。

目前，热门的 Distributed Tracing 方案包括 Jaeger、Grafana Tempo。所以在测试中，我们选择了 Jaeger + ClickHouse / Jaeger + Elasticsearch / Grafana Tempo + S3 作为比较对象。

在这个 PoC 中，对比对象均分配了 4 CPUs 及 8 GiB 内存，其余组件则按需提供足量资源保证不成为瓶颈。

整体的测试架构非常简单：

为了直观对比不同方案的硬件资源需求量，我们控制变量，先尝试将 Ingestion Rate 保持在 10000 spans/s。此时得到的结果如监控所示：

题外话：为什么缺少 Jaeger + Elasticsearch 的测试结果？为什么用 10000 spans/s ？

遗憾的是，Elasticsearch 方案在 Ingestion Rate 仅为 5000 spans/s 时就开始出现队列拥堵和 Crash ，在更高的负载下无法保持稳定，因此未能出现在最终的对比中。

事实上，我们也在不同负载下做过多次测试，尝试让所有比较对象都能顺利完成。例如使 Tempo 数据写入本地磁盘而非对象存储，它可以通过 18000 spans/s 的测试，尽管这并不是 Tempo 的推荐使用方式。如果你对这些更为极限的测试感兴趣，请在文章下留言，或者前往 Slack 频道与我们讨论。

在 CPU 使用率上，VictoriaLogs (50.4%) < ClickHouse (69.4%) < Tempo (135%)。同时，ClickHouse 与 Tempo 的 CPU 使用率波动更明显。

如果仅对比 VictoriaLogs 和 ClickHouse ，在负载提升至 17000 spans/s 时，ClickHouse 的 CPU 波动问题会更加突出。

在内存用量上，**ClickHouse (14%) = VictoriaLogs (14.4%) < Tempo (53.3%)**，此时 VictoriaLogs 与 ClickHouse 的内存较为稳定，而 Tempo 使用了 4x 内存容量并且抖动明显，最终也出现了 OOM 的情况。

在数据增长体积上，相同时间范围内 VictoriaLogs (3.27 GiB) < ClickHouse (5.86 GiB)。Tempo 使用的是对象存储，根据平台提供的数据，其数据量约为 4.4 GiB，但是并不便于直观对比。因此我们在后续测试中对比了 Tempo 使用本地磁盘作为存储时的情况：

可以看出，虽然 Tempo 使用的对象存储成本更低，但是压缩率不如 VictoriaLogs 和 ClickHouse 。如果 VictoriaLogs 能在未来支持对象存储，那将变得更有竞争力。