一、概述

直播业务具有实时性强，复杂度高，排查链路长，影响面大等特征，线上问题如果不能立刻排查处理，分分秒秒都在影响用户的观看体验、主播的收入。

但各端的问题可能都只是表象，例如，一个看似简单的画面卡顿问题，可能涉及到编码器配置、网络带宽分配、服务器负载等多个方面，各个团队经常在等待合作方的反馈，一整套流程下来，一个线上问题的定位可能要消耗掉数小时的人力。

我们迫切的需要一套高效的跨端实时排障系统！

为此我们采取了以下措施：

1. **关键业务监控：**联合各协作方，对关键业务的接口、广播和核心处理逻辑实施了实时埋点监控，并附加了相关场景信息，确保了问题定位的准确性和全面性。
2. **统一追踪系统：**为了实现单个业务链路所有埋点的跨端联络，我们设计了统一的trace_id字段，并在数据层进行串联，通过看板直观展示，极大地提升了问题追踪和定位的效率。

这些措施带来了显著的成效：

• **跨部门协作效率提升：**通过实时数据共享和统一追踪系统，直播移动端、PC端、Web端、服务端以及流媒体等各个团队协作效率大幅提升。在开播、视频连线等9个核心业务的故障排查中，排障率达到了91%，异常定位的平均时间从2小时缩短至仅需5分钟。兄弟部门也采纳了我们的方案，有效减轻了工作压力。
• **系统稳定性增强：**这些措施还帮助我们优化了开播异常断流、连麦发布订阅失败等多项关键业务问题，确保了系统的高效运行，减少了因技术问题导致的用户流失。
• **用户体验改善：**我们的快速响应和问题解决能力极大地提升了主播和用户的直播体验。用户和主播的正面反馈络绎不绝，间接提高了主播收入稳定性，增强了平台的吸引力。

二、技术方案详解

1. 方案设计

如上图所示，整体全链路排障建设可以分为数据采集、数据处理&存储、可视化工具建设3大块。

在开始介绍实现方案之前，需要简单介绍一下OpenTracing，它是业内实现分布式链路追踪系统通常会采用的方案，我们在后续的埋点和上报组件设计也对它进行了一些参考。OpenTracing定义了追踪数据所需要的操作和数据结构，帮助开发人员实现分布式追踪的能力。OpenTracing里面有两个比较核心的概念，简单说明一下：

Trace：Trace代表一条追踪路径，它由多个Span组成，存在一个唯一ID

Span：Span代表追踪路径中的一个时间跨度，包括操作名称、开始时间、结束时间等信息，由SpanID作为标识。由多个 Span 可以形成一条追踪路径。Span还定义了父子、跟随两种关系。在Span上下文中，记录和维护了Trace的ID和当前Span的ID。

下图是OpenTracing的模型图，它描述了由多个Span组成一条追踪路径：