本文主要介绍Ceph分布式追踪，主要参考[1]

分布式追踪（distributed tracing）技术

• 分布式追踪首先是一种追踪技术，它通常使用特殊格式的日志，在运行时记录软件在不同逻辑层中的运行时流程和时间戳，用于软件系统的调试、诊断与性能分析。而在分布式系统中，一次完整的追踪往往需要横跨多个组件，这就需要所有组件中产生的追踪数据格式是统一的。不同组件可能有不同的架构甚至使用不同的编程语言，而组件间也会采用迥异的消息格式和协议进行互通。这意味着分布式追踪需要成为目标系统的基础类库，并为不同语言或架构的组件提供一致的接口，同时嵌入到组件间的消息中间件中，为组件间行为的关联提供内置支持。为了最小化日常追踪时的性能开销，还需要实现对追踪的抽样。

• 一个完善的追踪系统还要提供集群追踪数据的收集、解析和展示功能。要完整实现这样的系统难度是相当高的，而往往多数分布式系统在开发、调试、优化和监控中都非常缺乏分布式追踪所提供的全集群视角去定位成百上千模块中的问题。好在Google在它一篇论文[2]中根据其内部实现的分布式追踪工具Dapper的公开了一种通用的追踪模型（spans and trees）。

• 之后基于Dapper的想法，开源社区中也有了多种追踪工具的实现，比如Twitter的Zipkin，Uber的Jaeger，Apache下的SkyWalking等等。它们大都实现了分布式追踪需要的各种功能，提供了多语言支持，并有完善的文档以供使用。

分布式追踪在Ceph中的现状

• 目前Ceph利用LTTng [3] 在各个子模块中的关键位置实现了追踪点（tracepoint），LTTng由于其无锁设计能够允许Ceph在更小的性能开销下产生更高密度的追踪数据。但是也仅仅如此，LTTng自己无法去关联Ceph模块间的事件，它仍然属于传统的非分布式追踪工具。于是Ceph又基于LTTng实现了blkin库，它能够让集群产生与Zipkin格式兼容的追踪数据，实现了最基础的分布式追踪。但是，blkin的功能非常有限，仅仅覆盖了Ceph少数请求的部分执行流程，缺少了对追踪的抽样，其配置、收集、展示与分析功能都是完全割裂的。这不仅导致了普通用户甚至是开发者使用起来都有相当高的难度，加上其功能的完善仍需要庞大的工作量，这直接导致了它缺少社区的维护与更新，变成了目前的近乎不可用的状态。

OpenTracing

• OpenTracing [4] 是一套分布式追踪的多语言API，它和blkin一样也基于Dapper的追踪模型。但是不同的是目前主流的开源分布式追踪系统都对OpenTracing API实现了原生支持，而不是像blkin那样反过来对某一个追踪系统实现了部分的兼容。原生支持是指只要系统基于OpenTracing API实现了追踪功能，它就能够利用现成追踪系统的完整功能，包括了抽样、配置，追踪数据的收集、展示与分析，还能在极小的开发成本下切换到其它支持OpenTracing API的分布式追踪系统。对于Ceph来说，只要集成了OpenTracing，它就只需要关注怎么使用好API，在代码中放置合适的追踪点，而其他的功能、易用性甚至大量的维护工作都不需要Ceph完成；当出现了更好的选择时，或者在一些特殊的场景中（比如单元测试），Ceph也可以非常简单地切换到不同的追踪工具。当前关于OpenTracing在Ceph中的集成工作仍在比较初级的阶段，如果需要直观地了解上述OpenTracing 的优势，可以参考演示代码[5]。

[1] https://pjw.io/articles/2018/05/08/opentracing-explanations/

[2] https://research.google.com/archive/papers/dapper-2010-1.pdf

[3] https://lttng.org/

[4] http://opentracing.io/

[5] https://github.com/cyx1231st/distributed-tracing-example