HUATUO 基于BPF的可观测能力建设及 GPU 大模型性能剖析

第三届 CCF·夜莺开源创新论坛于 2025.7.4 在北京举行。论坛上，众多可观测性领域的专家分享和探讨了监控、可观测性、AI 等议题。

来自滴滴出行的内核专家张同浩，带来了主题为《HUATUO 基于BPF的可观测能力建设及 GPU 大模型性能剖析》的分享。笔者在现场作为观众受益良多，现将其内容整理如下，供大家参考。

内核领域的问题相对难查，比如某个行为慢了，普通工程师很难定位问题。张老师围绕 HUATUO 开源项目介绍了内核观测方面的一些痛点、解决思路。HUATUO 开源项目是一个基于 eBPF 的内核可观测性工具，其网址是：https://huatuo.tech，HUATUO 项目最初由滴滴开发开源，目前也是托管在中国计算机学会开源发展技术委员会。

核心要点

生产系统故障分析的核心难点包括缺乏现场、复现困难、跨团队协作成本高、缺少持续全景观测。
HUATUO 希望从内核层提供持续、低损耗、全方位的系统观测能力。
HUATUO 关注 TCP/IP 协议栈、系统负载、CPU 调度器、中断关闭时长、内存管理、VFS/Block Device IO 等关键观测点。
除了指标，异常事件、AUTOTRACING 和持续性能剖析也是内核可观测能力的重要组成部分。
GPU 大模型性能剖析面临闭源驱动、解释型语言、JIT 中间层、运行环境差异和零侵入要求等挑战。

系统故障分析的现状和挑战

张老师总结了系统故障分析的现状和挑战：

缺乏故障现场
- 漂移止损、降级处理等无法保留现场
复现问题难度大
- 云原生基础架构日趋复杂：容器虚拟层，业务混部，资源优先级，共享内核，sidecar 架构
- 生产环境中业务应用上下游依赖复杂
- 偶发的、突发的事件类型多，并且问题触发条件苛刻
人力物力成本高
- 涉及团队多，协调难，服务器成本高
缺乏持续全景观测
- 缺乏更细粒度有效指标和观测数据
- 观测维度单一，缺乏全面的，全景的观测能力
- 缺乏对系统的深度，持续性的剖析能力

即便有问题现场也不容易，各种排查工具轮番上阵：

监控指标
系统日志
top…
perf top…
strace…
dmesg…
vmstat/mpstat/…
ss…
tcpdump…
wireshark…
docker inspect…
stap/dtrace…
go tools…
bpftrace…
bcc…
还没搞定？开始凌乱了…

要是有个一剑封喉的必杀技工具就好了。

HUATUO 是希望从内核层面提供一个全景的观测能力，能够持续的、全方位的观测系统。

从故障处理视角看，这类能力解决的不是“多采几个指标”的问题，而是帮助工程师在故障发生后保留更多现场信息，并在复杂云原生环境里看到更细粒度的系统行为。

HUATUO 的核心特性

最让我印象深刻的是低损耗。内核函数被频繁调用，如果埋点位置不合理，会对系统性能造成很大影响；如果关键位置埋点缺失，又会导致无法定位问题。具体在哪里埋点，很依赖经验。HUATUO 最终选定的观测点是：

TCP/IP 协议栈
- 协议栈，网卡硬件丢包
- Qdisc 队列延迟
- SKB 发送、接收延迟
系统负载检测
- 容器级别
- 进程长期处于D状态
- 进程 fork 异常突增
CPU 调度器
- 争抢
- 延迟
- 系统调用
中断关闭时长
- 硬中断关闭时长
- 软中断关闭时长
- 直方图
内存管理
- kswapd 异步回收耗时
- 直接回收，阻塞进程耗时
VFS/Block Device IO
- IO 调度延迟
- 设备响应延迟
- 文件系统刷盘阻塞

这些观测点覆盖了网络、调度、内存、IO 和容器负载等常见故障域。对 SRE 来说，它们对应的是生产系统中最容易出现“应用看起来慢，但应用日志说不清楚”的位置。

之前 bcc 社区有一张内核观测的全景图，张老师也画了一张 HUATUO 的全景图，来阐释 HUATUO 关注的点：

下面是 HUATUO 采集的数据绘制的一些图表样例：

除了指标，还要采集异常事件，因为异常事件通常是更关键的东西，张老师罗列了个中思考：

HUATUO 也采集了一些异常事件，写入到 ElasticSearch 中，下面是一些样例：

AUTOTRACING：按需捕捉更高维问题

另外就是 AUTOTRACING，张老师也介绍了其中的一些思考：

解决哪些痛点:

解决相比指标，事件，更高维度层面的，系统，业务应用的突增，偶发问题。

适合哪些内核子系统

CPUSYS，CPUIDLE，IO，Loadavg，容器争抢等

如何组织观测数据

调用栈，火焰图？

损耗和有效性数据的平衡

自动、按需触发执行

持续性能剖析 Continuous Profiling

另一个关键特性是持续性能剖析 Continuous Profiling，张老师介绍了其思考：

为什么需要持续性能剖析：

持续的，可回溯的，全景的，全语言的性能剖析能力。

应用场景：

性能分析，故障排查，放火演练，链路压测。

观测对象：

CPU使用，内存分配、内存分布，锁竞争。

基础技术要求：

低损耗，零侵扰。

这里也取得了一些基本的成果：

GPU 大模型性能剖析

张老师也分享了 GPU 大模型性能剖析相关的内容。首先是挑战：

GPU 用户库，内核驱动闭源，关键信息难获取
解释型语言，JIT 中间层
发行版多，运行环境多，难统一
零侵入训练推理框架
指标统计 vs 性能剖析

GPU 这块是对一些关键 Python 函数做了埋点，效果如下：

对可观测性建设的启发

这次分享里有几个对可观测性建设很有价值的启发：

问题	HUATUO 的思路	对工程团队的价值
故障现场容易丢失	持续采集关键内核指标和异常事件	故障后能回看现场，而不是只靠复现。
工具很多但线索分散	从内核关键路径建立全景观测	减少在 top、perf、strace、tcpdump 等工具之间反复切换。
低损耗和有效性难平衡	选择关键观测点，按需触发追踪	避免为了观测引入过高性能开销。
AI/GPU 性能难剖析	对关键 Python 函数做埋点	在训练和推理场景中获得更多性能线索。