eBPF + LLM：实现可观测性智能体的基础设施

报名倒计时第二天！快来参与可观测性开源开发者Meetup |南京站

今天很高兴与大家分享 DeepFlow 在可观测性智能体方面所做的一些工作。今天的话题主要包括两个方面：如何使用 eBPF 解决数据质量的问题，如何在此基础上使用 LLM 构建高效率的智能体。从这两方面出发，我们能看到为何说 eBPF 和 LLM 是实现可观测性智能体的关键基础设施。

上面第一个问题实际上是一个数据治理问题，得到高质量数据有很多方法，例如利用组织规范要求、提升研发工程效能等。今天我分享的主要是后者，具体来说是如何利用 eBPF 这种创新的技术零侵扰获取全栈可观测性数据。在我们有了高质量数据之后，利用 LLM，结合提示词工程、RAG、微调等手段，才能够建设高效的可观测性智能体。今天分享的实践来自于我们的可观测性产品 DeepFlow，同时它也是一个越来越流行的开源项目。最后我也会分享一下关于可观测性智能体的演进思考。

第一个问题的实质是数据治理，目标是获得高质量的可观测性数据。我们先来看一下传统的解决方案，比如我们使用 APM 采集数据，此时如何保证数据的完整性、关联性？特别是在云原生的环境下，客户端访问服务端时，可能会经过复杂的 K8s 网络、各类网关、各种中间件、数据库、以及 DNS 等各类基础服务，这些中间环节都不是 APM 所能覆盖的，甚至 APM 的观测位置和进程实际的网络请求也会有差异。我们在这个基础上做数据治理和数据分析，通常会发现数据的完整性和一致性存在问题，经常需要花费大量的时间和精力来推动提升业务侧插桩覆盖率，还需要利用抓包、看日志等方式串联大量基础服务的异构数据。下面这幅图相信是我们使用 APM 时经常会碰到的问题：客户端观测到的时延是 500ms，而服务端观测到的只有 10ms，更糟糕的是可能服务端还没发插桩。

言归正传，我们为什么说 eBPF 是高质量可观测性信号源的基础设施呢？eBPF 技术是一种内核的可编程技术，下面这张图上的每个小蜜蜂都是 eBPF 可以 Hook 的函数位置。我们在云主机上的任何一个进程，它的所有内部状态，我们都可以使用 eBPF 通过 Hook 业务函数、系统调用、内核函数、网络和磁盘驱动函数来进行感知。更关键的是，这个动作因为有 eBPF Verifier 的存在是完全安全的，而且因为有 JIT 编译机制的存在其性能可媲美内核原生代码。

eBPF 技术有两个独特的优势，可以很好的解决 APM 面临的数据质量问题。第一个优势是零侵扰（Zero Code），一个 eBPF 程序的运行不需要对任何应用进程进行代码修改、重编译、重启，它是一项即插即用的技术，可以随时上到你的生产环境中。第二个优势是全栈（Full Stack），无论是业务进程，还是网关、消息队列、数据库、操作系统，都可以使用 eBPF 采集到观测数据。因此当一个进程在运行时，它与整个软件栈的交互，从业务逻辑到语言运行时，从共享库到内核再到硬件驱动，都可以使用 eBPF 来覆盖。从下图中我们可以看到，eBPF 能够采集的 Raw Data 是非常丰富的，包括：Process Events、File Events、Perf Events、Socket Events、Kernel Events、Hardware Events。今天 QCon 这个 Session 的主题是业务可观测性，对于这个主题来讲，我们先把焦点放到前四类数据上。

但是上图中大家看到的这些数据只是 Raw Data，需要进行识别、提取、转换、关联、聚合等操作才能得到我们能日常使用的业务可观测性数据。下面这张图是 DeepFlow 中对 eBPF 原始数据处理的一部分总结，可以看到我们基于 Socket Events 可以提取出 API 的 Request/Error/Delay 黄金指标，通过关联这些指标可以构建 Service Map，通过关联所有的调用可以形成分布式追踪的调用链，而通过聚合这些调用链可以继续构建出更细粒度的 API Map。这其中，基于 eBPF 的零侵扰分布式追踪是 DeepFlow 原创的能力，无需插桩、无需注入 TraceID 即可实现分布式追踪，感兴趣的小伙伴欢迎到我们的 GitHub Repo^[4] 上下载试用。除此之外，从 Process Events 可提取进程启停日志，从 File Events 可以提取 File Access Log，从 Perf Events 可以提取 CPU、内存、GPU、显存、锁事件并绘制性能剖析火焰图。

除了获取观测信号以后，我们还需要做的一项重要工作就是给数据注入统一的标签。比如注入从 K8s、Cloud、CMDB 中获取的资源和业务标签，帮助我们横向关联全栈数据；注入系统层面的进程、线程、协程等标签，以及面向网络层面的 Subnet、IP、TCP SEQ 等标签，帮助我们纵向关联分布式调用链。

以分布式追踪为例，我们来看看 DeepFlow 使用 eBPF 做到的效果。下图对比了 APM 和 eBPF 追踪结果的差别：使用 APM 一般能覆盖 Java 进程，但对于整个应用中的 API 网关、微服务网关、服务网格、DNS、Redis、MySQL 等通常难以覆盖，对其他非 Java 语言的应用覆盖代价也较大。使用 eBPF，基于零侵扰和全栈数据，整个调用栈可以涵盖所有的业务进程和基础设施进程，以及 K8s 网络传输、文件读写等事件。这项能力是一项非常前沿的创新，我们将这个工作发表了一篇近 20 页的学术论文，去年已经被美国计算机学会顶级学术会议 ACM SIGCOMM 录用。

回到今天 Session 的主题业务可观测性，那么 eBPF 从内核中获取到的数据如何与业务关联起来呢？eBPF 是内核技术，整个生态讨论的点聚焦在系统、性能、安全等方面；而应用关注业务语义，开发者希望获取的是业务、效率方面的信息。如何让 eBPF 的可观测性突破次元壁，从系统到业务，下面我也来讲讲 DeepFlow 的做法。以 Socket Data 为例，对 eBPF 获取到的数据进行协议解析时，我们通常只会解析标准协议（如 HTTP、MySQL 等）的头部字段。现在 DeepFlow 已经支持了二十多种协议解析，涵盖 HTTP1/2/S、RPC、MQ、DB、Network 几大类。DeepFlow 内置的解析能力可以从这些协议的头部乃至 Payload 中提取标准字段，例如 URL、SQL 语句、错误码等等。但是对于位于例如 HTTP Payload 中的业务错误码、交易流水号、订单 ID、汽车车架号等信息，是不能按照统一的逻辑来提取的。而且有时候业务会使用 Protobuf、Thrift 等方式进行序列化，需要结合相应的 Schema 才能对 Payload 进行解析。

这里我们使用了另一项技术 WebAssembly 来解决这个问题。实际上如果我们认为 eBPF 是一种内核可编程技术的话，那么 WebAssembly 就是一种用户态可编程技术。DeepFlow 使用它实现了一套安全、高性能、热加载的插件机制，用户可以使用 Golang、Rust、C/C++ 等语言编写 Plugin，实现对业务 Payload 的按需解析，从而对 Request Log、File Access Log 等 eBPF 观测数据进行增强。例如，你可以基于 DeepFlow 提供的 Plugin SDK，编写一段 Golang 程序，解析 HTTP 的 Protobuf Payload，提取业务关心的字段。你甚至能使用 Payload 中的 Error Code、Error Message 等信息改写原始 HTTP Request Log 中的相应字段。

最后，这一部分的内容标题是「使用 eBPF 构建高质量的可观测性信号源」。因此我们的观点是 eBPF 是一项基础设施，是整个可观测性建设的第一步。在零侵扰可观测性能力的雄厚基石之上，我们可以将传统侵入式的数据按需的纳入进来，并注入统一的标签，从而建设一个更加强大的可观测性平台。eBPF 的能力，就像是星级争霸一开始就敲上一段 Whos your daddy 让地图全开；而传统的侵入式数据，则像是业务方按需对局部区域使用科学球进行定点探查。

今天分享的第二个点，是如何在一个高质量数据基础上，使用 LLM 的能力来构建可观性智能体。在以前，AIOps 最大的苦恼在于数据质量差（覆盖度低、格式乱）。当你打算开始做 AIOps 的时候，通常要花费小半年甚至更久的时间推动数据治理。现在，有了 eBPF 的高质量数据意味着基石牢固了，同时又恰逢 AGI 时代，LLM 展露出了远比以往小模型更强大的能力。因此我们认为 eBPF + LLM 是实现可观测性智能体的基础设施。下面我来分享一些 DeepFlow 在这方面的实践。

目前阶段，DeepFlow 并没有面向所有问题来做智能体，我们希望能挖掘开发、测试、运维整个流程中的问题，挑选出来两三个适合于通过结合可观测性 + 智能体来解决的最痛的痛点，先聚焦在这两三个点上做透。我们找到的第一个场景是工单，具体来讲是工单群创建初期阶段的混乱过程；第二个场景是变更，具体来讲是变更之后的性能劣化快速定界；第三个场景是漏洞，这个场景我们还在探索中，今天将会分享一些我们的初步思考。

工单的低效：我们先假设你的企业里面告警会触发创建一个群聊，例如创建一个飞书群。举一个我们在客户处看到的典型场景：第一个人被拉进工单群以后，他可能看看调用链追踪的数据，做一些分析后发现不是自己的问题；然后把第二个人拉进群，这个人看了一些指标数据，做了一些分析后又发现不是自己的问题；然后把第三个人拉进群，这个人看了看事件数据，做了一些分析后还是发现不是自己的问题；然后拉第四个人、第五个人、...；可能直到部门里那个最厉害的人老王被拉进群，又做了更加深入细致的分析和总结，才能盖棺定论并将工单转给合正确的责任人小李。我们经常发现，在工单匹配到小李之前，这个过程是非常混乱的、低效的，耗时可能长达一个多小时。即使开头拉进去的人并不是在全程参与，但这个工单群的存在也会时不时打断他们的正常工作，对工单群内所有人的效率都造成了明显的影响。

可观测性智能体可以怎样解决这个问题呢？工单被创建时，会自动将 AI Agent 驱动的机器人拉到工单群中。AI Agent 先调用 DeepFlow API 查看追踪、指标、事件、日志等数据种的一种，并对数据使用一系列统计算法进行特征总结（从而有效降低 Token 数量），然后使用这些特征信息作为 Prompt 调用 LLM（目前主要是 GPT4）进行分析。分析完一种数据之后，AI Agent 利用 LLM 的 Function Calling 或者 JSON Mode 等能力，决定还需要分析其他哪个或哪些类型的数据。最后，AI Agent 基于所有分析结果再请求 LLM 做一次归纳总结。

在这个过程中，DeepFlow 的 eBPF 提供了完整的、全栈的可观测性数据，AutoTagging 为所有数据注入了统一的、语义丰富的标签。基于分析结果，AI Agent 能够利用例如 label.owner 等标签将对应的负责人准确的拉到工单群中来。目前阶段，虽然 AI Agent 的工单定界准确率虽然还无法达到 100%，但他已经能够在大多数情况下将工单群初期非常混乱的一个多小时成功的压缩到一分钟，而且显著减少了工单群里的人数，从而显著提高了整个团队的工作效率。

变更的低效：我们发现在云原生环境下，服务发版之后的性能劣化原因可能是多方面的，而且由于调用链、软件代码栈的复杂性，负责 On Call 的小伙伴有时候很难定位根因，也很有可能因为对自己知识范围以外的内容不懂而轻易误判。这类问题发生后，一般只能临时扩容或回滚恢复业务，等待问题修复以后再做一次发版。但是，测试环境不见得能复现生产环境中的问题，所以我们又不得不引入一系列的流量回放机制辅助分析问题的根因。在这个场景下，我们希望 AI Agent 能够帮助开发者快速定界性能劣化的根因，将版本再次上线的时间能大幅提前。

对于调用链复杂的场景，我们在工单 Agent 的例子中已经有了很好的解决思路。而对于函数调用栈复杂的场景，这正好是 eBPF 的拿手好戏，它能够零侵扰的获取进程运行时的业务函数、库函数、运行时函数、内核函数调用栈。由于 eBPF 的安全性和低开销，Profiling 能够持续开启，因此在变更之后性能劣化到无法容忍之前，通常已经积累了一段时间的 Profiling 数据，AI Agent 利用这些数据有望快速完成根因定界。

eBPF Profiling 数据涵盖了非常广泛的技术栈，任何一个业务开发都难以理解其中的全部信息。这种场景恰好是 AI Agent 擅长的。如下图所示，LLM 通常已经能够理解内核函数、运行时函数、基础库函数的知识，因此这部分函数的分析结果是可以直接给出的。即使有 LLM 不擅长的，由于这类函数所在的软件项目更新频率不高，且属于通用知识，因此我们可以考虑通过微调对 LLM 不掌握的部分进行增强。我们再来看一些常用的应用库函数，例如 Python 的 Requests 等等，这类库的特点是数量非常多、迭代比较快、接口文档非常丰富，我们可以考虑将此类函数的文档向量化，利用 RAG 机制来对 LLM 的分析进行增强。再往上就是企业内部的业务代码了，它们不是通用知识、数量也更大、变化也更快，因此我们选择优化提示词的方式来将他们直接喂给 LLM，例如我们可以在服务发版时在 K8s 中注入对应的 Git commit_id label，DeepFlow 的 AutoTagging 能力能够非常容易的让 AI Agent 通过 commit_id 定位到最近的代码修改记录并告知 LLM。可以看到，通过组合使用 LLM、Fine-tuning、RAG、Prompt Engineering 能技术，能够完整覆盖 eBPF 全栈 Profiling 数据中涉及到的所有专业领域，帮助开发者快速定界根因。

漏洞的低效：有报道表名，「漏洞整改可能做了 76% 的无用功，仅有 3% 的漏洞应优先关注」。DeepFlow 目前还在探索如何在这个环节使用 AI Agent 提效。可以肯定的是 eBPF 是 Cloud Workload Security 绝佳的数据采集技术。Isovalent 总结了安全的四大黄金观测信号：Process Execution、Network Socket、File Access、Layer 7 Network Identity。DeepFlow 目前对这四个信号都有了一部分覆盖，未来还会持续增强，我相信随着这些数据的补齐，结合 LLM 一定能做出非常亮眼的安全场景 AI Agent。

这一部分的最后，我们来谈一谈如何持续改进 AI Agent。以工单场景为例，我们在测试环境中利用混沌工程可以构造大量的异常数据，由于这些异常我们知道正确的根因，因此可以用于评估 AI Agenl 并持续改进。在生产环境（注：PPT 右侧应为生产环境），我们加入了让使用者评分的机制，Agent 开发人员基于评分进行改进。

那么 DeepFlow 的 AI Agent 目前到底长什么样子呢？这部分我们来快速的介绍一下。目前 DeepFlow 企业版页面中，从拓扑图、调用链追踪、持续剖析页面都能唤出 AI Agent，同时 Agent 的 API 也可被飞书 ChatBot 调用实现工单专家的功能。当 AI Agent 给出第一轮总结后，同时也会提供三四个左右你可能会继续询问的问题，直接点击这些问题可以继续对话。当然用户也能直接输入自己的问题进行对话。

另外，DeepFlow 社区版中今天也发布了 AI Agent 的能力，目前能够对当前 Grafana Panel 的数据进行分析。当前我们支持了 Topo 和 Tracing 两个 Pannel，适配了 GPT、通义千问、文心一言、ChatGLM 四种大模型，欢迎大家下载试用。

最后，我来分享一下 DeepFlow AI Agent 未来的演进方向。

现在，eBPF 已经能完整覆盖云端应用，下一步我们将会把它的能力扩展到端侧，包括智能汽车上的自动驾驶和智能空间两大域控，以及一些权限允许的智能手机场景。

另一方面，我们也发现 RAG 有很大的优化空间，这里分享一篇 RAG 的综述 Retrieval-Augmented Generation for Large Language Models: A Survey^[5]，希望对大家有帮助。

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

访问 DeepFlow Demo^[6]，体验零插桩、全覆盖、全关联的可观测性。