HUATUO 基于BPF的可观测能力建设及 GPU 大模型性能剖析
第三届 CCF·夜莺开源创新论坛，于 2025.7.4 在京举行，论坛上，众多可观测性领域的专家齐聚一堂，共同分享、探讨监控、可观测性、AI 相关的议题。来自“滴滴出行”的内核专家张同浩，带来了主题为《HUATUO 基于BPF的可观测能力建设及 GPU 大模型性能剖析》的分享，笔者在现场作为观众受益良多，现将其内容整理如下，供大家参考。
内核领域的问题相对难查，比如某个行为慢了，普通工程师很难定位问题。张老师围绕 HUATUO 开源项目介绍了内核观测方面的一些痛点、解决思路。HUATUO 开源项目是一个基于 eBPF 的内核可观测性工具，其网址是：https://huatuo.tech，HUATUO 项目最初由滴滴开发开源，目前也是托管在中国计算机学会开源发展技术委员会。
系统故障分析的现状和挑战
张老师总结了系统故障分析的现状和挑战：
- 缺乏故障现场
- 漂移止损、降级处理等无法保留现场
- 复现问题难度大
- 云原生基础架构日趋复杂：容器虚拟层，业务混部，资源优先级，共享内核，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 调度延迟
- 设备响应延迟
- 文件系统刷盘阻塞
之前 bcc 社区有一张内核观测的全景图，张老师也画了一张 HUATUO 的全景图，来阐释 HUATUO 关注的点：
下面是 HUATUO 采集的数据绘制的一些图表样例：
除了指标，还要采集异常事件，因为异常事件通常是更关键的东西，张老师罗列了个中思考：
HUATUO 也采集了一些异常事件，写入到 ElasticSearch 中，下面是一些样例：
另外就是 AUTOTRACING，张老师也介绍了其中的一些思考：
解决哪些痛点:
- 解决相比指标，事件，更高维度层面的，系统，业务应用的突增，偶发问题。
适合哪些内核子系统
- CPUSYS，CPUIDLE，IO，Loadavg，容器争抢等
如何组织观测数据
- 调用栈，火焰图？
损耗和有效性数据的平衡
- 自动、按需触发执行
另一个关键特性是：持续性能剖析 Continuous Profiling，张老师介绍了其思考：
为什么需要持续性能剖析：
- 持续的，可回溯的，全景的，全语言的性能剖析能力。
应用场景：
- 性能分析，故障排查，放火演练，链路压测。
观测对象：
- CPU使用，内存分配、内存分布，锁竞争。
基础技术要求：
- 低损耗，零侵扰。
这里也取得了一些基本的成果：
另外，张老师也分享了 GPU 大模型性能剖析相关的内容，首先是挑战：
- GPU 用户库，内核驱动闭源，关键信息难获取
- 解释型语言，JIT 中间层
- 发行版多，运行环境多，难统一
- 零侵入训练推理框架
- 指标统计 vs 性能剖析
GPU 这块是对一些关键 Python 函数做了埋点，效果如下：
One more thing
HUATUO 项目目前是在孵化阶段，在滴滴内部已经产生了业务价值，对此项目感兴趣的朋友，可以联系我（我的微信：picobyte）拉入 HUATUO 社区的微信群。
