抓包不如“开天眼”：用 eBPF 搭一条实时流量取样与可视化流水线
作者：Echo_Wish
很多做运维的兄弟，排查问题第一反应是什么？
tcpdump 走起。
然后抓一堆包，导到 Wireshark，CPU 飙升，磁盘爆满，线上同事盯着你：“哥，别搞了行不行？”
说句实在话，传统抓包是“事后诸葛亮”。
我们真正需要的是——
实时、低开销、可持续运行的流量观测能力。
这几年让我彻底改观的技术，就是：
eBPF
它让我们不用改内核，不用重启机器，就能在内核里插“探针”。
不是抓全量，而是聪明地取样。
今天我带你搭一条完整的实时流量取样 + 可视化流水线：
eBPF 程序 → 用户态收集 → 流式聚合 → 可视化展示
我们一步步拆。
一、为什么不是 tcpdump，而是 eBPF？
传统抓包：
- 全量抓
- 高 I/O
- 高 CPU
- 不适合长期运行
而 eBPF：
- 在内核层过滤
- 只上传关键数据
- 取样可控
- 性能开销极低
你可以把它理解成：
在内核里装了一个“聪明的流量筛子”。
二、核心思路：内核只做取样，不做重活
我们先写一个简单的 eBPF 程序，挂载在 tc ingress 点，做流量采样。
使用 Python 的 bcc 框架（底层也是基于 eBPF）：
from bcc import BPF
program = """
#include <uapi/linux/ptrace.h>
#include <linux/skbuff.h>
BPF_HASH(packet_cnt, u32, u64);
int count_packets(struct __sk_buff *skb) {
u32 key = 0;
// 简单采样：1/100 概率
if (bpf_get_prandom_u32() % 100 != 0) {
return TC_ACT_OK;
}
u64 *val, zero = 0;
val = packet_cnt.lookup_or_init(&key, &zero);
(*val)++;
return TC_ACT_OK;
}
"""
b = BPF(text=program)
fn = b.load_func("count_packets", BPF.SCHED_CLS)
注意这里的逻辑：
bpf_get_prandom_u32() % 100
这就是采样控制点。
不是抓 100%，
而是 1%。
这意味着什么？
如果你的机器 10Gbps 流量，
你只处理 100Mbps 的元数据。
这就是性能差距。
三、别在内核里做复杂分析
很多人第一次写 eBPF，会忍不住想：
- 统计 RTT
- 解析 HTTP
- 计算延迟分布
我劝一句：别。
内核只负责采样与计数。
真正的分析放在用户态。
我们可以在用户态读取 map：
import time
while True:
time.sleep(1)
for k, v in b["packet_cnt"].items():
print("sampled packets:", v.value)
这一步，你就已经实现了：
- 实时采样
- 每秒输出统计
- 几乎无性能影响
四、升级：按源IP聚合
我们改造一下，让它按源 IP 统计。
BPF_HASH(ip_cnt, u32, u64);
int count_packets(struct __sk_buff *skb) {
if (bpf_get_prandom_u32() % 100 != 0) {
return TC_ACT_OK;
}
u32 src_ip = skb->remote_ip4;
u64 *val, zero = 0;
val = ip_cnt.lookup_or_init(&src_ip, &zero);
(*val)++;
return TC_ACT_OK;
}
然后在用户态做聚合：
for k, v in b["ip_cnt"].items():
print("IP:", k.value, "count:", v.value)
这时候你已经拥有：
实时 Top IP 监控能力。
比起传统流量分析工具，
它的优势是：
- 无需 sidecar
- 不侵入应用
- 内核级可见性
五、把数据推入可视化流水线
观测不是为了打印日志。
我们要画图。
推荐两种方案：
- 推送到 Prometheus
- 或发给 Apache Kafka
例如，推到 Prometheus：
from prometheus_client import Gauge, start_http_server
g = Gauge('sampled_packets', 'Sampled packets per second')
start_http_server(8000)
while True:
total = 0
for k, v in b["packet_cnt"].items():
total += v.value
g.set(total)
time.sleep(1)
然后用：
Grafana
画出实时流量趋势图。
这就是完整流水线：
eBPF → Python exporter → Prometheus → Grafana
六、真实生产场景怎么玩？
场景一：防止流量突增
采样统计 QPS，如果瞬间翻倍：
- 自动触发告警
- 自动扩容
- 或启用限流策略
场景二：检测异常 IP
通过 Top N 分析：
- 发现 DDoS 早期征兆
- 识别异常扫描行为
场景三：流量画像
- 内部服务调用关系
- TCP 重传率
- 延迟分布
eBPF 能挂的点非常多：
- kprobe
- tracepoint
- tc
- XDP
真正牛的团队，是把它当成“内核观测操作系统”。
七、性能对比的真实感受
我做过一次测试：
- tcpdump 全量抓：CPU 40%
- eBPF 1% 采样：CPU 3%
差距不是一点点。
而且 eBPF 程序运行在内核安全沙箱里，不会崩机器。
这就是它的恐怖之处。
八、别走偏：eBPF 不是银弹
我要泼点冷水。
eBPF 很强，但：
- 调试难度高
- 版本依赖多
- 内核差异坑不少
如果只是偶尔排查问题，
你不一定非要上它。
但如果你在做：
- 高并发系统
- 金融级稳定性要求
- 边缘节点监控
那它几乎是必备能力。
九、一个更成熟的架构
如果你想进阶，可以参考：
Cilium
Pixie
这些系统本质上都是：
eBPF + 流式处理 + 可视化平台
它们已经帮你封装好了复杂逻辑。
最后的思考
运维的本质，不是救火。
是让系统“自我可见”。
以前我们是：
出事了再抓包。
现在我们应该是：
实时看到趋势，提前干预。
eBPF 给我们的不是工具。
