可观测性 Trace 全量存储——之开篇

01

为什么要写这个系列

1.1 被忽视的 Trace 存储

可观测的三大支柱 Trace、Metric、Log

• Metric 有数不胜数的一系列 TSDB 系统，如 InfluxDB、TDengine、Druid、M3DB、VictoriaMetrics 等等

• Log 也有很多，如 ES、Clickhouse、Doris、Loki 等等

• Trace 通常是被当做规范化的 Log 来对待的，因此一般存在 Log 对应的系统上，然而 Trace 的量级最大，却没有一个专门的存储系统，存储成本自然偏高一些

1.2 Trace 全量和采样的争论

对于 Trace 的存储目前主要有 2 派：

• 采样派

Trace量大成本高使用率低

• 全量派

一旦采样，很难满足日志和Trace的关联一旦采样，很难满足各个应用的多样化诉求链路完整下的采样也是需要额外耗费不少成本的

 02 

如何选择

对于 Trace 存储，就面临一个抉择：到底是采样还是全量？这就好比 A、B 2 个方案，各有优缺点，到底怎么选？

不同的人会有不同的观点，也没法说某种观点就是错的，每种方案也各有人选择

其中的一个看法视角是：缺点是否可以挽救，如果缺点可以从别的地方挽救回来，那么就相当于继承了优势又挽回了劣势

比如这里的采样方案，缺点是不可挽救的，既然选择采样就必然会牺牲一些用户体验，而全量方案用户体验的优势是有了，成本的劣势是可以通过优化的方式来解决的，所以全量的方式会更有发展空间

 03 

怎么解

3.1 明确题目

Trace 存储可能有如下需求：

上述过滤查询 traceId、spanId 的功能则交给类似 exemplar 的模块去实现。对于 Trace 存储来说，最主要的需求就是拿着 traceId、spanId 去查 Trace 内容，即一个典型的 kv 存储，kv 存储有太多的系统可以满足了

这个 kv 存储也有自己的特点

●     v 的大小通常比较大，0~10M 都有可能

3.2 常见解法

采样下的解法：

• 货拉拉全链路监控演进史
  

• 分布式链路追踪在字节跳动的实践
  

全量下的解法：

• 饿了么 EMonitor 演进史
  

• 得物App全栈可观测平台落地实践
  

我们这里主要说全量下的解法：

3.3 下篇-性能优化（待续）

最终的优化效果：每天 1PB 的原始 Trace，高峰期 1300 万 tps 的 Trace 写入，只用了 110C 的计算资源和 80T 的存储，单 Span 查询平均耗时 200ms，就可以实现上述的 kv 的写入和查询。

这个优化效果基本达到了用采样的资源实现了全量的存储。

那这里的优化重点是哪些呢？

• 客户端需要配合全量做哪些性能优化

• 有没有减少 Trace 的方式

• 服务端如何做到不反序列化 Trace 原始内容

• HBase、Clickhouse 等在这个 kv 场景下，存在什么问题？有没有更好的方案？

敬请期待下篇内容