什么?Coolbpf不仅可以远程编译,还可以发现网络抖动!-创新互联
近日,在 2022 云栖大会龙蜥峰会 eBPF & Linux 稳定性专场上,来自 eBPF 技术探索 SIG Maintainer 的毛文安分享了《Coolbpf 的应用实践》技术演讲,以下为本次演讲内容:
为德惠等地区用户提供了全套网页设计制作服务,及德惠网站建设行业解决方案。主营业务为网站设计制作、做网站、德惠网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!一、为什么要支持可移植?随着 BPF 技术的发展,开发一个 BPF 程序变得越来越简单,尽管 BPF 提升了便利性,但 BPF 也一直在追求另一个方面:可移植性。BPF 可移植性被定义为成功编写并通过内核验证的一个 BPF 程序,能运行在不同内核版本。
进行 BPF 的移植有两个挑战:
1. 不同内核版本数据的内存布局不同。
2. 内核类型和数据结构不断变化,结构体字段可能被移除或重命名。
BPF CO-RE(Compile Once - Run Everywhere)是实现可移植性的一个手段。
为了支持 CORE,提供了以下组件:
- BTF:描述内核镜像,获取内核及BPF程序类型和代码的关键信息
- Clang 释放 bpf 程序重定位信息到.btf 段
- Libbpf CO-RE 根据.btf 段重定位 bpf 程序
需要进行重定位的信息主要有三类:
- 结构体相关重定位,这部分和BTF息息相关。Clang通过__builtin_preserve_access_index()记录成员偏移量。
- map fd 、全局变量(data、bss、rodata)、extern 的变量重定位,主要依赖于 ELF 的重定位机制,来更新 eBPF 指令的 imm 字段。
- 子函数重定位,是为了将 eBPF 程序调用的子函数同主函数放在一起,便于一起加载到内核。
使用 libbpf 进行 BPF CORE 的开发步骤如下:
- 生成带所有内核类型的头文件 vmlinux.h,通过 bpftool 生成。
- 使用 Clang(版本10 或更新版本)将 BPF 程序的源代码编译为 .o 对象文件;
- 从编译好的 BPF 对象文件中生成 BPF skeleton 头文件 bpftool gen 命令生成;
- 在用户空间代码中包含生成的 BPF skeleton 头文件;
- 编译用户空间代码,则嵌入 BPF 对象代码无需发布单独的文件。
大致有如下的函数调用:
__open() :创建并打开 BPF 应用,之后可以设置 skel->rodata 变量。 __load() :初始化,加载和校验 BPF 应用部分。 __attach() :附加所有可以自动附加的 BPF 程序。有事件和网络运行报文到达时,会触发运行 bpf 程序。 __destroy():分离所有的 BPF 程序并使用其使用的所有资源。
eBPF 程序的主要开发方式有三种,它们各有优缺点,见下:
1、内核自带示例代码:基于内核 samples/bpf 示例代码,无 CORE。该方式没有任何基于第三方的开源项目,资源占用量低。但缺点是需要自己完全重新搭建工程,效率较低,且版本兼容性较差。
2、BPF CORE:基于 libbpf 自己编写的 bpf_core_read 代码,开发机生成对应目标机的二进制程序。该方式不依赖在环境中部署 Clang/LLVM ,资源占用少。但是需要搭建编译工程,部分代码相对固定,无法动态配置。
3、BCC:基于应用最广的开源项目,开发效率较高。但是每一次运行都要执行 Clang/LLVM 编译,存在内存、CPU 等资源的争抢;目标环境依赖对应内核头文件。
二、Coolbpf 的功能和架构Coolbpf 提供了远程编译(云编译)。其中远程编译指运行程序的目标机器与编译程序不在同一个机器上,能够解决资源占用问题;提供了本地编译和基础库封装,方便用户调用基础库进行编写;提供了低版本内核的支持;提供了 BTF 的自动生成和发布,用户无需手动适配,下载即可直接使用;提供了自动化测试以及支持 Python/Go/Rust 等高级语言进行应用开发。
Coolbpf 天然支持 BPF 的 CORE 能力,它解决了编译和资源消耗的问题,同时,前面介绍的复杂的 libbpf 开发步骤完全被简化了。用户只需要专注自己的功能开发,不用关注环境搭建和冗余代码开发。
Coolbpf 提供了标准化的 bpf 编译服务。首先将 bpf.c 提交到远程编译服务器时,服务器会根据的内核版本针对不同的语言返回点 bpf.so 或 bpf.o 为高级的应用程序提供服务。因此在你的高级语言代码中,只需加载 bpf.so 即可运行程序,无需再手动触发 Libbpf 的 open()、load()、attach()等函数,而是由高级语言程序的 init()自动完成,这样用户可以快速搭建和部署工程,只需专注于数据输出之后的处理。
Coolbpf 还支持在没有 eBPF 特性的低内核版本上,通过我们提供的 eBPF 驱动,帮助它安全的在低版本上运行。我们将高版本上 eBPF verifier 校验部分实现在一个驱动里,它会进行各种安全校验,保证 eBPF 对比于内核模块的安全性。另外,我们把原来基于 libbpf 的调用都转换为 IOCTL 的系统调用。
之前支持的 helper 函数、创建 map 、加载 program 都会转化成低版本上的 kprobe 或 tracepoint 的实现,另外还支持 perf event 和 jit。这样就使得同一个用户程序,加载这样一个驱动,就能不修改 eBPF 程序代码而安全的运行在低版本内核上。
三、Coolbpf 的网络应用实践Raptor 是基于 Coolbpf 的系统可观测工具,能够运行在低版本内核如 alios、CentOS 3.10 等。它可以作为一个 SDK,提供给第三方使用,进行数据采集。
在这个网络应用观测中,通过监控系统调用中的数据交互、请求和回复等信息,来确定交互的数据内容和五元组等信息,通过 map 的交互方式发送给用户态,做到了无侵入的方式做观测,最终呈现比如流量统计、请求时延等观测结果。
我们来看一个具体的问题,了解 Coolbpf 是如何发现收包阶段的网络抖动问题。我们知道网络收包分为两个阶段:
阶段 1:OS 通过软中断将数据包送到应用的收包队列并通知进程,完成协议栈的收包工作。
阶段 2:应用得到通知后从收包队列取数据。
我们在 Coolbpf 里写一段 BPF 程序,只需监控两个 tracepoint:tcp_probe,tcp_rcv_space_adjust 就能查询到阶段 2 的延迟问题
在这个案例中,某业务应用收包慢,发现内核侧已经收到了 tcp 包,但是应用侧将近 1s 后才收到。
观测方法:部署 eBPF agent,发现阶段 2“收包延迟时间”将近 1 秒。
确定原因:每次发生延迟时间都在某时刻的大致 42 秒处,怀疑跟业务某定时任务相关造成应用自身延时,最终排查到业务有某个任务会定时收集 jvm 的参数,对该业务有 stop 的操作。
解决方法:停掉该任务后,消除了抖动问题。
相关链接:
eBPF技术探索 SIG 地址:https://openanolis.cn/sig/ebpfresearch、
原文链接
本文为阿里云原创内容,未经允许不得转载。
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧
本文名称:什么?Coolbpf不仅可以远程编译,还可以发现网络抖动!-创新互联
本文路径:http://myzitong.com/article/pjgoi.html