APO选择ClickHouse存储Trace的考量
OpenTelemetry生态已经很成熟,但对用户而言,选择OpenTelemetry仍然需要考虑以下几个问题:
- 探针的成熟度
- 海量Trace数据的存储和展示的问题
本文重点讨论海量Trace数据的存储与展示问题,APO定位是一个OpenTelmetry的发行版,本文将重点讨论APO团队是如何考虑这个问题的。
现有OpenTelemetry的Trace存储方案
OpenTelemetry生态过于灵活,选择众多,这也给用户带来了幸福的烦恼。
直接使用Jaeger+ElasticSearch方案
Jaeger作为老牌的Tracing方案,其使用习惯已经被很多用户所接受,Jaeger与OpenTelemetry同属于CNCF组织下的开源项目,所以两者也是结合最紧密的。
目前使用OpenTelemetry方式最快的方式使用的是Jaeger+ElasticSearch方案,该方案成熟。但是由于ElasticSearch的存储查询效率并不高,当规模较大的时候成本较大,所以很多用户期望有更加高效的存储方案。
新起的开源Signoz与Uptrace的做法
Signoz与Uptrace是近几年OpenTelemetry生态的发行版本,这两者都选择了ClickHouse作为存储方案,ClickHouse由于其强大的压缩和查询能力,成为很多可观测性方案的标准做法。
Signoz与Uptrace做法相同:自定义ClickHouse的表结构
自定义ClickHouse的表结构的好处在于,所有的内容完全能够自己掌控,但是坏处是其他生态产品很少会基于该自定义表结构进行演进,从而没有办法与其他生态集成。
大量已经习惯了使用Jaeger用户的在使用Signoz和Uptrace的时候都有一定的学习成本,比如需要理解:
- Span自身花的时间应该如何查找
- Span的tag应该如何才能查看
这对于没有接触过Jaeger的用户而言是可行的,选择Signoz和Uptrace没有太多差别,但对于已经熟悉Jaeger的用户不大友好。
ClickHouse官方的Exporter方式
ClickHouse官方针对OpenTelemetry生态推出了Exporter,解决了Trace如何落地到ClickHouse的问题,但是并未搭配界面使用,这意味着用户使用ClickHouse官方Exporter的用户,需要定制页面完成Trace的展示和分析工作,这对于绝大部分用户而言并不友好。
Jaeger 2.0 基于ClickHouse的实现Tracing存储方案
具体可以参考文章:迈向 Jaeger v2:更多 OpenTelemetry!
虽然当前Jaeger 1.X版本并没有正式支持ClickHouse,而是在1.57之前通过RemoteStorage 的插件方式支持,具体见链接,在最新的1.58之后,RemoteStorage 就不再支持了。