DeepFlow 零侵扰数据能力构建 AIOps 的基石

本文整理自云杉网络 DeepFlow 解决方案负责人李飞在“智能可观测运维技术 MeetUp”的演讲内容，主题为「DeepFlow 零侵扰数据能力构建 AIOps 的基石」。

​

感谢中兴通讯和龙蜥社区的邀请，今天非常荣幸代表云杉网络和 DeepFlow，向大家分享 DeepFlow 如何使用零侵扰的可观测性数据构建 AIOps 建设的基石，以及使用“大模型 AI 智能体” + “DeepFlow 可观测性数据”逐步探索构建 AIOps 的进展和发现。

01｜回顾历史，AIOps 建设中的数据质量之苦

从我毕业进入运维领域开始直到现在，一线运维工程师仍然处于非常辛苦的工作状态，工作量大、工作职责重、压力大、成绩体现不出来，运维岗位的 IT 工程师基本都处于 IT 圈的最底层，所以运维领域一直都有一个非常朴素的想法，期望用 AI 来解放我们的 Ops 工作，用 AIOps 来替代人工 Ops，但经过这么多年的发展，AIOps 并没有取得明显的落地效果。

​

19 个月前，GPT-3 的出现让我们看到 AIOps 实现的新路径，似乎胜利的曙光就在眼前，但如果我们仔细分析历史，找到 AIOps 发展缓慢的核心原因，就会发现真正实现 AIOps 并没有那么容易。

​

1） AIOps 发展的核心瓶颈点在哪里？

​

首先 AI 的本质是用计算机复制人类的知识和方法，不知疲倦的以更快的速度完成人类的数据处理过程，而不是用计算机去创造一个超越人类智慧的、类似于上帝的一个新角色。

​

而回顾过去会发现，我们的运维工作存在三个特征：

​

• 手工运维——大部分的 IT 运维经常在出问题之后去各个设备上敲一组命令，根据结果做综合判断，可能再换一个地方抓包、读包、做判断，之后登录另一台设备查日志、做判断……操作动作不断的循环下去，直到找到根因，整个过程就像农民伯伯用镰刀割麦子一样存在大量的体力劳动。

• 经验运维/直觉运维/灵感运维——在故障诊断过程中经常需要经验、直觉、灵感去判断诊断方向，对一些重要系统变更/升级时可能还会在操作之前烧个香，祈祷这次变更升级能够成功，夸张一点来说我们的运维工作还处于靠运气的状态。

• 专家依赖——运维工程师经过多年实践经验的积累逐渐成长为专家，但专家积累的经验、直觉和灵感很难被复制和传递，初级工程师无法通过培训和学习快速变为另一名专家。

​

运维中存在大量手工操作、经验、直觉、灵感的核心原因就是——数据，我们的运维工作中普遍存在如下数据的问题：

• 广泛的数据盲区——虽然我们建设了大量的监控工具，但是这些监控工具实质上只覆盖了整个 IT 系统中不到 1% 的范围，剩下的 99% 都是盲区，这些盲区中出现的问题当然无法快速解决。

• 普遍的数据孤岛——留存的运维数据分散在不同的物理设备、不同的系统中，在故障诊断过程中，需要专家在不同设备、不同系统之间不停切换和搬运数据。

• 低质量的数据关联——我们建设了业务监控、应用监控、系统监控、网络监控等多种工具，但不同的工具的数据之间缺乏关联，没有统一的数据标签，所以在故障诊断过程中，需要在 A 系统中分析诊断一轮，确定某一个实例的 ID，用这个实例的 ID 到 B 系统中检索分析一轮，确定某一个 IP，再到 C 系统中检索这个 IP 的数据……诊断过程全靠人工将这些数据衔接起来。

• 高昂的获取成本——当生产系统出现问题需要诊断时，经常会缺少一些关键数据，这时候就需要部署新的工具，或者开发人员写新的观测代码，重新编译，部署新的版本，整个过程费时费力，而且会中断生产。

​

正是由于数据的问题，让我们的故障诊断更多的依靠经验、灵感和直觉，而不是依靠运维数据，因此 AIOps 的发展缓慢，难以落地，道阻且长。而在大模型时代，实现 AIOps 所面临的首要问题仍然是运维数据。

2） DeepFlow 的探索

​

幸运的是 DeepFlow 自 2016 年诞生之后一直聚集于数据，我们用可观测性理论实现了一个非常优质的可观测数据框架体系，其中的核心包括了“eBPF 技术”和“AutoTagging 技术”。

• eBPF 技术

​

首先，eBPF 技术带来了零侵扰（Zero Code）的观测数据能力——DeepFlow 不需要任何代码注入便可以获取应用的观测数据，一方面可以释放应用开发人员插桩的压力，另一方面可以将同样的观测能力覆盖到 API Gateway、DNS、Redis、MQ、DB 等原来无法注入代码的位置。

其次，eBPF 技术带来了全栈（Full Stack）的观测数据能力——传统的观测能力主要集中在应用程序内部，而操作系统、容器系统、物理网络都是运维的盲区，但 DeepFlow 通过 eBPF 技术实现了从上到下，从应用到系统、存储、网络的全栈观测数据获取能力，我们不仅打开了应用的黑盒，更重要的是打开了包括操作系统和网络在内的整个 IT 系统的黑盒。

总结来说，我们通过 eBPF 技术在更广泛位置实现了观测数据获取能力，在对应用零侵扰的条件下，消除原来大量存在的运维观测盲区，无需添加代码、无需重启应用、即插即用的获取关键数据。

• AutoTagging 技术

​

通过 eBPF 采集以及开放的数据接口，DeepFlow 汇聚 metrics、tracing、logging、profiling、events 等各种各样的海量观测数据之后，下一步更重要的工作便是构建数据之间的关联性。

​

DeepFlow 自研了低成本、高性能的标签注入技术，并命名为“AutoTagging”。通过 AutoTagging 标签注入技术，DeepFlow 能够将所有的观测数据注入丰富的文本标签，这些富含文本语义的信息标签包括了资源标签、业务标签以及各种各样的文本信息，比如应用实例的云资源信息、容器资源信息，CI/CD 流水线中标记的开发者、维护者、版本号、commit_id、仓库地址等等。

通过标签信息的注入，在故障诊断过程中便可以用文本字段一次检索出与某笔业务或某个应用相关的所有 metrics、tracing、logging、profiling、events 数据，并呈现在一个工作台上，经过初中级工程师 3-5 步的数据分析得到故障诊断结论。

​

通过 eBPF 技术消除数据盲区，通过 AutoTagging 技术打通数据孤岛，DeepFlow 用户基本抛弃了原来的手工运维、经验运维、灵感运维等工作模式，从根本上实现了数据运维和数字化运维，运维效率得到实质性提升。

在此基础上，DeepFlow 可观测性数据中富含的文本标签也非常适合大模型处理和分析，为我们打通可观测性和大模型之间的连接带来了意想不到的效果。

​

02｜DeepFlow 基于 eBPF 的零侵扰、全栈可观测性

我们可以先看一下在大模型时代到来之前，DeepFlow已经用零侵扰、全栈可观测性实现了哪些数字化运维能力。

​

1）DeepFlow 的系统架构

​

首先，DeepFlow 通过 eBPF 技术实现零侵扰、全栈观测数据获取能力，同时结合 Wasm 技术实现非常灵活、强大的可编程采集能力，可以通过动态编程、动态加载，随时上线新的观测数据采集功能。

​

其次，DeepFlow 可以汇入各样的观测数据（As Sink），包括 Prometheus、OpenTelemetry、Skywalking、Vector等等数据源均可以汇入。

​

然后，DeepFlow 在可观测性数据的基础上实现了三大核心观测能力：（1）自动化微服务全景绘制；（2）无抽样零侵扰分布式追踪；（3）函数级持续剖析。

最后，DeepFlow 可以通过多种接口向外部开放全部的观测数据（As Source）。

​

2）自动化微服务全景绘制

​

传统 APM 对 Java 类应用的观测和服务拓扑构建能力支持的较好，但 DeepFlow 通过 eBPF 技术实现了整个微服务全景的绘制能力，观测范围包括：

​

• Java 类应用；
• Golang、Rust、Python、Node.js 等其他各种语言开发的应用；
• 外部网关、Spring Gateway、DNS、Redis、MQ、DB 等各个公共组件。

​

并且 DeepFlow 不仅能够绘制微服务全景，观测任意微服务的调用性能，还能够观测任意两个微服务之间的调用在 POD 网卡、Node 网卡、主机网卡、物理网络等全栈关键位置的响应性能，这种全栈观测能力，给故障诊断带来一种火箭般的运维能力提升。

比如，现在发现应用 A、B 之间的调用有 100ms 的时延，用 APM 手段我们知道 A 访问 B 出现慢响应，但到底哪里导致慢响应发生？仅从 A、B 程序内部的观测数据是说不清楚的，要回答这个问题经常要花费几个月时间去诊断定位。

​

而通过 DeepFlow 微服务全景图中 A、B 之间的全栈调用性能指标，直接观测到 A 访问 B 的调用从“A 程序” ——> “POD 网卡（A）” ——> “Node 网卡（A）” ——> “Host 网卡（A）” ——> “物理 Switch” ——> “Host 网卡（B）” ——> “Node 网卡（B）” ——> “POD 网卡（B）” ——> “B 程序” 每一个关键位置的响应时延，因此在 1 分钟内便可在应用 A、应用 B、K8s 容器、云、物理网络之间确定慢响应的边界。

3）无抽样零侵扰分布式追踪

​

区别于传统 APM 追踪，DeepFlow 通过 eBPF 技术实现的分布式追踪具有无需插码、高性能等特点，因此支持各类语言程序，支持各个无法插码位置的无抽样追踪，目前可以说是在全球都是独一无二的技术，核心技术原理已经发表在 SIGCOMM 2023 以 DeepFlow 命名的论文中。

4）函数级持续剖析

​

DeepFlow 的函数级持续剖析提供了一种在生产系统中随时可用的应用程序函数性能剖析能力，它已经具备 OnCPU、OffCPU 的剖析能力，还将提供 GPU、Memory 的剖析能力。在剖析深度上，它不仅支持对业务函数的性能剖析，还能够剖析库函数、Runtime 函数、内核函数的运行性能。

5）更多全栈观测能力

​

总结下来，DeepFlow 还具备包括拓扑分析、追踪分析、剖析分析、网络分析、资源事件分析等一系列全栈观测分析能力，对包括业务应用和基础设施在内的整个 IT 系统实现：

​

• 热加载的全链路追踪
• 实时的线上性能剖析
• 会话级、比特级的流量性能分析
• 分钟级的故障定界定位
• 全栈的故障诊断
• 可编程的交易分析
• 可编程的安全分析
• ……

03｜基于零侵扰数据构建可观测性智能体的实战案例

当 DeepFlow 用可观测性数据实现数字化运维，并做到分钟级的运维诊断能力之后，我们将可观测性数据与大模型为代表的 AI 能力做结合，还会发生什么样的爆炸性效果呢？我们开发了一个基于大模型的 AI 智能体——Stella，通过 Stella 我们可以用大模型的能力对 DeepFlow 可观测性数据进行 AI 分析。

由于时间关系，我们举一个函数性能剖析的诊断案例来看 Stella 的 AI 分析效果。

​

为什么用函数性能剖析来举例呢？因为通过函数性能剖析优化应用代码是 IT 开发和运维中一个极有挑战的工作，涉及不同的知识领域，一张性能剖析火焰图包括了业务函数、框架库函数、运行时函数、共享库函数、内核函数，应用开发人员可能对自己的业务函数比较熟悉，但内核函数很可能需要操作系统方面的专家，库函数需要各个框架的专家，没有一个工程师可以对火焰图中的每一个函数都非常了解，对函数性能剖析结果进行人工分析时，开发人员一般是非常懵的一种状态，这个时候大模型的海量知识检索和提炼能力就可以为分析诊断带来巨大的效率提升。

​

在这个案例中，一个微服务程序遇到了非常典型的 CPU 性能的问题——应用程序消耗的 CPU 随着时间的推移越来越高，于是我们使用 DeepFlow 的函数性能剖析做诊断定位并发现了一些异常函数，但我们看不懂这些函数代表什么意思。

​

于是我们使用 Stella 对火焰图进行分析。Stella 调用 GPT 之后，很快给出了多个比较关键且靠谱的诊断结果：“定时器操作占用了大量的 CPU 操作”、“等待和定时器检查上消耗了大量的 CPU”、“业务逻辑存在大量的忙等”、“频繁的定时器操作和 channel 通信可能是导致性能问题的关键所在”，最后还给出了几个潜在的下一步诊断选项供我们选择。

紧接着我们把 commit id 告诉 Stella，让它去代码库里拿到代码，做比对分析，并尽可能找到问题。Stella 自己完成了代码拉取、比对、分析这些动作，最终找到了代码变更中引入的逻辑错误，并且给出了代码修正建议。

从这个案例中，我们可以看出大模型的 AI 智能体能够快速扩展单个工程师的知识储备量，将不同技术栈的知识信息汇集到一起，作为一个又聪明又忠实的牧羊犬、导盲犬明显提升普通工程师的运维诊断能力。

在 Stella 的其他案例中，我们还发现大模型的 AI 智能体可以比人类快上万倍的速度分析富含文本信息的运维数据。

04｜展望未来，让智能体实现 Full Self-Driving

现阶段 DeepFlow 的 Stella 已经可以实现多个子任务的辅助分析，从业务指标监控，到复杂拓扑分析，再到劣化请求的追踪诊断，再到函数性能剖析、TCP 流分析、IO 性能分析、系统性能分析、日志分析等等不同维度数据的分析诊断，再到根因判定、代码回溯、修复建议……

在这些子任务中，Stella 对运维支撑的工作表现都非常好。

​

但我们也在思考，未来 Stella 是不是可以做得更多一些，能否把这些子任务串接起来，在不需要工程师参与的情况下，就可以从业务指标监控开始，发现异常后自动化全流程诊断分析，并给出修复建议，甚至在经过人工的审核后，能够自动化执行修复动作。

由于 DeepFlow 的观测数据内含统一的文本标签，这种子任务之前的切换和流转会比较顺畅，预计很快就能够实现。

​

除此之外，我们发现随着各行业数字化的发展，像智能驾驶、智能工厂等等行业系统对可观测性运维的需求越来越迫切，所以 DeepFlow 也会通过 eBPF 技术将观测能力向更广泛更细分的方向扩展，同时为更多的细分领域带来 AIOps 能力。

​

PPT下载地址：​​https://yunshan-guangzhou.oss-cn-beijing.aliyuncs.com/yunshan-ticket/pdf/6d59d55e9a321be3892014e962ce8242_20240723144140.pdf​​

​

欢迎大家报名参与 7月27日的《零侵扰、云原生的可观测性工程实践》线下活动，与腾讯、中国移动、ByConity、顺丰、店匠、塞讯验证、云原生社区等可观测性领域中的技术专家一起，探讨行业发展趋势、应用场景、落地路径。