[项目自荐] 基于 ebpf 的高性能无侵入网络观测项目

52 天前
 chenjiandongx

Repo: https://github.com/packetd/packetd

项目概览

tcpdump 是一款强大的网络抓包工具,可以结合 wireshark 工具对流量进行分析。但是 tcpdump 缺少了一些现代化观测方案联动的手段,比如生成 traces/metrics/logs ,同时也缺少实时以 7 层网络视角观测的能力。另外 tcpdump 更倾向于作为一种 cli 工具,而不是以 agent 模式持续运行。

So, packetd is born.

packetd 支持从数据流中解析出多种应用协议( HTTP/gRPC/MySQL/Redis/Kafka/...),使用请求的来回 roundtrip 作为其核心概念,进而衍生出 traces/metrics/roundtrips 数据。

packetd 提供了更加现代化的可观测手段,可以无缝地对接现有的观测体系:

快速上手

packetd 支持 watchagent 两种运行模式。前者作为一种 cli 工具 debug 网络请求,后者使用 agent 模式持续监听网络包并上报可观测数据。

watch mode

agent mode

jq 序列化 roundtrips 数据(以 HTTP 协议为例)

{
  "Request": {
    "Host": "192.168.255.128",
    "Port": 36654,
    "Method": "GET",
    "Header": {
      "Accept": [
        "*/*"
      ],
      "User-Agent": [
        "curl/8.11.1"
      ]
    },
    "Proto": "HTTP/1.1",
    "Path": "/get",
    "URL": "/get",
    "Scheme": "",
    "RemoteHost": "httpbin.org",
    "Close": false,
    "Size": 0,
    "Chunked": false,
    "Time": "2025-07-06T12:36:51.49809695-04:00"
  },
  "Response": {
    "Host": "54.243.106.191",
    "Port": 80,
    "Header": {
      "Access-Control-Allow-Credentials": [
        "true"
      ],
      "Access-Control-Allow-Origin": [
        "*"
      ],
      "Connection": [
        "keep-alive"
      ],
      "Content-Length": [
        "255"
      ],
      "Content-Type": [
        "application/json"
      ],
      "Date": [
        "Sun, 06 Jul 2025 16:36:51 GMT"
      ],
      "Server": [
        "gunicorn/19.9.0"
      ]
    },
    "Status": "200 OK",
    "StatusCode": 200,
    "Proto": "HTTP/1.1",
    "Close": false,
    "Size": 255,
    "Chunked": false,
    "Time": "2025-07-06T12:36:52.044846786-04:00"
  },
  "Duration": "546.749836ms"
}

traces 数据(以 HTTP 协议为例)

详见 docs/observability.md

Span Name <http.request.method>

Span Attributes:

协议支持

可观测性

packetd 可以结合社区的可观测方案将 packetd 产生的数据进行持久化及可视化。

Prometheus + Grafana

OpenTelemetry + Jaeger

Elasticsearch + Kibana

性能压测

packetd 做了大量的性能优化,有着优秀的性能表现,能在较低资源使用的同时保证数据准确率。

Header 字段含义:

Field Desc
PROTO 协议类型
REQUEST client 发起的总请求次数
WORKERS client 并发数
BODYSIZE client 请求 body 大小
ELAPSED 单轮压测耗时
QPS 单轮压测请求速率
BPS 单轮压测流量速率 bit/s
PROTO (REQUEST) 捕获的请求总数
PROTO (PERCENT) 捕获的请求总数与实际总请求数的比例(达成率)
CPU (CORE) 压测期间使用的平均 CPU 核心数
MEMORY (MB) 压测结束时 RSS 内存

HTTP 压测结果,0.2C/40MB 内存可以处理 10Gb/s 的网络请求数据。

REQUEST WORKERS BODYSIZE ELAPSED QPS BPS PROTO (REQUEST) PROTO (PERCENT) CPU (CORE) MEMORY (MB)
10000 1 10KB 0.755s 13249.506 1035Mib 10000 100.000% 0.093 38.348
10000 1 100KB 0.761s 13138.960 10.02Gib 10000 100.000% 0.105 40.012
10000 1 1MB 0.779s 12838.487 100.3Gib 10000 100.000% 0.103 37.754
100000 10 10KB 2.094s 47765.909 3732Mib 100000 100.000% 0.367 41.258
100000 10 100KB 2.156s 46373.435 35.38Gib 100000 100.000% 0.343 39.418
100000 10 1MB 2.086s 47949.323 374.6Gib 100000 100.000% 0.359 39.699
100000 100 10KB 1.545s 64715.898 5056Mib 100000 100.000% 0.478 41.906
100000 100 100KB 1.560s 64095.780 48.9Gib 100000 100.000% 0.461 42.387
100000 100 1MB 1.542s 64863.419 506.7Gib 100000 100.000% 0.467 39.383
1000000 1000 10KB 13.950s 71684.121 5600Mib 996969 99.697% 0.636 49.406

MySQL 压测结果:

REQUEST WORKERS ELAPSED QPS SQL PROTO (REQUEST) PROTO (PERCENT) CPU (CORE) MEMORY (MB)
10000 1 2.316s 4317.668 select * from stress_test limit 100 10001 100.010% 0.026 38.562
10000 1 5.291s 1889.883 select * from stress_test limit 1000 10001 100.010% 0.066 46.715
1000 1 3.030s 330.042 select * from stress_test limit 10000 1001 100.100% 0.096 46.895
10000 10 0.544s 18368.043 select * from stress_test limit 100 10010 100.100% 0.128 38.180
10000 10 1.949s 5130.091 select * from stress_test limit 1000 10010 100.100% 0.154 63.730
1000 10 1.595s 627.029 select * from stress_test limit 10000 994 99.400% 0.125 78.801
2000 20 3.182s 628.515 select * from stress_test limit 10000 1977 98.850% 0.126 78.863
2000 30 3.066s 652.303 select * from stress_test limit 10000 1944 97.200% 0.124 79.227

更多协议结果可参考 docs/performance.md

2182 次点击
所在节点    程序员
13 条回复
malingxin
52 天前
应用场景是?是不是可以容器化放集群内跑
oudioppa
52 天前
给你点个 star
swananan
52 天前
我只是快速的过了一遍 readme ,所以问的问题可能没那么精确。
好奇这个项目是基于 libpcap 来实现的,没有基于 xdp ,所以为啥说是基于 ebpf 呢。是因为 libpcap 支持 cbpf filter 这种吗。
感觉如果不支持对 tls 流量解析,就有点可惜啊。可以考虑像 ecapture 那样,对稳定的 tls 开源库做 hook ,直接抓取相关流量,这样感觉适用性是不是更广一些
Gilfoyle26
52 天前
好像以前黑马的 c++有这个,不知道是不是一样的
flamingooo
52 天前
蛮好的, 正好最近要写个 agent : )
lrh3321
52 天前
给你点了个 star
chenjiandongx
52 天前
@malingxin 是的,后续版本打算直接集成到 k8s ,使用 operator + agent 的方式运行。
chenjiandongx
52 天前
@swananan libpcap 也算是 cbpf ,classic bpf 的一种,算是 bpf 的一种形态。
chenjiandongx
52 天前
@swananan 项目也保留可扩展其他 sniffer 的接口,后续会继续尝试引入 CO-RE 方式的 sniffer 。
swananan
52 天前
所以严格的说,目前这个项目并不是基于 ebpf 的探测项目哈,没有恶意,只是指出
bumblebeek
52 天前
对比 cilium 的 pwru 有什么优势?
mango88
52 天前
对比 deepflow 的话,亮点能介绍一下吗
tuchuanw
52 天前
牛逼,mark 一下,慢慢学习👻

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1150621

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX