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 支持 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 协议为例)
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
1 malingxin 63 天前 应用场景是?是不是可以容器化放集群内跑 |
2 oudioppa 63 天前 给你点个 star |
![]() | 3 swananan 63 天前 我只是快速的过了一遍 readme ,所以问的问题可能没那么精确。 好奇这个项目是基于 libpcap 来实现的,没有基于 xdp ,所以为啥说是基于 ebpf 呢。是因为 libpcap 支持 cbpf filter 这种吗。 感觉如果不支持对 tls 流量解析,就有点可惜啊。可以考虑像 ecapture 那样,对稳定的 tls 开源库做 hook ,直接抓取相关流量,这样感觉适用性是不是更广一些 |
![]() | 4 Gilfoyle26 63 天前 好像以前黑马的 c++有这个,不知道是不是一样的 |
5 flamingooo 63 天前 蛮好的, 正好最近要写个 agent : ) |
![]() | 6 lrh3321 63 天前 给你点了个 star |
![]() | 7 chenjiandongx OP @malingxin 是的,后续版本打算直接集成到 k8s ,使用 operator + agent 的方式运行。 |
![]() | 8 chenjiandongx OP ![]() @swananan libpcap 也算是 cbpf ,classic bpf 的一种,算是 bpf 的一种形态。 |
![]() | 9 chenjiandongx OP @swananan 项目也保留可扩展其他 sniffer 的接口,后续会继续尝试引入 CO-RE 方式的 sniffer 。 |
![]() | 10 swananan 63 天前 ![]() 所以严格的说,目前这个项目并不是基于 ebpf 的探测项目哈,没有恶意,只是指出 |
![]() | 11 bumblebeek 63 天前 ![]() 对比 cilium 的 pwru 有什么优势? |
![]() | 12 mango88 63 天前 ![]() 对比 deepflow 的话,亮点能介绍一下吗 |