文 / eBPF 技术摸索 SIG
随着 eBPF 技术的广泛应用，在操作系统层面提供了更多的观测能力，站在操作系统层面对利用的行为数据进行 trace 追踪成了一种利用监控的新伎俩，本文次要介绍基于 eBPF 实现对利用网络数据监控的背地逻辑。
一、一个申请数据包的组成
一个残缺的利用申请数据包次要蕴含申请地址信息及具体的申请数据。其中申请地址信息就是咱们常说的五元组信息 (IP+ 端口 + 协定)，这部分都是操作系统协定栈负责去解析；而申请数据则由利用通过各种协定去封装并解析，常见的利用协定有：http、mysql、rediis、dns 等。
利用每一个申请数据的承受与发送都是通过网络相干的零碎调用与操作系统交互，如果申请报文没有加密，那么在零碎调用处做一个拦挡通过函数入参就能轻而易举的拿到利用协定数据。当下热门的利用可观测都是基于此办法对利用网络数据进行 trace，包含：时延、流量统计、协定等。
二、基于零碎调用的申请追踪
2.1 网络申请模型
一个利用过程基于零碎调用的网络申请模型如下 (这里仅介绍客户端)：
- 通过 socket 去建设套接字，取得一个 fd 作为 socket 的标识。
- 通过 connect 填写 IP 端口信息发动申请连贯。
- 通过 read/write 申请 / 接管具体数据，除了 read/write 零碎调用还有 send/recvfrom，readv/writev 等可用。
- 通过 close 完结本次申请。
通过下面的流程图咱们大略理解了一次残缺网络申请的零碎调用逻辑。有几点须要留神：
- 对于单个建链实现的申请而言，其发送数据和接收数据往往是串行的，或者说一个 write 必然匹配一个 read，因而咱们能力统计到 RT 工夫，而 read/write 的返回字节数就能够作为咱们的流量统计。
- write/read 如何配对，对于客户端而言，是先 write 再 read，罕用的做法是通过过程 pid 和 socket fd 作为配对标识，实现 write/read 这一次残缺申请数据的配对。
2.2 零碎调用追踪
eBPF 技术能够在不扭转内核源码或加载内核模块状况下在内核插入指定 hook 代码，能在内核或应用程序执行到一个特定的 hook 点时执行。预约义的 hooks 蕴含零碎调用、函数出 / 入口、内核追踪点、网络事件等等。
有了 eBPF 做零碎调用的 hook 当前，零碎调用的事件采集对于咱们来说变得分外不便，只不过咱们须要留神下哪些事件须要上报及申请数据上报当前的匹配策略。同时对于获取申请数据是有一些考究，对于 write 发送数据而言在零碎调用函数入口间接获取入参就能够获取数据，然而对于 read 读取数据而言咱们须要在零碎调用函数的进口做 hook 去拿数据。
上文中提到 pid+fd 作为 traceid 作为申请的惟一标记，有如下两种办法能够实现：
办法 1：当有 connect 的时候先在 BPF map 中记录下这个 traceid，示意有一个新的申请建设，后续的 read/write 申请数据都是以此为配对。不过在 http 长连贯场景下，connect 发动可能在咱们 trace 之前，所以只能通过 netlink 等其余形式来获取链接信息。
办法 2：实际上咱们关怀的只是 read/write 的申请数据及如何配对，是否能够仅依据 fd 获取连贯信息？BPF 程序能够拿到以后过程的 task_struct，依据 fd 能够拿到对应的 sock 构造体，sock 构造体中记录了申请地址信息。
除此之外就是 BPF 框架的技术选型，咱们采纳了 Coolbpf 开发，通过对 libbpf 的改良，在具备 core 个性的同时提供了更简洁的 API 接口，exporter 程序能够间接以 so 的模式加载代码。以上只是网络申请事件采集的最小单元，借助 exporter 的其余能力，能够取得更丰盛的数据指标：谬误数、时延、过程级流量统计等。
三、利用协定辨认
在零碎调用层面只能辨认到 4 层网络协议，对于利用的 7 层协定无奈辨认，实际上是在 hook 零碎调用拿到 buf 参数后，对 buf 的头部几个字节做协定头解析，目前反对的协定有：http、mysql、kafak、dns、mongo、pgsql、dubbo。对于 https 等加密报文能够通过 uprobe 的形式对 ssl 加密库做 hook，后续会反对这部分性能。
四、部署
咱们在日常值班问题中也有碰到各种网络抖动时延问题，因而咱们将此局部性能放在了 SysOM 智能诊断平台的 agent 中，能够通过容器一键部署，并在 grafana 中查看对应的时延散布及具体的时延申请信息。
同时咱们与 sls 单干，也将此局部内核采集的能力输入给了 iLogtail。
五、what’s more
除了上文提到的基于零碎调用的利用观测，对于利用因为本身起因收包迟缓造成网络“假抖动”的状况，咱们基于 Coolbpf 也做了相干观测实际。一个残缺的收包流程次要分为两个阶段：
阶段 1：OS 通过软中断将数据包上送到利用的收包队列并告诉过程后就算实现了协定栈的收包工作。
阶段 2：利用失去告诉后去收报队列取包。
这两个阶段能够认为是异步的，咱们将数据包达到收包队列到利用实现取包这段时间作为利用的 ” 收包延迟时间 ” 进行观测，基于此办法在网络抖动问题定位中失去了极大帮忙。
案例 1 某业务利用基于 dubbo 框架容器收到 tcp 包后提早了将近 1s 业务层才收到
部署 SysOM agent 对“收包延迟时间”进行观测，发现 ” 收包延迟时间 ” 将近 1 秒，右侧红框局部为工夫，单位为纳秒，联合左侧红框每次产生延迟时间都在某某工夫 42 秒，狐疑跟业务某定时工作相干造成利用本身时延，最终排查到业务有某个工作会定时收集 jvm 的参数，对利用有 stop 动作，停掉该工作后打消了抖动问题。
案例 2 业务高峰期，客户端 rpc 耗时比服务端多 20-30ms
业务监控如下：
部署 SysOM agent 对“收包延迟时间”进行观测，发现对应时间段存在利用“收包延迟时间”较大，因而首先排除了网络链路问题。红框局部为工夫，单位为纳秒，图中工夫须要加上 8 小时。
依据时序比照发现是因为此时间段利用在做 GC 导致，最初通过调整 GC 参数解决。
六、总结
以上是基于 Coolbpf 在可观测性的相干实际，相干性能都集成在了 SysOM 的 agent 中，后续会引入更多对利用观测的性能。当利用日志无奈解决问题或者没有日志的状况下，利用 eBPF 技术在 OS 层面对利用行为逻辑的观测，在定位某些利用的疑难问题时有着极大帮忙。
参考链接：
eBPF 介绍链接地址：https://www.rutron.net/posts/…
coolbpf gitee 代码仓链接地址：https://gitee.com/anolis/cool…
内核文档链接地址：https://www.kernel.org/doc/ht…
龙蜥实验室 coolbpf 链接地址：https://lab.openanolis.cn/#/a…
—— 完 ——