构建 Netflix 分布式追踪（tracing）体系( 二 ) “为什么我的手机不能播放T

宽松的采样策略的另一个影响是，需要可扩展的流处理和存储基础设施来处理增加的数据量。
大量取样的跟踪数据集对于故障诊断来说并不可靠，因为无法保证你想要的请求就在收集的样本中。我们需要一种周到的方法来收集微服务中的所有跟踪信息，同时保持基础设施运行的低操作复杂性。
大多数分布式跟踪系统在微服务调用图的请求摄取点强制执行采样策略。我们采取了一种基于头部的混合采样方法 (1) ，允许为特定的、可配置的请求集记录 100% 的跟踪，同时继续根据摄取点的策略集随机采样流量。
这种灵活性使得 tracer 库能够在关键任务流微服务中记录 100% 的 trace 信息，同时在离线批处理数据等辅助系统中尽可能少的收集信息。我们的工程团队在考虑到由于跟踪而增加的资源使用率后，对其服务进行了性能调优。
(1) -contrib/zipkin-secondary-sampling/blob/master/docs/design.md
下一个挑战是通过一个可扩展的数据处理平台来流式处理大量的跟踪数据。
文章插图
Mantis 是我们处理 Netflix 运营数据的首选平台。我们选择 Mantis 作为传输和处理大量 trace 数据的主干，因为我们需要一个背压感知、可扩展的流处理系统。跟踪数据收集代理通过 Mantis Publish 库 (1) 将跟踪数据传输到 Mantis 作业集群。
(1)
我们对一个时间段的跨度进行缓冲，以便在第一个作业中收集一个跟踪的所有跨度。第二个作业从第一个作业中获取数据源，对数据进行尾部采样，并将 trace 写入存储系统。这种链式 Mantis 作业 (1) 的设置，使我们能够独立地扩展每个数据处理组件。
使用 Mantis 的另一个优势是能够使用 Mantis 查询语言 (MQL) (2) 在 Raven 中执行实时的临时数据探索。
(1) #job-chaining
(2)
然而，如果你没有低成本的数据存储手段，拥有一个可扩展的流处理平台并没有什么帮助。
存储：尽量节约
由于 ElasticSearch 具备灵活的数据模型和查询能力，我们一开始就使用 Elasticsearch 作为数据存储。随着入驻更多的流媒体服务， trace 数据量开始成倍增长。由于高数据写入率导致 ElasticSearch 集群扩展的操作负担增加，这让我们感到很痛苦。数据读取查询需要越来越长的时间来完成，因为 ElasticSearch 集群使用了大量的计算资源来为新增的 trace 创建索引。
高数据摄取率最终降低了读写操作。我们通过迁移到 Cassandra 作为数据存储来解决这个问题，以处理高数据写入量。在 Cassandra 中使用简单的查找索引，使我们有能力在进行大量写入时保持可接受的读取延迟。
理论上，横向扩展可以让我们处理更高的写入率，并在 Cassandra 集群中保留更大量的数据。这意味着存储 trace 的成本与存储的数据量呈线性增长。我们需要确保存储成本的增长与存储的数据量呈亚线性关系。为了追求这个目标，我们概述了以下存储优化策略。

在 EC2 中使用更便宜的 Elastic Block Store(EBS) 卷而不是 SSD 实例存储。
采用更好的压缩技术来减少 trace 数据大小。
通过使用一些简单的基于规则的过滤器，只存储相关和有用的 trace 数据。

每当现有节点的 EC2 SSD 实例存储达到最大存储容量时，我们就会增加新的 Cassandra 节点。使用更便宜的 EBS 弹性卷，而不是 SSD 实例存储，是一个更合适的选择，因为 AWS 允许动态增加 EBS 卷的大小，而无需重新创建 EC2 节点。这使我们能够在不向现有集群添加新的 Cassandra 节点的情况下增加总存储容量。
2019 年，我们云数据库工程（CDE）团队的厉害的同事为我们的用例进行了 EBS 性能基准测试，并将现有集群迁移到使用 EBS 弹性卷。通过优化时间窗口压缩策略（TWCS）参数，他们减少了 Cassandra SSTable 文件的磁盘写入和合并操作，从而降低了 EBS 的 I/O 速率。
这种优化帮助我们减少了集群节点之间的数据复制网络流量，因为 SSTable 文件的创建频率低于之前的配置。此外，通过在 Cassandra 数据文件上启用 Zstd 块压缩，跟踪数据文件的大小减少了一半。有了这些优化后的 Cassandra 集群，现在运营集群的成本降低了 71% ，而且可以比之前的配置多存储 35 倍的数据。
我们观察到， Edgar 用户使用了不到 1% 的收集跟踪数据。这让我们相信，如果放弃那些用户不会关心的跟踪数据，可以减少写入压力，并在存储系统中保存更多的数据。