为什么要引入 DeepFlow全栈链路追踪？

前面我们就说了，现在工作重点是推 Hera，然后实现 DevOps。那现在就说为什么我们要引入 DeepFlow？

在推 Hera 的过程中，我们会发现有几个问题，首先最大的痛点是 Hera 探针接入成本比较高，覆盖的应用不全，如果我们要向全集团全部的业务去推进 Hera 的话，那它必须要形成完整的覆盖度。但我们在推的时候有一些很难推，有些业务可能有需求排期或者需求倒排之类的（编者按：探针的插码可能被业务团队放到业务需求之后），接入成本高。那如果在我们的 Hera 探针接入后，我们是不是就不需要 DeepFlow 的自动化采集？其实并不是，我们在接入 Hera 探针后， DeepFlow 还是可以对我们 Hera 的探针进行功能上的补全的。后面我也会详细说一下，目前主要是这两个痛点。

首先是 Hera，我们采取的是 OTel 探针，OTel 探针做可观测性的话会比较了解，我们是基于社区版本做了一个简单的改造，对小米内部的一些功能做了适配。我们可以看到有两种接入方式，一个是 Golang 的应用，一个是 Java 的应用，其实它们两个接入方式是不一样的。
如果是 Go 应用的话，我们内部的话可能会有一个微服务框架，可以通过中间件的方式，把 OTel SDK 给加进去，这样它会在一些核心的地方，比如说网络请求加入一些自动上报的逻辑。但有的没有用框架，那就得手动地写代码了，你得在网络调用地方手动地去写上报逻辑。
然后下面是 Java 应用， Java 应用比较简单点，它可以通过 Agent 的字节码注入技术，自动地把 OTel 探针注入到 Java 应用中去。然后接入成本就是可能要改启动命令，虽然成本比较低，但也涉及到业务的发版。
这边大致是 Hera 如果不用 DeepFlow，而用探针的接入方式来做接入。Java 的我们加一个命令行加入 Agent，这样启动的时候就可以自动地实现探针的功能了。
然后这是 Go，你可以看到它的整个流程是比较复杂的，首先要代码改造，业务方代码改造后他们一定不会全量上线的，可能要灰度验证一段时间，最后到上线需要至少一周。第二就是改造成本过高，业务方研发会降低优先级，前面也说了，小米内部有一些盈利的业务，他们可能不会优先考虑到接探针，他们先要完成他们的活动任务，这就会降低优先级，我们推得就比较困难。第三就是很多业务研发对指标链路上报的原理不太熟悉，特别 Golang 需要手动去加探针，需要拉群沟通协作，然后可能我们需要安排一个人力，专门协助他们去接入 Hera，对团队的整体的负担比较大。
（右边的扇形图）最后给一个结论，我们现在大概接入 Java 的应用大概有 5000 个，接入 Golang 的应用只有 300 个，这个之间的比例关系就可以看出来，它接入的数量肯定是跟接入成本是相关的。
前面说接入的痛点后，我再说一下，其实我们已经接入了 OTel 探针，实现了全链路追踪的能力，那 Hera 全链路追踪能力的应用还存在什么问题？首先进程内的探针只能获取一头一尾，无法获取 trace 到网络的链路，这边有个例子，请求从 Client 出去，跨专线、跨机房的业务，它会走专线，先到域名解析，然后要进入容器网络，进容器网络、出容器网络，然后可能走专线的话要经过网关，然后到专线，到另一个机房的网关，然后再进七层代理，七层代理前面可能还有个 LB，最后到 Server 的容器网络，最后进入 Server。
整个过程中有很多中间环节，但是目前我们加 OTel 探针的形式，只能获取客户端发送 Request 到 Server 收到 Response 中间的 Span，所以我们看到有个2秒的时延，但是我们并不知道这个2秒到底是因为 Server 的不稳定，还是 Client 不稳定，还是因为中间网络链路的不稳定而导致的，这是我们现在的问题。
这边有个图，可以看到有个2秒钟的一个 Span，但它下面没有细节，你只能告诉用户就这个请求不稳、很慢，但你不能告诉他哪里慢，这个就容易造成两方的拉扯，服务端和服务依赖方（编者按：基础设施）两方拉扯，（最后发现）其实两边都没有问题，而是网络的问题。
网络问题其实在业界中也是会频繁发生的，我们在 Hera 业务使用的时候也发生过。首先是海外专线因为施工被挖断，导致业务出现大量的超时。还有机房的网络割接，小米经常在凌晨的时候会做一些网络割接，这个过程虽然很快，但中间可能会出现一些临时性的网络抖动，可用性就会造成波动，凌晨的时候有很多业务方收到告警了，说服务的稳定性、可用性下降。第三个就是交换机故障，导致后面的服务全部访问超时全挂了。第四个就是域名解析负载高，响应慢导致业务超时，这都是我们遇到过的一些问题，但这些 Hera 并不能回答到底是什么原因引起的。
我们说重点，为什么要选择 DeepFlow。首先 DeepFlow 是真正的零侵扰的自动化采集，用户不需要修改任何代码发布版本，整个接入过程中是完全无感的。
我们之前要推业务方，一个模式就是我们会跟对方拉群沟通，然后跟对方说怎么排期，或者帮助他们去解决问题，甚至拉很多会去沟通接入的收益。但现在不需要了，现在我们如果想去跟他们覆盖 Hera 的能力的话，我会直接地拉他们的产品运维、一线运维或者他们的 leader，我们就告诉他们说要在你们这个试点用 DeepFlow 了，他们如果对性能不满意的话，我们会甩一个压测文档，我告诉他们整个接入过程是无感的，不需要他们投入任何人力，只需要运维看一下有没有问题就行了。这个接入过程非常顺畅，接入也很快，可以一下接入大量的业务。
第二点就是我们当时调研的时候，其实 DeepFlow 是有竞品的，像 Pixie 或者是其他的，我们都当时都调研了一遍，我们为什么选择 DeepFlow 去适配 Hera 作为基础采集功能，是因为 Hera 的 L7 的看板，跟 DeepFlow 提供的官网的看板是一模一样的，没有任何区别，包括我们协议的解析。可以这样说，DeepFlow 向下兼容了 Hera 的看板，里面包括 Dubbo、HTTP、Redis、MySQL 的黄金指标，我们在 DeepFlow 中都可以找到，是和 Hera 完全一样，就不用做任何改造了。
第三点，这个是一个比较偏小米集团的功能诉求，我们对比其他的几个竞品 cBPF 这方面做得不是特别好，我们对比了一下 eBPF 能力，固然很多产品都做得很强，但 cBPF 的能力能做到 eBPF 80% 的能力的产品其实很少。
所以说我们当时选择 cBPF 能力比较强的 DeepFlow，因为适配内核和兼容小米当前的主机环境，这个我们后面也会说的。小米有一些比较偏传统的业务，它的主机内核版本很老，有 3.0 以下版本的内核。
然后是刚刚解释的无法回答用户是否因为网络问题引起的故障的案例，我们现在可以回答了。首先 DeepFlow 是原生支持网络 Span 的，这是 DeepFlow 的核心特性，它可以零侵扰地生成网络 Span，采集的点非常细。我们当时也调研了，从容器网卡出来到交换机，到路由到 NAT，每一层的网络 Span 都可以生成。不过对于小米内部其实我们不需要这么精细，这个功能已经超出了我们预期很多了。其实我们只需要知道客户端网卡到服务端网卡之间的网络 Span，然后这个 Span 我们的业务研发同学看不懂，你只要告诉他是网络问题，然后去找网络组就可以了。所以结论就是，我们只需要一个客户端网卡到服务端网卡中间的一个网络 Span 就可以解答我们用户的问题了。
第二点也是非常重要的，也是当时我们选型的目的，Hera 当前的数据源，也就是我们的 ES，还有和我们的链路追踪的 OTel 的 ES 数据源，和 DeepFlow 的 Clickhouse 里面 Span 是天然打通的。在我们调研之前，社区都已经给出方案了，开发成本是很低的，之前也咨询过 DeepFlow 团队提供了两套方案，第一套方案是直接把 ES 数据导到 Clickhouse 里去，但这个方案对我们的侵扰太大了，本身我们的内部的 ES 也有很多同学在维护，所以我们选取了第二套方案，我们通过 DeepFlow 提供的 API 的能力，把 DeepFlow 的 Span 以 W3C 那种标准的协议格式导到我们 Hera 的当前链路的数据中去，然后我们通过 Trace ID 以及 Parent Span ID 关联。由于 OTel 是一个标准的协议，所以是天然打通的，开发成本很低，我们当时试了一下，这个功能还没有正式地去推，但是我们已经在调研中了，目前我们调研发现整个接入过程应该是很快的，开发成本很低。
还要感谢的就是 DeepFlow 社区支持力度很大，团队也非常专业。我们提的一些 FR 都是以双周为一个节点进行推进的，这是我们取得的一些成就。后面也会说一下，首先是加强 cBPF 能力，满足业务需求的前提下，我们的理论覆盖率，意思就是到底有多少个主机能够覆盖到我们 Hera 的特性，通过 DeepFlow 的覆盖能力实现 Hera 的功能，最开始 30% 是因为我们只有 30% 支持 eBPF，然后我们有 cBPF 能力加强后，60% 的机器就可以实现 Hera 的无侵扰的部署能力了。但它仍然不是100%，后面还有一些更老的内核的主机，比如说像 3.x 老内核主机，可能在 cBPF 的能力上面也有缺陷。我后来又经过跟社区一起努力，从 60% 又提到 80%，这个时候其实离全量覆盖很近了。
最后还有 20% 是最老的 2.6 版本内核。其实我们也适配了，但它是存在一些技术问题的，比如像 Cgroups 的隔离性，它做得不是特别好。后来我们出于安全的考虑就没有去推这20%，当然社区也在出方案，我们最后还是会全量覆盖。最后优化应用的拓扑图的展示，为用户提供更清晰的拓扑信息。