写了个 eBPF 流量可视化工具(生产目前在跑)

[oom]

旁路挂在交换机镜像口上，支持多网卡，不侵入业务链路，单个二进制文件跑起来就是一整套系统（ Web 控制台 + eBPF 采集 + 存储查询）

GitHub: https://github.com/xxddpac/netra

这两天刚好在真实的 20Gbps 专线上部署验证：

• 两块物理网卡各自独立接镜像流量（两台核心交换机分别镜像到同一台服务器的两个物理口，共享同一份 eBPF map ）
• 抓取峰值流量 10.1Gbps / 160 万 pps（毫无压力，无丢包）
• 40 核机器上，netra 进程稳定占用约 1.2 个核（约 3%）
• 存储用 DuckDB ，流量历史按小时封存 Parquet 文件，进行一些列优化，1 亿+ 条数据查询稳定在 2-3 秒
• 接入 AI 以及 MCP 对接内部工具

有大流量环境的大佬欢迎聊聊实测性能

[sskycn]

强

[owt5008137]

喜欢造轮子之挑战 opentelemetry 么

[zhcode]

试一下，看能不能替代掉 vnstat

[qW7bo2FbzbC0]

可以说说为什么选用 duckdb 吗

[oom]

@qW7bo2FbzbC0
主要这两方面：
1.DuckDB 可以直接内嵌到 Go 二进制里,省去了数据库运维这块
2.列式存储针对海量数据的聚合查询性能非常强，实际压测表现查询性能比 SQLite 快 20-100 倍

一开始只用 SQLite 时当数据量上来之后基本没法用，所以额外引入 duckDB,低频数据不大的走 SQLite,高频海量数据的走 duckDB ，各自发挥优势

[oom]

@zhcode 期待大佬测试结果

[oom]

@owt5008137 这两个实现的功能不一样呀

[oom]

@sskycn

[AEnjoyable]

可惜了，数据分析性能不是问题，问题是存储。
我现在用 dpdk 采集+clickHourse 存储，公司的需求太夸张了

需要采五元组，并分析和记录存储半年用于回溯

[AEnjoyable]

#9 补充一下，三线合计带宽最大是 140Gbps ，
每秒会话最大 60 万条，还要算网速😭

[oom]

@AEnjoyable #10
140Gbps,60 万会话/秒，这个应该属于运营商级别了吧
采集这块我也觉得不是问题，理论上 eBPF 架构是能扛的住的。
你们存半年实际用了多少存储空间呢？另外 ClickHouse 分布式存储查半年量级的五元组数据的性能表现大概是什么样的，这个能分享下吗。
我刚看了最近 10 天 2 亿多条五元组数据，聚合查询耗时 3.85 秒，我觉得对于单机 duckDB 来说也还行

[owt5008137]

@oom opentelemetry 整个生态组件很多的，现成的集成器里有基于 eBPF 的，可视化，存储，传输都是不同层面的组件。看起来可以包含你这个组件需要的功能。无非某些地方满足不了你的需求其实都可以写插件解决，它那上面基本上所有层面的组件都是有插件机制的。

[AEnjoyable]

@oom 机房级的，没运营商那么夸张。
ch 数据压缩可以，差不多每天 70 多 g ，（我们的这些五元组基本都是长链接），现在只跑了三个多月，8t 多