流媒体生态系统的分布式请求追踪

来源：DEMUXED 2021 演讲者：Josh Evans 内容整理：胡经川 本次演讲者是来自 SVA 的 QoE 工作组的联合主席 Josh Evans，他向我们介绍了如何将分布式请求跟踪集成到流媒体视频工作流程中，从而可以在整个流媒体视频分发工作流程中协作整合日志、指标和请求跟踪，极大地提高其整体可观察性。通过利用分布式请求跟踪和它所带来的洞察力来显著改善观众的 QoE。

目录

• 项目概览
• 请求追踪基础
• 通用媒体客户数据（CMCD）
• 仪器与实现
• 展望

在流媒体视频世界中，慢启动、低码率、高失速率(stall rate)和播放失败可谓是四大“世界末日”，无论这四个中的哪一个发生都会导致糟糕的用户体验。当问题发生的时候，找到根本原因是十分重要的，可能是播放器的问题，也可能是缓冲算法或比特率选择的问题，或者是内容编码或打包的问题。为此，流媒体视频联盟发布了端到端工作流监控的最佳实践，这份文档中提出跨流媒体视频工作流的级联效应可以通过多点监控来观察记录和相互分离，这意味着从各个点（CDN、播放器、源或编码器）收集数据，然后将这些数据整合在一起。然而这些数据往往是孤立的，即使您可以尝试以某种方式连接它，那些从中派生的孤立的日志和指标通常也不足以驱动 QOE 或以真正有效的方式解决问题。

图 1:端到端工作流监控最佳实践

下面的维恩图描述了可以收集的元素之间的关系，有高粒度的日志记录事件，它们可以汇总并转化为指标。此外，请求范围的追踪也十分重要，没有它就无法了解一个事件的全貌，所以它也是任务具有可观察性的三大前提之一。所以我们试图通过“流媒体生态系统的分布式请求追踪”这个项目回答这个基本问题，这个项目介绍了如何利用多服务日志、指标和追踪来完成流媒体视频 QOE 信号的根本原因分析。

图 2：可观察性的三大支柱

项目概览

在项目的第一阶段，我们的目标主要有以下几点：

• 从播放器和 CDN 日志中提取追踪数据，然后设计一套通用的方法来完成这项工作；
• 识别端到端工作流中的基线请求和响应模式来理解多个播放器和 CDN 中的常见行为；
• 人为模拟降级和故障来识别相应的请求追踪和聚合模式是什么样的；
• 建立一个模型来关联高级 QOE 信号来识别跟踪模式，然后指向根本原因；
• 开发指标和可视化来说明整个过程。

在架构方面，有一个两层 CDN 和边缘的配置，以及一个中间层来保护 S3。我们在应用程序中设计了一个视频数据平台（VDP），一个播放器收集器将信息拉入 VDP 平台，还有一个日志收集器接收日志，数据标准化后被发送到分析平台。

图 3:架构

在服务和技术方面，SVA 内部有很多参与，THEOplayer 是我们将要集成到这个项目中的播放器之一，还有 Dash.js，这两款播放都有 CMCD 实现。对于 CDN，我们正在利用 Fastly、Lumen 和 AWS CloudFront，以及之前提到的 S3。

在视频数据平台和分析方面，在 VDP 方面拥有 Datazoom，然后我们正在利用 Splunk 和 Zipkin。

请求追踪基础

分布式请求跟踪的基本概念之一是时间跨度的概念，从本质上讲，时间跨度是在服务内花费的时间，或者请求脱离主机到远程服务时服务之间花费的时间。另外就是要了解服务的层次结构。

在故障排除支持和实时支持方面，追踪可以实现分布式事务监控。你可以监控到故障发生在哪里，并快速排除根本原因。当然，你也可以围绕延迟中的依赖关系和性能进行离线分析。如果你正确打包数据，你就可以将其注入 Zipkin 之类的工具中实现可视化。

图 4:Zipkin可视化界面

通用媒体客户数据（CMCD）

通用媒体客户数据是一个关键组件，每个媒体播放器都可以通过它与每个媒体对象请求进行数据通信，并让每个 CDN 一致地接收和处理它。

播放器发出常规内容请求，它传递一个 SID 参数，在这种情况下是一个查询字符串，它将被传送到 CDN，并在其中记录。然后，使用相同会话 ID 记录其自己的遥测数据的播放器可以与也具有该会话 ID 参数的缓存日志连接，这样就可以将信息收集并组合，然后就可以开始进行将数据连接在一起的有趣查询。

图 5:播放器内容请求流程

仪器与实现

正如前面提到的，使用的播放器工具是 Dash.js 和 THEOplayer。目标是在每个内容请求的查询字符串中生成和设置标识符，这意味着设置 SID和 RID，CMCD 中没有 RID 参数，所以这是一个自定义键，使用反向 DNS 表示法将其命名为 org.svalabs.rid。在 THEOplayer 中，这些是自动设置的，他们将其内置到播放器本身中。

对于捕获，我们需要至少捕获开始时间、往返时间和 HTTP 响应代码。在 THEOplayer 中，有一些不错的拦截器方法可以实现，然后注册回调以便能够访问请求和响应。然后这些数据都需要打包、标准化并交付到 VDP 中，并最终交付到分析平台继续进行日志记录。

大多数 CDN 默认记录查询字符串，CDN 可以将参数解析为 JSON 或其他格式，但这也可以由下游服务完成。如果要使用标头，则需要做一些额外的工作，CDN 需要解析出标头，然后记录它们，此外，来自正在发送标头的浏览器的请求需要获得发送这些标头的权限，因此 CDN 必须进行一些配置以允许这些标头。下图是在进行跟踪时要从 CDN 收集的上下文工作列表。

图 6:CDN 追踪的上下文工作列表

对于 VDP，它在播放器端有收集器，它有从 CDN 接收日志流的日志收集器，然后它以标准化格式将所有数据打包并发送到分析平台。

图 7：VDP 工作流

展望

随着项目的发展，会接触到更复杂类型的事物，加密内容将被随机请求，甚至可能查看服务器端广告注入。因此需要大规模创建数据，因此，我们希望能够进行一些并发会话。此外，需要进行更多的故障模拟和故障分析。而且要扩大 CDN 的数量，我们可以在其中消费数据并将其转换为跟踪数据。

实现一些复杂的场景也是需要的，比如请求折叠即当许多请求同时出现在同一条内容上时、预取请求以及超越边缘和中间层的多层 CDN 配置，甚至是 CDN 堆叠，其中一个 CDN 可能充当另一个 CDN 的源。

从长远来看，还会将 CMCD 扩展为 CMSV（公共媒体服务器数据），CMSV 的目的是定义一个标准，每个媒体服务器可以通过该标准与每个媒体对象响应进行数据通信，并让每个播放器和中间代理服务器一致地接收和处理以最终提高终端的体验质量。

附上演讲视频：

http://mpvideo.qpic.cn/0bc3iuaaaaaadeahpa3cjrrfarodabcqaaaa.f10002.mp4?dis_k=ff8f37faa4d417c689cd0b6357835e36&dis_t=1653459351&vid=wxv_2366056904214544385&format_id=10002&support_redirect=0&mmversion=false