构建Netflix的分布式跟踪基础设施

“@Netflixhelp为什么不在我的手机上玩虎王？”--一名Netflix会员通过Twitter表示。

这是我们的随叫随到工程师需要回答的一个问题，以帮助解决成员问题-这在对分布式系统进行故障排除时是困难的。调查视频流故障包括检查成员帐户的所有方面。在我们之前的博客文章中，我们介绍了Edgar，这是我们用于流媒体会话的故障排除工具。现在，让我们看看我们是如何设计支持Edgar的跟踪基础设施的。

在Edgar之前，我们的工程师必须筛选从各种Netflix微服务中提取的堆积如山的元数据和日志，以便了解我们的任何成员都经历过的特定流故障。重建流会话是一个乏味且耗时的过程，涉及跟踪Netflix应用程序、我们的内容交付网络(CDN)和后端微服务之间的所有交互(请求)。该过程从手动拉取属于会话一部分的成员帐户信息开始。下一步是把所有的拼图拼凑在一起，希望得到的图片能帮助解决会员问题。我们需要通过分布式请求跟踪来提高工程生产力。

如果我们有每个流会话的ID，那么分布式跟踪可以通过提供所有服务调用的服务拓扑、重试和错误标签以及延迟测量，轻松地重建会话故障。我们还可以通过将相关跟踪与帐户元数据和服务日志相结合来获取有关流会话的上下文信息。这种洞察力引导我们构建了Edgar：一种分布式跟踪基础设施和用户体验。

当我们四年前开始构建Edgar时，很少有开源分布式跟踪系统能满足我们的需求。我们的策略是使用特定于Netflix的库来收集基于Java的流媒体服务中的跟踪，直到开源跟踪器库成熟为止。到了2017年，像Open-Tracking和Open-Zipkin这样的开源项目已经足够成熟，可以在Netflix的多语言运行时环境中使用了。我们选择Open-Zipkin是因为它与我们基于Spring Boot的Java运行时环境有更好的集成。我们使用螳螂来处理收集到的踪迹流，并使用Cassandra来存储踪迹。我们的分布式跟踪基础设施分为三个部分：跟踪器库检测、流处理和存储。从各种微服务收集的踪迹以流处理方式被摄取到数据存储中。以下各节描述了我们构建这些组件的过程。

这是我们的工程团队在集成跟踪库时问我们的第一个问题。这是一个重要的问题，因为跟踪器库拦截通过关键任务流服务的所有请求。在我们的多语言运行时环境中安全地集成和部署跟踪库是我们的首要任务。我们通过开发对操作负担的同理心，并专注于在运行时环境中提供高效的跟踪库集成，赢得了我们工程师的信任。

分布式跟踪依赖于将本地进程间调用(IPC)的上下文和任意请求的客户端调用传播到远程微服务。传递请求上下文可以在运行时捕获微服务之间的因果关系。我们采用了Open-Zipkin的B3HTTP报头的上下文传播机制。我们确保上下文传播头部在各种“铺路”的Java和Node运行时环境中的微服务之间正确传递，这些环境既包括具有遗留代码库的较旧环境，也包括Spring Boot等较新环境。我们执行我们文化的自由和责任原则，为Python、NodeJS和Ruby on rails等环境支持跟踪库，这些环境不属于“铺好的路”开发人员体验的一部分。我们松散耦合但高度一致的工程团队可以自由地为他们的运行时环境选择合适的跟踪器库，并且有责任确保正确的上下文传播和网络调用拦截器的集成。

我们的运行时环境集成注入了服务名称、弹性伸缩组(ASG)和容器实例标识符等基础设施标签。Edgar使用此基础设施标记模式来查询跟踪并将其与日志数据连接起来，以排除流会话故障。此外，由于一致的标记，在Edgar中提供到不同监控和部署系统的深层链接变得很容易。运行时环境集成到位后，我们必须设置适当的跟踪数据采样策略，以构建故障排除体验。

这是我们在构建基础设施时考虑的最重要的问题，因为数据采样策略规定了记录、传输和存储的跟踪数量。宽松的跟踪数据采样策略会在每个服务容器中生成大量跟踪，并可能导致流服务的性能下降，因为跟踪库会消耗更多的CPU、内存和网络资源。宽松采样策略的另一个含义是需要可扩展的流处理和存储基础设施群来处理增加的数据量。

我们知道，大量采样的跟踪数据集不能可靠地进行故障排除，因为不能保证您想要的请求在收集的样本中。我们需要一种深思熟虑的方法来收集流式微服务中的所有痕迹，同时保持运行基础设施的较低操作复杂性。

大多数分布式跟踪系统在微服务调用图中的请求摄取点强制实施采样策略。我们采用了基于头部的混合采样方法，允许记录特定且可配置的一组请求的100%跟踪，同时继续根据摄取点设置的策略对流量进行随机采样。这种灵活性允许跟踪库在我们的任务关键流微服务中记录100%的跟踪，同时从离线批处理等辅助系统收集最少的跟踪。我们的工程团队在考虑到由于跟踪而增加的资源利用率后，针对性能调整了他们的服务。下一个挑战是通过可伸缩的数据处理平台流式传输大量跟踪。

螳螂是我们在Netflix处理运营数据的首选平台。我们选择螳螂作为我们的主干来传输和处理大量跟踪数据，因为我们需要一个反压力感知、可扩展的流处理系统。我们的跟踪数据收集代理通过Mantis发布库将跟踪传输到Mantis作业集群。我们在一段时间内缓冲跨度，以便收集第一个作业中跟踪的所有跨度。第二个作业分流第一个作业的数据馈送，对数据进行尾部采样，并将跟踪写入存储系统。这种链式螳螂作业的设置允许我们独立地扩展每个数据处理组件。使用Mantis的另一个优势是能够使用Mantis查询语言(MQL)在RAVEN中执行实时即席数据探索。但是，如果您不能以经济高效的方式存储数据，那么拥有可伸缩的流处理平台就没有多大帮助。

我们一开始使用Elasticsearch作为我们的数据存储，因为它具有灵活的数据模型和查询功能。随着我们使用更多的流媒体服务，跟踪数据量开始呈指数级增长。由于高数据写入速率而增加的扩展ElasticSearch群集的运营负担对我们来说是痛苦的。数据读取查询需要越来越长的时间才能完成，因为ElasticSearch集群使用繁重的计算资源在摄取的跟踪上创建索引。高数据摄取率最终降低了读取和写入操作。我们通过迁移到Cassandra作为我们的数据存储来处理高数据摄取率，从而解决了这个问题。在Cassandra中使用简单的查找索引使我们能够在执行大量写入的同时保持可接受的读取延迟。

从理论上讲，横向扩展将允许我们处理更高的写入速率，并在Cassandra集群中保留更大量的数据。这意味着存储跟踪的成本与存储的数据量呈线性增长。我们需要确保存储成本增长与存储的数据量呈次线性关系。为了实现这一目标，我们概述了以下存储优化战略：

只要现有节点的EC2SSD实例存储达到最大存储容量，我们就会添加新的Cassandra节点。使用更便宜的EBS弹性卷而不是SSD实例存储是一个有吸引力的选择，因为AWS允许动态增加EBS卷大小，而无需重新配置EC2节点。这允许我们在不向现有集群添加新的Cassandra节点的情况下增加总存储容量。2019年，我们云数据库工程(CDE)团队中令人惊叹的同事针对我们的使用案例对EBS性能进行了基准测试，并迁移了现有群集以使用EBS弹性卷。通过优化时间窗口压缩策略(TWCS)参数，他们减少了Cassandra SSTable文件的磁盘写入和合并操作，从而降低了EBS I/O速率。此优化帮助我们减少了群集节点之间的数据复制网络流量，因为可SSTable文件的创建频率低于我们之前的配置。此外，通过对Cassandra数据文件启用Zstd块压缩，我们的跟踪数据文件的大小减少了一半。有了这些经过优化的Cassandra群集后，我们现在的运营成本降低了71%

虽然我们已经取得了实质性的进展，但我们现在正处于建立我们的跟踪数据存储系统的另一个转折点。在Edgar上加入新的用户体验可能需要我们存储10倍于当前数据量的数据量。因此，我们目前正在试验用于新数据网关的分层存储方法。该数据网关提供了一个查询接口，该接口抽象了从分层数据存储读取和写入数据的复杂性。此外，数据网关将接收的数据路由到Cassandra群集，并将压缩的数据文件从Cassandra群集传输到S3。我们计划将最后几个小时的数据保留在Cassandra集群中，其余的保留在S3存储桶中，以便长期保留跟踪。

跟踪数据是Telltale在监控Netflix宏观级别应用程序运行状况时使用的关键信号。Telltale使用踪迹中的因果信息来推断微服务拓扑，并将踪迹与Atlas中的时间序列数据相关联。这种方法为应用程序健康状况描绘了一幅更丰富的可观察性画像。

当我们的工程师通过故障注入测试(FIT)平台对他们的微服务进行压力测试时，我们的混沌工程团队使用跟踪来验证故障被正确注入。

需求工程团队利用跟踪来提高区域疏散期间预缩放的正确性。跟踪提供与微服务交互的设备类型的可见性，以便在疏散AWS区域时更好地说明这些服务的需求变化。

数据科学和产品团队通过分析以相关A/B测试名称作为标签的跟踪，将在微服务上运行A/B测试的成本考虑在内。

随着Netflix的发展，我们软件系统的范围和复杂性不断增加。我们将重点做好以下几个方面的推广工作：

为跨所有运行时环境收集跟踪提供出色的开发人员体验。有了一种尝试分布式跟踪的简单方法，我们希望更多的工程师用跟踪检测他们的服务，并通过标记相关的元数据为每个请求提供额外的上下文。

增强我们查询跟踪数据的分析能力，使Netflix的高级用户能够针对狭隘的使用案例构建自己的仪表板和系统。

构建将指标、日志记录和跟踪系统中的数据关联起来的抽象，以便为故障排除提供额外的上下文信息。

随着我们在构建分布式跟踪基础设施方面取得进展，我们的工程师继续依赖Edgar来解决流问题，比如“为什么我的手机上不播放Tiger King？”我们的分布式跟踪基础设施有助于确保Netflix会员继续欣赏像虎王这样的必看节目！

我们正在寻找令人惊叹的同事加入我们构建分布式跟踪基础设施的旅程。如果您对可观测性感兴趣，请与我们联系。