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 就不再支持了。
APO对Trace存储的思考
不同表结构对性能影响没有显著差别
我们团队调研过Jaeger官方关于ClickHouse不同表结构对于Trace插入和查询的影响(主要对比Jaeger RemoteStorage 的表结构和ClickHouse的官方exporter表结构),虽然表结构对性能影响有些许差异,但在插入、查询、压缩比方面各有千秋,而且性能差异对大部分用户也是能接受的。具体见链接。
用户习惯最重要
由于APO在向导式界面已经屏蔽了Trace的细节,先通过指标和告警引导用户到需要查看的Trace时,用户才通过TraceID查看Trace。此时,我们认为用户能够以最小的成本理解Trace细节最重要,所以我们引入了Jaeger来展示Trace细节,并没有重新开发页面或者选择signoz、uptrace的方案。
APO对Jaeger RemoteStorage的扩展
Jaeger2.0 已经明确会支持ClickHouse了,在Jaeger 2.0发版之前,APO做了Jaeger RemoteStorage的扩展,使其能够支持1.58以后的版本。具体实现项目见链接。
总结
ClickHouse不同的表结构对性能会有差异,但是只要使用ClickHouse其存储和查询效率就会比ElasticSearch高很多,所以在这种情况下,用户的体验就是最重要的。
对于用户而言,每天接触的新产品新功能很多,能够在新产品上无缝嫁接其已具备的成熟体验可能是最重要的。