eBPF全链路网络可观测性平台

一、项目概述

1.1 传统可观测性方案的困境

在项目启动前，团队使用的可观测性方案面临三大根本性挑战：

• 代码侵入性：APM 探针（SkyWalking、Pinpoint）需要 Java Agent 挂载或代码手动埋点，每次升级都要重新发版；业务团队对 APM 的性能损耗（通常 3-8%）抱怨已久
• 资源消耗高：CNCF OpenTelemetry 方案的采集侧资源消耗在高频调用场景下达到 5-10%，与业务进程争抢 CPU 和内存
• 覆盖不完整：应用层埋点只能看到「服务A调用服务B」，但无法看到网络层的 TCP 重传、DNS 延迟、连接池耗尽等基础设施层问题

1.2 为什么选择 eBPF

eBPF（Extended Berkeley Packet Filter）是 Linux 内核 4.x 引入的一项革命性技术。它允许在特权模式下运行用户自定义的程序，拦截内核任意位置的函数调用，且无需修改业务代码、无需重启进程。

1.3 核心目标与规模

平台需要覆盖三大核心场景：TCP 连接生命周期追踪（SYN → ESTABLISHED → FIN 全链路）、网络延迟热力图（从 NIC 到应用的全链路时延拆解）、服务间流量拓扑（无需业务代码，输出类似 Istio 的服务依赖图）。

二、技术架构设计

2.1 三层数据流架构

整体架构分为三层，每一层都有明确的数据传输路径：

2.2 eBPF 程序类型选择

针对不同观测目标，选择不同类型的 eBPF 程序：

• XDP（eXpress Data Path）：挂载在网卡驱动层面，在网络包到达内核协议栈之前拦截。适合做网络包级别的统计、过滤和丢弃。优势：最早可见性，在 DMA 阶段就拿到数据包。
• Tracepoint：在内核关键函数上设置静态探测点（如 tcp:tcp_set_state、net:netif_receive_skb）。优势：稳定可靠，内核版本升级不失效。
• kprobe / kretprobe：动态插桩任意内核函数入口和返回点。优势：灵活，可以追踪任意内核函数；劣势：依赖内核符号，可能因版本升级失效。

2.3 eBPF Map 架构

eBPF Map 是内核态和用户态共享数据的核心数据结构：

// 1. 连接跟踪 Hash Map：四元组 → 连接状态
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 65536);
    __type(key, struct conn_key_t);    // (src_ip, src_port, dst_ip, dst_port)
    __type(value, struct conn_info_t); // state, last_time, bytes_in, bytes_out
} conn_map SEC(".maps");

// 2. 延迟直方图 Map：每个 CPU 核心独立的直方图桶
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 256); // 256 个延迟桶：0-1ms, 1-2ms, ..., 255-256ms
    __type(key, __u32);        // bucket index
    __type(value, __u64);       // count
} latency_histogram SEC(".maps");

// 3. Ring Buffer：高吞吐事件传递（相比 perf buffer 效率更高）
struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 256 * 1024); // 256KB ring buffer
} events SEC(".maps");

三、核心技术挑战与解决方案

四、关键技术实现

4.1 TCP 连接生命周期追踪

在 tcp:tcp_set_state tracepoint 上挂载 eBPF 程序，追踪每个 TCP 连接的状态转换：

// eBPF C 代码：TCP 连接状态追踪
// 挂载点：/sys/kernel/debug/tracing/events/tcp/tcp_set_state

SEC("tracepoint/tcp/tcp_set_state")
int trace_tcp_set_state(struct trace_event_raw_tcp_set_state *ctx) {
    struct sock *sk = (struct sock *)ctx->skaddr;
    if (!sk) return 0;

    __u32 pid = bpf_get_current_pid_tgid() >> 32;
    __u8 new_state = ctx->new_state;

    // 构建连接四元组 Key
    struct conn_key_t key = {
        .src_ip = sk->__sk_common.skc_rcv_saddr,
        .src_port = bpf_ntohs(sk->__sk_common.skc_num),
        .dst_ip = sk->__sk_common.skc_daddr,
        .dst_port = sk->__sk_common.skc_dport,
    };

    struct conn_info_t *conn = bpf_map_lookup_elem(&conn_map, &key);
    if (!conn) {
        // 新建连接记录
        struct conn_info_t new_conn = {0};
        new_conn.state = new_state;
        new_conn.start_time = bpf_ktime_get_ns();
        new_conn.pid = pid;
        bpf_map_insert_elem(&conn_map, &key, &new_conn);
    } else {
        conn->state = new_state;
        conn->last_time = bpf_ktime_get_ns();
    }

    // 统计各状态的连接数
    __u32 state_key = new_state;
    __u64 *count = bpf_map_lookup_elem(&tcp_state_counter, &state_key);
    if (count) {
        __sync_fetch_and_add(count, 1);
    }

    return 0;
}

4.2 延迟直方图采集

在 TCP 发送和接收路径上埋点，计算数据包在网络栈中的停留时间，聚合为直方图：

SEC("tracepoint/net/netif_tx")
int trace_tx_latency(struct trace_event_raw_net_dev_template *ctx) {
    __u64 now = bpf_ktime_get_ns();
    __u32 cpu = bpf_get_smp_processor_id();
    struct sk_buff *skb = (struct sk_buff *)ctx->skbaddr;

    if (!skb) return 0;

    // 记录发送时间戳（如果之前没有记录过）
    __u64 *ts = bpf_map_lookup_elem(&tx_ts_map, &skb);
    if (!ts) {
        bpf_map_insert_elem(&tx_ts_map, &skb, &now);
    } else {
        // 计算延迟并更新直方图
        __u64 latency_us = (now - *ts) / 1000; // 转换为微秒
        __u32 bucket = latency_us / 1000;       // 1ms 粒度的桶
        if (bucket >= 255) bucket = 255;

        __u32 bucket_key = bucket;
        __u64 *bucket_val = bpf_map_lookup_elem(&latency_histogram, &bucket_key);
        if (bucket_val) {
            __sync_fetch_and_add(bucket_val, 1);
        }
        bpf_map_delete_elem(&tx_ts_map, &skb);
    }
    return 0;
}

4.3 Go 用户态消费端

Go 程序使用 cilium/ebpf 库读取 Map 数据和消费 Ring Buffer：

package main

import (
    "github.com/cilium/ebpf"
    "github.com/cilium/ebpf/ringbuf"
    "golang.org/x/sys/unix"
)

type ConnInfo struct {
    State     uint8
    StartTime uint64
    LastTime  uint64
    BytesIn   uint64
    BytesOut  uint64
}

func startRingBufferConsumer(m *ebpf.Map, connMap *ebpf.Map) {
    // 打开 Ring Buffer
    rd, err := ringbuf.NewReader(m)
    if err != nil {
        log.Fatalf("opening ringbuf reader: %v", err)
    }
    defer rd.Close()

    // 启动消费 goroutine
    go func() {
        for {
            record, err := rd.Read()
            if err != nil {
                if errors.Is(err, unix.EINTR) {
                    continue
                }
                log.Printf("reading ringbuf: %v", err)
                return
            }

            // 解析事件数据
            event := (*ConnEvent)(unsafe.Pointer(&record.RawSample[0]))
            processConnEvent(event, connMap)
        }
    }()
}

func processConnEvent(event *ConnEvent, connMap *ebpf.Map) {
    key := ConnKey{
        SrcIP:   event.SrcIP,
        SrcPort: event.SrcPort,
        DstIP:   event.DstIP,
        DstPort: event.DstPort,
    }

    // 读取连接信息并更新 Prometheus 指标
    var conn ConnInfo
    if err := connMap.Lookup(key, &conn); err == nil {
        tcpState.WithLabelValues(
            fmt.Sprintf("%d", conn.State),
            fmt.Sprintf("%d", event.PID),
        ).Inc()
    }
}

// Prometheus 指标暴露
var (
    tcpState = promauto.NewCounterVec(prometheus.CounterOpts{
        Name: "tcp_state_transitions_total",
        Help: "Total TCP state transitions by state and process",
    }, []string{"state", "pid"})

    latencyHistogram = promauto.NewHistogramVec(prometheus.HistogramOpts{
        Name:    "tcp_latency_us",
        Help:    "TCP packet latency histogram in microseconds",
        Buckets: []float64{100, 200, 500, 1000, 2000, 5000, 10000},
    }, []string{"pod", "direction"})
)

4.4 服务拓扑自动发现

通过 Destination NAT（DNAT）信息重建服务间调用拓扑，无需任何业务代码修改：

• 在 net:nf_nat_packet tracepoint 捕获 DNAT 转换记录
• 根据转换前后的 IP:Port 对照 Service CIDR 范围，识别源服务和目标服务
• 每分钟汇总生成流量矩阵，输出为 Prometheus 格式的 network_flow_total 指标
• Grafana 使用该指标渲染服务拓扑图（类似 Istio 的 service graph）

五、性能指标与成果

5.1 采集性能对比

5.2 业务价值

• 告警误报率降低：网络质量告警的误报率从 15% 降至 3%。通过 TCP 重传热力图，可以精准区分「网络抖动」和「应用慢」两类告警。
• 故障定位时间缩短：在一次跨机房网络抖动事件中，通过 eBPF 追踪快速定位到特定链路的重传率异常，故障定位时间从 45 分钟缩短至 8 分钟。
• 覆盖范围扩展：从原来仅覆盖 Java 服务（APM 探针支持的语言）扩展到全语言全服务，覆盖率从 60% 提升至 100%。