一篇14年的关于分布式追踪的前瞻式文章，其风格很像综述。
Background
Use cases
- Anomaly detection：有一些与众不同的、少量的workflow。
- Diagnosing steady-state problems：存在于many workflows的问题
- Distributed profiling：发现slow components or functions
- Resource attribution：旨在回答"谁应该为我的分布式系统组件堆栈深处执行的这项工作负责"的问题
- Workload modeling：使用端到端的跟踪来创建工作负载摘要，然后可以用于以后的分析或推断
approaches to end-to-end tracing
大多数端到端追踪基础设施使用三种方法中的一种来识别因果关系的活动：元数据传播、模式或黑箱推理。
- 元数据的传播。许多实现被设计为与白盒系统一起使用，对于白盒系统，可以修改组件以传播元数据（例如，一个ID）。
- schema-based。少数实施方案，如ETE和Magpie，不传播元数据，而是要求开发者编写temporal join-schemas，在自定义编写的日志信息中暴露的变量之间建立因果关系。
- 黑盒推理。他们通过从预先存在的日志中关联变量或时间来推断因果关系，或者进行简化的假设[44]。
Anatomy of end-to-end tracing
需要回答两个问题
- 哪些因果关系应该被保存下来
- 应该用什么模型来表达关系
Which causal relationships should be preserved?
不同的片断对不同的用例是有用的，但保留所有的片断会产生太多的开销。 因此，跟踪基础设施的工作是只保留对其输出的使用方式最有用的片断。本节的其余部分描述了已被证明对各种使用情况有用的片断。
Intra-request slices
- The submitter-preserving slice：保存这个slice意味着单个端到端追踪将显示一个请求的原始提交者和通过系统的每个组件处理它所做的工作之间的因果关系。
- The trigger-preserving slice：相比之下，触发因果关系保证了一个请求的跟踪将显示所有在客户端响应发送前必须执行的工作
Inter-request slices
- contention-preserving slice：顾名思义
- read-after-write-preserving slice：就是一边read、一边write，这个因果关系保留下来
How should causal relationships be tracked?
所有的端到端追踪基础设施必须采用一种机制来追踪与他们的预期用例最相关的请求内和请求间的因果关系片断。
Tradeoffs between metadata types
在决定使用哪种类型的元数据时，有三个主要问题需要考虑。 首先是大小。较大的元数据会导致较大的消息（例如RPC），或者会限制有效载荷的大小。 第二是对丢失或不可用的数据的脆性（或resilience）。 第三是该方法是否能够在不建立跟踪的情况下立即提供完整的跟踪（或分析所需的其他数据）。
主要有三种
- Static, fixed-width metadata：简单的ID
- Dynamic, fixed-width metadata：通过这种方法，除了工作流ID之外，简单的逻辑时钟（即单个64位值）可以嵌入到元数据中
- Dynamic, variable-width metadata：通过这种方法，分配给因果关系活动的元数据除了价值之外还可以改变大小。这样做将允许元数据包括区间树时钟而不是简单的逻辑时钟
How to preserve forks and joins
需要额外处理一对多和多对一的情况。
How should sampling be used to reduce overhead?
在决定对哪些跟踪点进行抽样时，有三种基本不同的选择：基于头部的相干抽样，基于尾部的相干抽样，或者单元抽样。
基于头部的连贯性采样： 通过这种方法，在整个工作流开始时（例如，当请求进入系统时）对其进行随机抽样决定，元数据与工作流一起传播，表明是否要收集其跟踪点。
基于尾部的连贯性采样： 这种方法与前一种方法类似，只是工作流的采样决定是在工作流结束时做出的，而不是在工作流开始时。 推迟取样决定可以实现更智能的取样--例如，追踪基础设施可以检查工作流的属性（例如，响应时间），并选择只收集异常的工作流。
单一采样：通过这种方法，开发人员直接设置跟踪点的采样百分比，采样决定是在单个跟踪点的水平上做出的。
How should traces be visualized?
- Gantt charts (also called swimlanes)
- Flow graphs (also called request-flow graphs)
- Call graphs and focus graphs
- Calling Context Trees (CCTs)
Putting it all together
有个不错的表