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

[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 提供了更加现代化的可观测手段，可以无缝地对接现有的观测体系：

• 支持 Prometheus /metrics 路由暴露指标。
• 支持 Prometheus RemoteWrite 协议主动上报 Metrics 数据（如 VictoriaMetrics ）。
• 支持 OpenTelemetry 协议上报 traces 数据。

快速上手

• docs/quickstart.md

packetd 支持 watch 和 agent 两种运行模式。前者作为一种 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:

• http.request.size
• http.response.size
• http.request.method
• http.response.status_code
• url.full
• url.scheme
• server.address
• server.port
• client.remote.host
• network.peer.address
• network.peer.port
• network.transport
• network.protocol.name
• network.protocol.version
• http.request.header.<key>
• http.response.header.<key>

协议支持

• amqp
• dns
• grpc
• http
• http2
• kafka
• mongodb
• mysql
• postgresql
• redis

可观测性

• docs/observability.md

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

[malingxin]

应用场景是？是不是可以容器化放集群内跑

[oudioppa]

给你点个 star

[swananan]

我只是快速的过了一遍 readme ，所以问的问题可能没那么精确。
好奇这个项目是基于 libpcap 来实现的，没有基于 xdp ，所以为啥说是基于 ebpf 呢。是因为 libpcap 支持 cbpf filter 这种吗。
感觉如果不支持对 tls 流量解析，就有点可惜啊。可以考虑像 ecapture 那样，对稳定的 tls 开源库做 hook ，直接抓取相关流量，这样感觉适用性是不是更广一些

[Gilfoyle26]

好像以前黑马的 c++有这个，不知道是不是一样的

[flamingooo]

蛮好的, 正好最近要写个 agent : )

[lrh3321]

给你点了个 star

[chenjiandongx]

@malingxin 是的，后续版本打算直接集成到 k8s ，使用 operator + agent 的方式运行。

[chenjiandongx]

@swananan libpcap 也算是 cbpf ，classic bpf 的一种，算是 bpf 的一种形态。

[chenjiandongx]

@swananan 项目也保留可扩展其他 sniffer 的接口，后续会继续尝试引入 CO-RE 方式的 sniffer 。

[swananan]

所以严格的说，目前这个项目并不是基于 ebpf 的探测项目哈，没有恶意，只是指出

[bumblebeek]

对比 cilium 的 pwru 有什么优势？

[mango88]

对比 deepflow 的话，亮点能介绍一下吗

[tuchuanw]

牛逼，mark 一下，慢慢学习👻