腾讯蓝鲸 x DeepFlow 基于 eBPF 的可观测性平台实践一

基于 OTel 的实践与挑战

OTel 可能已为熟悉可观测性平台的朋友所熟知。在 OTel 诞生之前，已有诸多分布式链路追踪相关的产品，如 Jaeger、Zipkin 等，蓝鲸观测平台也有自己的实现方案。然而，由于各种实现方案层出不穷，这对使用者来说意味着每换一个平台就需要重新检测代码、配置新的 SDK，甚至还需要关心新平台的数据协议，导致接入成本很高。
OTel 的出现便是为解决这个问题，它统一了 Trace、Metric、Log 这三种数据协议，用户只需要加载一套 SDK，更改上报地址即可体验不同平台的功能。同时，数据标准化后不仅降低了用户维护 SDK 的负担，也提高了数据的可移植性。
2021 年，蓝鲸观测平台也拥抱开源，我们将自己的实现方案统一转换成了 OTel 协议格式。下面，我将展示基于 OTel 的一些特性，帮助用户快速定位问题。
首先，当用户有了一个具体问题后，这个时候往往用户已经有了一个明确的 traceid，或者说他已经有了明确的一个时间段，需要去定位具体是哪个服务出错了，是哪一个接口出错了，具体的这个出错内容是什么？那么可以带着 traceid 去到我们平台的检索页面，把这个 traceid 带入进去，直接快速的找到本次 trace 请求所经过的所有链路服务。
如果更关心于这种服务与服务之间，或者说接口与接口之间的调用关系的话，那么可以切换到这个拓扑的视角；
如果更关心于这种时间上的调用关系，想知道这些接口有没有按时间顺序去调的话，那么也可以切换到这种时序图的这种视角去从时序上看这个调用的关系；
如果更喜欢用以往的这种火焰图的形式，更关心耗时分布，也可以切换到火焰图的视角，然后通过这种火焰图的形式去找到这个耗时最大的一个 span 是什么。
其次，如果用户没有具体的问题，我们也会帮助他们挖掘更深层次的未知问题。
为此我们提供了业务的全景视角，用户通过这个拓扑图，然后往下钻，通过观察这个拓扑图上的具体一个服务，然后下钻到里面可以看到每一个服务它的一些黄金指标，像请求数、错误数或者说请求耗时以及底下的这些像这种 Top 视角，包括耗时 Top 或者错误 Top。
也可以切换接口的统计视角，这种视角去看到每一个接口的这种整体的一个情况。或者以错误统计的这种视角去查看错误次数最高是什么？然后我们也可以在右边的这个视图里面，直接展开看到它的这个错误的一些更详细的错误信息，堆栈信息。
此外，我们还提供了其他视角，如主机视角、日志视角和实例视角，用户可以在这些关联视角中观测到更多的对象，以帮助他们更快地发现架构中更深层次的问题。
在前两种情况中，用户会主动查看平台，通过平台发现问题。然而，即使用户没有查看平台，我们也会从 Trace 数据中提取出一些基础的黄金指标，并提供给用户配置告警，同时也提供了用户自定义的维度，以满足用户个性化的需求。将用户关心的关键指标通过告警的形式及时送达给用户。
上图就是数据的联动。这里介绍关键的三个数据 Metric、Log、Trace 之间的关联关系，从任意一个数据视角都可以关联跳转到其他两个数据的视角，帮忙用户快速的发现定位问题。
Trace 关联 Log 是以 service 来关联；
Trace 关联 Metric 是以主机或目标维度来关联；
Log 关联 Trace 是以 traceid 来关联；
Log 和 Metric 之间是以主机目标维度互相关联；
Metric 与 Trace 是以指标中通过 exemplars 机制打点的 traceid 来关联。
以上就是蓝鲸观测平台上基于 OTel 所进行的实践。
诚然我们做了这么多，但是在推广的过程中，还是会发现部分用户无法买账，不接受。主要的挑战有以下两个方面。
第一，接入成本高。
虽然 OTel 的出现已经将用户的接入成本降低了很多，SDK 中也提供了很多自动插码的逻辑，对于一些常见的库都有自动 hook 的逻辑，但也仅限于 Python 或者 Java 这种可注入的语言。但对于像 C、C++ 这种语言，接入成本就比较高了，几乎所有请求都需要自己手动插码。而在腾讯，游戏基本上都是基于 C、C++ 开发的。
另外对于存量的游戏业务，或者代理的游戏业务，接受度就更低了，基本上不可能要求游戏研发方给运营加上这个插码逻辑。
第二，数据的完整性。
组件盲区： 比如 Kafka 组件、存储组件，由于没办法上报 trace，那么这部分就无法观测
系统层网络层盲区： 另外对于系统和网络层的调用，也存在缺失，现有的 OTel 更倾向于开发者视角，对于运维视角不那么友好，我们需要打通开发者和运维视角，做到统一查看
K8s 引入的复杂性： 对于云原生，K8s 给开发者带来了便利的同时，也带来了不少挑战。开发者更专注业务逻辑的开发，而更少关注系统，部署等。当问题出现的时候，基于 OTel 的方式，很难完整的得到这部分的全景拓扑视图。

]]>