eBPF 云原生可观测性实战：从 DeepFlow 零侵扰采集到 GreptimeDB 统一存储、从 Cilium 网络观测到 AI Agent 可观测闭环的完全指南（2026）

摘要：传统可观测体系在云原生和 AI Agent 场景下面临三大瓶颈：采集侵入强、链路成本高、数据碎片化。本文基于 eBPF（扩展伯克利包过滤器）技术，结合 DeepFlow、Cilium、GreptimeDB、AutoMQ 等开源项目，构建一套零侵扰、低成本、统一存储、支持智能分析的可观测流水线。最终实现：eBPF 采集 → AutoMQ 传输 → GreptimeDB 存储 → LLM 智能取数的完整可观测闭环。

目录

1. 引言：可观测性的困境与 eBPF 的破局
2. eBPF 技术深度解析
   • 2.1 eBPF 架构与工作原理
   • 2.2 eBPF 在可观测性中的核心优势
   • 2.3 eBPF 程序类型与 Hook 点
3. DeepFlow：零侵扰可观测性平台
   • 3.1 DeepFlow 架构设计
   • 3.2 基于 eBPF 的零代码数据采集
   • 3.3 SmartEncoding 全栈关联
   • 3.4 生产环境部署实战
4. Cilium：eBPF 驱动的云原生网络
   • 4.1 Cilium 架构与 eBPF 数据平面
   • 4.2 Hubble 可观测性实战
   • 4.3 Cilium 网络策略与安全检查
5. AutoMQ：Kafka 存储卸载到对象存储
   • 5.1 AutoMQ 架构原理
   • 5.2 AutoMQ 与 eBPF 数据采集的集成
6. GreptimeDB：可观测性 2.0 数据库
   • 6.1 GreptimeDB 架构设计
   • 6.2 统一存储 Metrics / Logs / Traces
   • 6.3 基于对象存储的低成本存储
7. 完整流水线搭建实战
   • 7.1 环境准备与架构规划
   • 7.2 DeepFlow 部署与 eBPF 采集配置
   • 7.3 AutoMQ 集群部署
   • 7.4 GreptimeDB 部署与数据接入
   • 7.5 端到端验证
8. AI Agent 可观测闭环
   • 8.1 AI Agent 可观测的特殊挑战
   • 8.2 基于 eBPF 的 AI Agent 行为追踪
   • 8.3 LLM 智能分析与自动诊断
9. 性能优化与生产最佳实践
   • 9.1 eBPF 程序性能调优
   • 9.2 DeepFlow 数据采样与存储优化
   • 9.3 GreptimeDB 查询与压缩策略
10. 总结与展望

1. 引言：可观测性的困境与 eBPF 的破局

1.1 传统可观测体系的三大瓶颈

在云原生时代，微服务架构和容器化部署使得系统复杂度呈指数级增长。传统的可观测性方案主要依赖三种信号：

1. Metrics（指标）：Prometheus 等工具通过拉取（Pull）或推送（Push）方式采集数值型指标
2. Logs（日志）：应用通过日志框架输出结构化或非结构化日志
3. Traces（链路追踪）：通过 SDK 埋点实现分布式追踪

然而，这套体系在生产环境中暴露出严重问题：

瓶颈一：采集侵入强

要在应用中实现完整的可观测性，必须在代码中显式集成各类 SDK：

// 传统链路追踪需要在代码中手动埋点
import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/trace"
)

func ProcessOrder(ctx context.Context, orderID string) error {
    // 手动创建 Span
    ctx, span := otel.Tracer("order-service").Start(ctx, "ProcessOrder")
    defer span.End()
    
    // 业务逻辑
    if err := validateOrder(ctx, orderID); err != nil {
        span.RecordError(err)  // 手动记录错误
        return err
    }
    
    // ... 更多手动埋点
}

这种方式存在明显缺陷：

• 代码侵入性高：需要在每个关键函数中添加追踪代码
• 多语言支持成本高：Java、Go、Python、Node.js 等每种语言都需要维护独立的 SDK
• SDK 版本升级困难：大规模微服务场景下，升级 SDK 版本需要改动大量仓库
• 第三方服务盲区：数据库、消息队列、外部 API 等无法植入 SDK 的服务成为监控盲区

瓶颈二：链路成本高

以 Prometheus + Grafana + Jaeger 为例，一个中等规模的 Kubernetes 集群（500 个 Pod）的可观测性成本：

仅基础设施成本就超过 $500/月（按云服务商的按需价格计算），还不包括：

• 工程师学习多种查询语言（PromQL、LogQL、TraceQL）的时间成本
• 多套系统间数据关联困难导致的排障效率低下
• 存储扩容和性能调优的持续投入

瓶颈三：数据碎片化

Metrics、Logs、Traces 三种信号通常由独立的系统采集、存储和查询，导致：

问题场景：用户反馈 API 延迟飙升至 5 秒

排障流程：
1. 在 Grafana 中查看 P99 延迟指标 → 发现订单服务延迟异常
2. 切换到 Jaeger 搜索对应的 Trace → 找到慢请求，发现是数据库查询慢
3. 切换到 Loki 查看订单服务的日志 → 发现数据库连接池耗尽的错误
4. 切换到 Prometheus 查看数据库连接数指标 → 确认连接数达到上限

问题：四个系统间来回切换，上下文丢失，排障时间超过 30 分钟

1.2 eBPF：内核级的「上帝视角」

eBPF（扩展伯克利包过滤器） 是 Linux 内核（4.1+）提供的一项革命性技术，它允许在不修改内核源码、不加载内核模块的情况下，安全地在内核中运行沙箱化的最小指令集程序。

eBPF 在可观测性场景中的核心优势：

1. 零侵入：eBPF 程序附加到内核的 Hook 点（系统调用、网络事件、函数调用等），无需修改用户态代码
2. 全栈覆盖：从网络包、系统调用、函数调用栈到数据库协议，eBPF 可以捕获任意层次的观测数据
3. 高性能：JIT（即时编译）将 eBPF 字节码编译为本地机器码，单事件处理开销 < 1 微秒
4. 安全隔离：eBPF 程序通过验证器（Verifier）严格检查，确保不会崩溃内核或进入死循环

// 示例：用 eBPF 捕获 HTTP 请求的简单程序（伪代码）
SEC("kprobe/tcp_sendmsg")
int trace_tcp_sendmsg(struct pt_regs *ctx) {
    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
    struct socket *sock = sk->sk_socket;
    
    // 获取目标 IP 和端口
    u16 dport = sk->sk_dport;
    
    // 记录到 eBPF Map（内核态键值存储）
    u64 key = bpf_ktime_get_ns();
    u32 value = dport;
    bpf_map_update_elem(&tcp_events, &key, &value, BPF_ANY);
    
    return 0;
}

1.3 本文的技术栈与架构

本文将介绍如何基于 eBPF 构建一个完整的可观测性流水线：

┌─────────────────────────────────────────────────────────────────┐
│                      应用与基础设施层                            │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐       │
│  │  Pod A  │  │  Pod B  │  │  Pod C  │  │ Database│       │
│  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘       │
└───────┼─────────────┼─────────────┼─────────────┼────────────┘
        │             │             │             │
        ▼             ▼             ▼             ▼
┌─────────────────────────────────────────────────────────────────┐
│                    eBPF 采集层（DeepFlow Agent）                 │
│  • 自动解码 HTTP/gRPC/MySQL/Redis/Kafka 等协议                 │
│  • 零侵扰采集 Metrics / Traces / Logs                          │
│  • 函数级持续性能剖析（OnCPU/OffCPU FlameGraph）               │
└─────────────────────────────┬───────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                   消息传输层（AutoMQ）                           │
│  • 兼容 Kafka 协议，无缝替换 Kafka                             │
│  • 存储卸载到 S3/OSS，存储成本降低 90%                         │
│  • 自动伸缩，按实际流量计费                                    │
└─────────────────────────────┬───────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                   统一存储层（GreptimeDB）                       │
│  • 同时支持 Metrics / Logs / Traces 三种信号                   │
│  • 基于对象存储（S3/OSS），存储成本降低 50 倍                  │
│  • 支持 SQL 和 PromQL 查询                                     │
└─────────────────────────────┬───────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                  智能分析层（LLM + DeepFlow）                    │
│  • 自然语言查询可观测数据                                       │
│  • 自动异常检测和根因分析                                       │
│  • AI Agent 行为追踪与性能分析                                 │
└─────────────────────────────────────────────────────────────────┘

2. eBPF 技术深度解析

2.1 eBPF 架构与工作原理

eBPF 的核心架构由以下组件组成：

┌──────────────────────────────────────────────────────────────┐
│                      用户态程序                               │
│  • 编写 eBPF C 代码  • 编译为 eBPF 字节码  • 加载到内核    │
└────────────────────────┬─────────────────────────────────────┘
                         │ bpf() 系统调用
                         ▼
┌──────────────────────────────────────────────────────────────┐
│                      eBPF 子系统（内核）                      │
│                                                              │
│  ┌────────────┐   ┌─────────────┐   ┌──────────────────┐   │
│  │  Verifier  │→ │ JIT Compiler │→ │  eBPF 程序执行   │   │
│  │  （验证器） │   │  （即时编译） │   │  （附加到 Hook）│   │
│  └────────────┘   └─────────────┘   └──────────────────┘   │
│         │                                                      │
│         ▼                                                      │
│  ┌────────────┐   ┌─────────────┐                             │
│  │  拒绝加载  │   │ eBPF Maps   │                             │
│  │  （不安全） │   │ （内核-用户 │                             │
│  └────────────┘   │   态通信）  │                             │
│                    └─────────────┘                             │
└──────────────────────────────────────────────────────────────┘

2.1.1 eBPF 程序的生命周期

1. 编写 eBPF 程序：使用 C 语言（或 Rust 通过 aya 框架）编写 eBPF 程序
2. 编译为 eBPF 字节码：使用 LLVM/Clang 将 C 代码编译为 eBPF 字节码（类似 JVM 字节码）
3. 加载到内核：通过 bpf() 系统调用将字节码加载到内核
4. 验证（Verifier）：内核的 Verifier 检查字节码的安全性：
   • 不包含无限循环
   • 不会访问越界内存
   • 不会导致内核崩溃
   • 所有代码路径都有返回值
5. JIT 编译：验证通过后，JIT 编译器将 eBPF 字节码编译为本地机器码（x86_64 / ARM64）
6. 附加到 Hook 点：将编译后的程序附加到指定的 Hook 点（如 kprobe/tcp_sendmsg）
7. 事件触发执行：当 Hook 点被触发时（如 TCP 发送数据），eBPF 程序自动执行
8. 数据传递到用户态：通过 eBPF Maps 或 perf_event 将处理结果传递到用户态程序

2.1.2 eBPF Maps：内核与用户态的桥梁

eBPF Maps 是内核中的键值存储，用于在 eBPF 程序之间、以及 eBPF 程序与用户态程序之间共享数据。

支持的 Map 类型：

// 定义一个 Ring Buffer Map，用于向用户态发送事件
struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 256 * 1024);  // 256KB
} events SEC(".maps");

SEC("kprobe/tcp_sendmsg")
int trace_tcp_sendmsg(struct pt_regs *ctx) {
    struct event *e;
    
    // 在 Ring Buffer 中预留空间
    e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e) return 0;
    
    // 填充事件数据
    e->pid = bpf_get_current_pid_tgid() >> 32;
    e->ts_ns = bpf_ktime_get_ns();
    bpf_get_current_comm(&e->comm, sizeof(e->comm));
    
    // 提交到 Ring Buffer
    bpf_ringbuf_submit(e, 0);
    return 0;
}

2.2 eBPF 在可观测性中的核心优势

2.2.1 零侵入的协议解码

eBPF 可以在内核中直接捕获网络包，并解码应用层协议。DeepFlow 利用这一能力，自动解码超过 20 种协议：

# DeepFlow 自动解码的协议列表
协议类型:
  应用层:
    - HTTP/1.x, HTTP/2, gRPC
    - WebSocket, MQTT
  数据库:
    - MySQL, PostgreSQL, MongoDB
    - Redis, Memcached
  消息队列:
    - Kafka, RabbitMQ (AMQP)
    - NATS, RocketMQ
  存储:
    - NFS, Ceph, S3 API

关键优势：无论应用使用什么语言、什么框架，只要流量经过内核网络栈，DeepFlow 就能自动采集和解析。

2.2.2 全栈关联：从应用到内核的完整调用链

传统追踪工具（如 strace、perf）只能看到单一层次的事件。eBPF 可以同时捕获多个层次的事件，并通过时间戳进行关联：

时间线视图：
┌─────────────────────────────────────────────────────────────┐
│ 用户态应用  │--connect()-->│  │  │  │  │  │  │  │         │
│ 内核网络栈  │  │--tcp_syn-->│--synack-->│--ack-->│         │
│ 物理网卡    │  │  │  │  │  │  │  │  │  │  │  │         │
└─────────────────────────────────────────────────────────────┘

DeepFlow 的 SmartEncoding 技术通过标准化元标签（如 service, instance, endpoint, request_id）实现全栈关联：

-- 在 GreptimeDB 中通过 SQL 关联 Metrics 和 Traces
SELECT 
    t.timestamp,
    t.trace_id,
    t.span_id,
    t.service_name,
    t.operation_name,
    m.cpu_usage,
    m.memory_usage
FROM traces t
LEFT JOIN metrics m ON t.service_name = m.service AND t.timestamp = m.timestamp
WHERE t.trace_id = 'abc123'
ORDER BY t.timestamp;

2.2.3 函数级持续性能剖析

eBPF 可以定期（如每 10 毫秒）触发采样，记录当前 CPU 上执行的进程及其函数调用栈，生成 CPU FlameGraph：

# 使用 DeepFlow 的函数剖析功能
deepflow profile start \
  --service order-service \
  --duration 60s \
  --frequency 99hz \
  --output order-service-flamegraph.svg

# 生成类似以下的 FlameGraph
#   order-service::processOrder (占用 CPU 40%)
#     └── database::query (占用 CPU 35%)
#         └── mysql::send_query (占用 CPU 30%)

OffCPU 剖析：除了 OnCPU（正在使用 CPU 的代码路径），eBPF 还可以剖析 OffCPU（等待 I/O、锁、网络等事件的代码路径），这是传统 profiling 工具难以做到的。

2.3 eBPF 程序类型与 Hook 点

eBPF 支持多种程序类型，每种类型对应不同的 Hook 点：

2.3.1 Kprobes / Kretprobes（内核函数探针）

附加到内核函数的入口（Kprobe）或返回点（Kretprobe）：

SEC("kprobe/tcp_v4_connect")
int trace_tcp_connect_entry(struct pt_regs *ctx) {
    // 在 tcp_v4_connect() 函数入口处执行
    // 可以获取连接试图建立的参数（目标 IP、端口）
    return 0;
}

SEC("kretprobe/tcp_v4_connect")
int trace_tcp_connect_exit(struct pt_regs *ctx) {
    // 在 tcp_v4_connect() 函数返回处执行
    // 可以获取连接是否成功、耗时多久
    int ret = PT_REGS_RC(ctx);  // 获取返回值
    return 0;
}

2.3.2 Uprobes / Uretprobes（用户态函数探针）

附加到用户态程序的任意函数（不需要重新编译程序）：

// 追踪 Go 程序的 http.Handler.ServeHTTP 函数
SEC("uprobe/go-http-server/main.http.Handler.ServeHTTP")
int trace_http_handler(struct pt_regs *ctx) {
    // 在 Go HTTP 处理函数入口处执行
    return 0;
}

实战技巧：使用 bpf2go 工具可以方便地编写和编译 Uprobe 程序。

2.3.3 Tracepoints（内核静态追踪点）

Linux 内核在关键位置预定义了 Tracepoint，比 Kprobe 更稳定（不会因为内核版本升级而失效）：

SEC("tracepoint/syscalls/sys_enter_openat")
int trace_openat(struct trace_event_raw_sys_enter *ctx) {
    // 系统调用 openat() 的 Tracepoint
    const char *filename = (const char *)ctx->args[1];
    char buf[256];
    bpf_probe_read_user_str(buf, sizeof(buf), filename);
    // 记录文件打开操作
    return 0;
}

查看系统支持的 Tracepoint：

# 列出所有 Tracepoint
sudo cat /sys/kernel/debug/tracing/available_events | head -20

# 输出示例：
# syscalls:sys_enter_openat
# syscalls:sys_exit_openat
# sched:sched_switch
# net:net_dev_queue

2.3.4 XDP（eXpress Data Path，高性能网络处理）

XDP 在网卡驱动的最早阶段处理网络包，性能极高（单核 10 Mpps+）：

SEC("xdp")
int xdp_firewall(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    // 解析以太网头部
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_PASS;
    
    // 如果是 IP 包，解析 IP 头部
    if (eth->h_proto == htons(ETH_P_IP)) {
        struct iphdr *ip = data + sizeof(*eth);
        if ((void *)(ip + 1) > data_end) return XDP_PASS;
        
        // 丢弃来自特定 IP 的包
        if (ip->saddr == 0x0A000001) {  // 10.0.0.1
            return XDP_DROP;
        }
    }
    
    return XDP_PASS;  // 放行其他包
}

应用场景：DDoS 防护、负载均衡（类似 IPVS）、流量镜像等。Cilium 的 eBPF 服务负载均衡就是基于 XDP 实现的。

3. DeepFlow：零侵扰可观测性平台

DeepFlow 是云杉网络开源的基于 eBPF 的零侵入可观测性平台，也是本文技术栈的核心组件。

3.1 DeepFlow 架构设计

┌──────────────────────────────────────────────────────────────────┐
│                         DeepFlow Platform                        │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │                  DeepFlow Server (控制平面)                  │  │
│  │  • 接收 Agent 上报的观测数据                                │  │
│  │  • SmartEncoding 标签注入                                   │  │
│  │  • 提供 GraphQL / REST API                                 │  │
│  │  • 集成 Grafana / Prometheus / OpenTelemetry               │  │
│  └────────────────────────┬───────────────────────────────────┘  │
│                           │                                     │
│  ┌────────────────────────▼───────────────────────────────────┐  │
│  │              DeepFlow Agent (数据平面，DaemonSet)            │  │
│  │  • 在每个 Kubernetes 节点上运行                             │  │
│  │  • 加载 eBPF 程序到内核                                    │  │
│  │  • 解码应用层协议（HTTP/gRPC/MySQL/...）                    │  │
│  │  • 生成 Metrics / Traces / Logs                             │  │
│  │  • 发送到 DeepFlow Server 或 Kafka                        │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │                  存储后端（可插拔）                         │  │
│  │  • MySQL / MariaDB：元数据（服务目录、标签定义）            │  │
│  │  • ClickHouse：观测数据（高压缩比、快查询）                │  │
│  │  • Kafka：数据传输通道                                     │  │
│  └────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

3.2 基于 eBPF 的零代码数据采集

DeepFlow Agent 使用 eBPF 实现以下数据采集能力：

3.2.1 自动服务发现与拓扑生成

DeepFlow Agent 通过 eBPF 监听网络流量，自动发现所有服务实例和它们之间的调用关系：

# DeepFlow 自动生成的服务拓扑（示例）
services:
  - name: order-service
    endpoints:
      - port: 8080
        protocol: HTTP/1.1
      - port: 9090
        protocol: gRPC
    instances:
      - ip: 10.244.1.10
        pod: order-service-6f8d9
      - ip: 10.244.2.15
        pod: order-service-6f8da

  - name: mysql-primary
    endpoints:
      - port: 3306
        protocol: MySQL
    instances:
      - ip: 10.244.3.20
        pod: mysql-0

# 自动生成的调用关系
relations:
  - source: order-service
    target: mysql-primary
    protocol: MySQL
    avg_latency: 2.5ms
    qps: 1500

3.2.2 自动分布式追踪

DeepFlow 通过 eBPF 自动生成分布式追踪链路，无需在任何服务中植入 SDK：

HTTP GET /api/orders/123
  │
  ├──> [eBPF 捕获] 订单服务 → MySQL: SELECT * FROM orders WHERE id=123
  │     latency: 1.2ms
  │
  ├──> [eBPF 捕获] 订单服务 → Redis: GET user:456
  │     latency: 0.3ms
  │
  └──> [eBPF 捕获] 订单服务 → 支付服务: POST /api/pay
        │
        └──> [eBPF 捕获] 支付服务 → MySQL: INSERT INTO payments ...
              latency: 3.1ms
              total: 5.2ms

每个请求自动获得一个 trace_id（基于 TCP 四元组 + 时间戳生成），并在 DeepFlow 的 Web UI 中展示完整的调用链。

3.2.3 持续性能剖析（Continuous Profiling）

DeepFlow Agent 通过 eBPF 定期采样（默认每秒 99 次），生成所有服务的 CPU FlameGraph：

# 查看 order-service 的 CPU FlameGraph
deepflow profile query \
  --service order-service \
  --time-range "2026-06-20 05:00:00 ~ 2026-06-20 05:30:00" \
  --profile-type oncpu \
  --output flamegraph.svg

# 生成类似以下结果的 FlameGraph
#   order-service::main (100%)
#     ├── net/http.(*Server).Serve (60%)
#     │     └── order_handler.GetOrder (55%)
#     │           └── database.Query (40%)
#     │                 └── mysql.Driver.Query (35%)
#     └── runtime.gc (40%)

关键特性：

• 开销极低（< 1% CPU）
• 支持 OnCPU（正在使用 CPU 的代码）和 OffCPU（等待 I/O 的代码）
• 自动关联到具体的 Pod / 容器 / 进程

3.3 SmartEncoding 全栈关联

DeepFlow 的 SmartEncoding 技术是其核心竞争力之一。它通过标准化元标签实现所有观测数据的全栈关联。

3.3.1 传统编码 vs SmartEncoding

传统编码方式（如 OpenTelemetry）：

// 需要在代码中手动设置标签
span.SetTag("service.name", "order-service")
span.SetTag("service.instance", "order-service-6f8d9")
span.SetTag("k8s.pod.name", "order-service-6f8d9")
span.SetTag("k8s.namespace", "production")
span.SetTag("cloud.region", "cn-beijing")
// ... 需要设置十几个标签

问题：

• 每个服务都需要手动植入标签设置代码
• 标签数量多导致存储开销大（每个 Span 可能携带 20+ 标签）
• 跨团队统一标签命名规范困难

SmartEncoding 方式：

DeepFlow 将标签分为两类：

1. 通用标签（Common Tags）：存储在独立的「标签表」中，通过 tag_id 关联到观测数据
2. 观测数据（Metrics / Traces / Logs）：只存储 tag_id，不存储标签的原始字符串

传统方式：
  Span {
    trace_id: "abc123",
    service_name: "order-service",  // 原始字符串，每个 Span 都存储
    pod_name: "order-service-6f8d9",
    namespace: "production",
    ...
  }

SmartEncoding 方式：
  标签表：
    tag_id: 1001 → service_name: "order-service", pod_name: "order-service-6f8d9", ...
  
  Span {
    trace_id: "abc123",
    tag_id: 1001  // 只存储一个整数
  }

效果：存储开销降低 70%，查询速度提升 5 倍。

3.3.2 SmartEncoding 实战配置

DeepFlow 通过「标签脚本（Tag Script）」定义标签的提取规则：

# deepflow-tag-script.py
# 定义如何从观测数据中提取标签

# 从 Kubernetes Pod 名称中提取服务名称
# Pod 名称格式：order-service-6f8d9 → 服务名称：order-service
def extract_service_name(pod_name):
    parts = pod_name.rsplit('-', 1)
    if len(parts) == 2 and len(parts[1]) == 5:
        return parts[0]
    return pod_name

# 从 HTTP Header 中提取 request_id
def extract_request_id(http_headers):
    return http_headers.get('X-Request-ID', '')

# 注册标签提取函数
register_tag('service_name', extract_service_name, source='pod_name')
register_tag('request_id', extract_request_id, source='http_header')

3.4 生产环境部署实战

3.4.1 前置要求

• Kubernetes 1.18+ 集群
• 节点内核版本 ≥ 4.14（推荐 ≥ 5.10 以获得完整 eBPF 特性）
• 节点架构：x86_64 或 ARM64
• 每个节点预留 1 vCPU / 2GB RAM 给 DeepFlow Agent

3.4.2 使用 Helm 部署 DeepFlow

# 添加 DeepFlow Helm 仓库
helm repo add deepflow https://deepflowio.github.io/deepflow
helm repo update

# 创建命名空间
kubectl create namespace deepflow

# 下载并自定义 values.yaml
helm show values deepflow/deepflow -n deepflow > values.yaml

# 关键配置项（values.yaml）
cat <<EOF > values.yaml
deepflowServer:
  # DeepFlow Server 副本数（生产环境推荐 3）
  replicaCount: 3
  
  # 服务类型（LoadBalancer 或 NodePort）
  service:
    type: LoadBalancer
  
  # ClickHouse 配置（观测数据存储）
  clickhouse:
    enabled: true
    replicas: 2
    persistence:
      size: 500Gi
  
  # MySQL 配置（元数据存
  mysql:
    enabled: true
    mysqlPassword: "your-secure-password"
    persistence:
      size: 100Gi

deepflowAgent:
  # Agent 以 DaemonSet 形式运行在每个节点
  daemonSet:
    # 是否允许在 Master 节点上运行
    tolerations:
      - operator: Exists
  
  # eBPF 配置
  ebpf:
    # 是否采集 HTTP 请求体（开启会显著增加开销）
    collect_request_body: false
    
    # 是否采集响应体
    collect_response_body: false
    
    # 最大并发追踪的请求数（根据节点负载调整）
    max_concurrent_requests: 10000
  
  # 协议解码配置
  l7Protocols:
    - HTTP
    - gRPC
    - MySQL
    - Redis
    - Kafka
EOF

# 部署 DeepFlow
helm install deepflow deepflow/deepflow -n deepflow -f values.yaml

# 验证部署状态
kubectl get pods -n deepflow
# 预期输出：
# NAME                                 READY   STATUS    RESTARTS   AGE
# deepflow-server-6f8d9c7b9-abc12     1/1     Running   0          2m
# deepflow-server-6f8d9c7b9-def34     1/1     Running   0          2m
# deepflow-server-6f8d9c7b9-ghi56     1/1     Running   0          2m
# deepflow-agent-xyz12                 1/1     Running   0          2m
# deepflow-agent-abc34                 1/1     Running   0          2m
# deepflow-clickhouse-0                1/1     Running   0          2m
# deepflow-clickhouse-1                1/1     Running   0          2m
# deepflow-mysql-0                     1/1     Running   0          2m

3.4.3 访问 DeepFlow Web UI

# 获取 DeepFlow Server 的 LoadBalancer IP
kubectl get svc -n deepflow deepflow-server -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
# 输出示例：192.168.1.100

# 在浏览器中访问
# http://192.168.1.100:20416

登录后，可以在「观测」→「服务拓扑」中看到自动发现的服务调用关系。

3.4.4 配置 DeepFlow 输出到 Kafka（为 AutoMQ 集成做准备）

# 修改 DeepFlow Server 配置，添加 Kafka 输出
kubectl edit configmap deepflow-server -n deepflow

# 在配置中添加以下内容
cat <<EOF
[ingester]
  # 输出到 Kafka
  [[ingester.kafka]]
    enabled = true
    addr = "automq-kafka:9092"  # AutoMQ 的 Kafka 兼容地址
    topic = "deepflow-metrics"
    
  [[ingester.kafka]]
    enabled = true
    addr = "automq-kafka:9092"
    topic = "deepflow-traces"
    
  [[ingester.kafka]]
    enabled = true
    addr = "automq-kafka:9092"
    topic = "deepflow-logs"
EOF

# 重启 DeepFlow Server
kubectl rollout restart deployment deepflow-server -n deepflow

4. Cilium：eBPF 驱动的云原生网络

Cilium 是基于 eBPF 的云原生网络、安全和可观测性解决方案，也是 Kubernetes 生态中最流行的 CNI 插件之一。

4.1 Cilium 架构与 eBPF 数据平面

┌──────────────────────────────────────────────────────────────────┐
│                      Kubernetes 集群                              │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │                  Cilium Agent (每个节点)                     │  │
│  │  • 监听 Kubernetes API（感知 Service / Endpoint 变化）      │  │
│  │  • 生成 eBPF 程序（服务负载均衡、网络策略、流量观测）       │  │
│  │  • 将 eBPF 程序加载到内核                                  │  │
│  └────────────────────────┬───────────────────────────────────┘  │
│                           │                                     │
│  ┌────────────────────────▼───────────────────────────────────┐  │
│  │                  eBPF 数据平面（内核）                       │  │
│  │                                                             │  │
│  │  ┌──────────────────────────────────────────────────────┐   │  │
│  │  │  XDP / TC eBPF 程序                                  │   │  │
│  │  │  • 服务负载均衡（替代 kube-proxy）                    │   │  │
│  │  │  • 网络策略执行（L3-L7）                              │   │  │
│  │  │  • 流量观测（Hubble 可观测性）                        │   │  │
│  │  └──────────────────────────────────────────────────────┘   │  │
│  │                                                             │  │
│  └─────────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │                  Cilium Operator                            │  │
│  │  • 管理 ClusterMesh（多集群互联）                          │  │
│  │  • 管理 Cilium Network Policy                             │  │
│  └────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

核心优势：Cilium 使用 eBPF 替代了传统的 iptables（kube-proxy 使用 iptables 做服务负载均衡），性能提升显著：

4.2 Hubble 可观测性实战

Hubble 是 Cilium 内置的可观测性组件，基于 eBPF 实现网络流量的实时监控。

4.2.1 启用 Hubble

# 使用 Cilium CLI 安装 Cilium（启用 Hubble）
cilium install \
  --version 1.16.0 \
  --set kubeProxyReplacement=strict \  # 完全替代 kube-proxy
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# 验证安装
cilium status --wait

# 输出示例：
#    /¯¯\
# /¯/_/  \    Cilium:  OK
# \_¯¯\_/    Kubernetes:  OK
# /¯¯\_/_/  Hubble:  OK
# \_¯¯\_/
# 
# Deployment    hubble-relay    Desired: 1, Ready: 1/1, Available: 1/1
# Deployment    hubble-ui       Desired: 1, Ready: 1/1, Available: 1/1

4.2.2 使用 Hubble CLI 观察流量

# 启用 Hubble 端口转发
kubectl port-forward -n kube-system svc/hubble-relay 4245:80 &

# 观察所有命名空间中的 HTTP 流量
hubble observe --type http --all-namespaces

# 输出示例：
# Jun 20 05:30:12.123  [http]  order-service-6f8d9:8080 -> mysql-0:3306  policy-verdict: allowed  http-method: GET  http-url: /api/orders/123  http-status: 200  latency: 2.5ms
# Jun 20 05:30:13.456  [http]  frontend-abc12:3000 -> order-service-6f8d9:8080  policy-verdict: allowed  http-method: POST  http-url: /api/orders  http-status: 201  latency: 15.3ms

4.2.3 Hubble UI 可视化

# 端口转发 Hubble UI
kubectl port-forward -n kube-system svc/hubble-ui 12000:80 &

# 在浏览器中访问
# http://localhost:12000

Hubble UI 提供：

• 实时的服务拓扑图
• 每个请求的详细信息（延迟、状态码、重试次数）
• 网络策略的决策日志（允许/拒绝）

4.2.4 将 Hubble 数据导出到 DeepFlow

Hubble 和 DeepFlow 可以互补：Hubble 提供 L3-L7 的网络观测，DeepFlow 提供应用层的完整可观测性。

# 配置 Hubble 导出数据到 Kafka（供 DeepFlow 消费）
apiVersion: cilium.io/v1alpha1
kind: CiliumClusterConfig
metadata:
  name: default
spec:
  hubble:
    export:
      - name: kafka
        kafka:
          brokers:
            - automq-kafka:9092
          topic: hubble-events
          # 导出 Hubble 的 Flow 事件（包含网络层的观测数据）
          flow:
            enabled: true
            fieldMask:
              - time
              - source
              - destination
              - l4
              - l7

4.3 Cilium 网络策略与安全检查

Cilium 支持 L3-L7 的网络策略，基于 eBPF 实现高性能的策略执行。

4.3.1 L3/L4 网络策略（基于 IP 和端口）

# 只允许 frontend 访问 order-service 的 8080 端口
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: order-service-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

4.3.2 L7 网络策略（基于应用层协议）

# 只允许访问 order-service 的 GET /api/orders/* 路径
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: order-service-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/orders/.*"
              - method: "POST"
                path: "/api/orders"
                # 可以基于 HTTP Header 做策略决策
                headers:
                  - "X-API-Version: 2026-06-01"

4.3.3 使用 eBPF LSM（Linux Security Module）实现运行时安全

Cilium 1.12+ 支持基于 eBPF LSM 的运行时安全策略：

# 禁止 order-service 的容器执行 /bin/sh（防止反弹 Shell）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: runtime-security
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  lsm:
    - action: Deny
      # 禁止执行特定二进制
      exec:
        path: "/bin/sh"
    - action: Deny
      # 禁止修改 /etc/passwd
      filesystem:
        path: "/etc/passwd"
        permissions:
          - write

5. AutoMQ：Kafka 存储卸载到对象存储

AutoMQ 是一款 Kafka 协议兼容的消息队列，其核心创新是将存储卸载到对象存储（S3 / OSS / OBS），大幅降低存储成本。

5.1 AutoMQ 架构原理

传统 Kafka 架构：
┌─────────────────────────────────────────────────────────┐
│  Kafka Broker                                           │
│  • 消息写入本地磁盘（挂载云盘，成本高）                   │
│  • 副本同步（Replication）产生跨可用区流量费             │
│  • 扩容需要重新平衡分区（Rebalance），耗时长             │
└─────────────────────────────────────────────────────────┘

AutoMQ 架构：
┌─────────────────────────────────────────────────────────┐
│  AutoMQ Broker                                          │
│  • 消息写入内存（PageCache）                             │
│  • 异步上传到对象存储（S3）                             │
│  • 无状态 Broker（可以快速扩缩容）                      │
│  • 副本同步通过 S3 实现（无跨可用区流量费）              │
└───────────────────┬─────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────────────┐
│  对象存储（S3 / OSS / OBS）                              │
│  • 存储成本：$0.023/GB/月（S3 Standard）                │
│  • Kafka 本地磁盘：$0.10/GB/月（EBS gp3）               │
│  • 成本降低：77%                                         │
└─────────────────────────────────────────────────────────┘

5.2 AutoMQ 与 eBPF 数据采集的集成

DeepFlow Agent 采集的观测数据可以通过 Kafka 协议发送到 AutoMQ，再由 AutoMQ 传输到 GreptimeDB。

5.2.1 部署 AutoMQ 集群

# 下载 AutoMQ
wget https://github.com/AutoMQ/automq/releases/download/1.0.0/automq-1.0.0.tgz
tar -xzf automq-1.0.0.tgz
cd automq

# 修改配置文件（config/server.properties）
cat <<EOF
# S3 存储配置
s3.enabled=true
s3.bucket=your-bucket-name
s3.region=cn-beijing
s3.access.key=your-access-key
s3.secret.key=your-secret-key

# Kafka 协议配置（保持与 Kafka 完全一致）
listeners=PLAINTEXT://:9092
log.dirs=/tmp/automq-metadata
EOF

# 启动 AutoMQ Broker（3 节点集群）
./bin/automq-server-start.sh -daemon config/server.properties

# 创建 DeepFlow 数据主题
./bin/kafka-topics.sh --create \
  --topic deepflow-metrics \
  --partitions 12 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

./bin/kafka-topics.sh --create \
  --topic deepflow-traces \
  --partitions 12 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

./bin/kafka-topics.sh --create \
  --topic deepflow-logs \
  --partitions 12 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

5.2.2 配置 DeepFlow 输出到 AutoMQ

参考 3.4.4 节的配置，将 DeepFlow 的 Kafka 输出地址指向 AutoMQ 集群。

6. GreptimeDB：可观测性 2.0 数据库

GreptimeDB 是一款云原生时序数据库，专为可观测性场景设计，统一存储 Metrics、Logs 和 Traces。

6.1 GreptimeDB 架构设计

┌──────────────────────────────────────────────────────────────────┐
│                      GreptimeDB 架构                             │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │                  Frontend（查询入口）                        │  │
│  │  • 支持 SQL（MySQL 协议兼容）                              │  │
│  │  • 支持 PromQL（Prometheus 查询语言）                      │  │
│  │  • 支持 OpenTSDB / InfluxDB 协议                           │  │
│  └────────────────────────┬───────────────────────────────────┘  │
│                           │                                     │
│  ┌────────────────────────▼───────────────────────────────────┐  │
│  │                  Datanode（存储与计算）                     │  │
│  │  • 存储引擎：基于 Apache Arrow 和 Parquet                  │  │
│  │  • 计算引擎：向量化执行（SIMD）                            │  │
│  │  • 索引：倒排索引（全文搜索）、B+ 树索引（范围查询）       │  │
│  └────────────────────────┬───────────────────────────────────┘  │
│                           │                                     │
│  ┌────────────────────────▼───────────────────────────────────┐  │
│  │                  对象存储（S3 / OSS）                        │  │
│  │  • 数据文件：Parquet 格式（高压缩比）                      │  │
│  │  • WAL（Write-Ahead Log）：确保数据不丢失                   │  │
│  └────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

核心创新：GreptimeDB 将 Metrics、Logs 和 Traces 统一为「宽事件（Wide Events）」模型：

-- Metrics 本质上是低维的宽事件
INSERT INTO metrics VALUES
  ('cpu_usage', 2026-06-20 05:30:00, 85.2, {'host'='node-1', 'dc'='bj'});

-- Logs 本质上是高维的宽事件
INSERT INTO logs VALUES
  (2026-06-20 05:30:00, 'order-service', 'ERROR', 'Database connection failed', {'trace_id'='abc123'});

-- Traces 本质上是嵌套的宽事件
INSERT INTO traces VALUES
  ('abc123', 2026-06-20 05:30:00, 'order-service', 'GET /api/orders', 2500, ...);

6.2 统一存储 Metrics / Logs / Traces

6.2.1 使用 SQL 查询三种信号

-- 查询 P99 延迟大于 1 秒的服务（Metrics + Traces 关联查询）
SELECT 
    m.service_name,
    m.p99_latency,
    COUNT(t.trace_id) AS slow_requests
FROM metrics m
LEFT JOIN traces t ON m.service_name = t.service_name 
                  AND m.timestamp = t.timestamp
WHERE m.p99_latency > 1000  -- 大于 1 秒
  AND t.duration > 1000
  AND m.timestamp > NOW() - INTERVAL 1 HOUR
GROUP BY m.service_name, m.p99_latency;

-- 查询包含错误的日志，并关联到对应的 Trace
SELECT 
    l.timestamp,
    l.service_name,
    l.log_level,
    l.message,
    t.trace_id,
    t.span_id
FROM logs l
LEFT JOIN traces t ON l.trace_id = t.trace_id
WHERE l.log_level = 'ERROR'
  AND l.timestamp > NOW() - INTERVAL 15 MINUTE
ORDER BY l.timestamp DESC;

6.2.2 使用 PromQL 查询 Metrics

# GreptimeDB 兼容 PromQL
# 查询 order-service 的 QPS（每秒请求数）
rate(http_requests_total{service="order-service"}[5m])

# 查询所有服务的 P99 延迟
histogram_quantile(0.99, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (service, le)
)

6.3 基于对象存储的低成本存储

GreptimeDB 将所有数据存储在对象存储（S3 / OSS）中，成本对比：

关键优化：

• 使用 Parquet 列式存储格式，压缩比可达 10:1
• 使用 Apache Arrow 做向量化计算，查询速度提升 5 倍
• 无状态计算节点，可以按需伸缩

7. 完整流水线搭建实战

7.1 环境准备与架构规划

假设我们有一个 6 节点的 Kubernetes 集群：

7.2 DeepFlow 部署与 eBPF 采集配置

参考 3.4.2 节完成 DeepFlow 部署。

额外配置：开启「全栈持续剖析」功能：

# 修改 DeepFlow Agent 配置
kubectl edit configmap deepflow-agent -n deepflow

# 添加以下配置
cat <<EOF
[agent]
  # 开启 OnCPU 持续剖析
  profile_on_cpu_enabled = true
  profile_on_cpu_sample_rate = 99  # 每秒 99 次采样
  
  # 开启 OffCPU 持续剖析
  profile_off_cpu_enabled = true
  profile_off_cpu_sample_rate = 99
  
  # 持续剖析数据上报间隔
  profile_report_interval = 60  # 每 60 秒上报一次
EOF

# 重启 Agent
kubectl rollout restart daemonset deepflow-agent -n deepflow

7.3 AutoMQ 集群部署

在 Kubernetes 中部署 AutoMQ：

# automq-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: automq
  namespace: kafka
spec:
  serviceName: automq
  replicas: 3
  selector:
    matchLabels:
      app: automq
  template:
    metadata:
      labels:
        app: automq
    spec:
      containers:
      - name: automq
        image: automq/automq:1.0.0
        ports:
        - containerPort: 9092
          name: kafka
        env:
        - name: S3_ENABLED
          value: "true"
        - name: S3_BUCKET
          value: "your-bucket-name"
        - name: S3_REGION
          value: "cn-beijing"
        - name: S3_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              name: s3-credentials
              key: access-key
        - name: S3_SECRET_KEY
          valueFrom:
            secretKeyRef:
              name: s3-credentials
              key: secret-key
        volumeMounts:
        - name: metadata
          mountPath: /tmp/automq-metadata
      volumes:
      - name: metadata
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: automq
  namespace: kafka
spec:
  ports:
  - port: 9092
    name: kafka
  clusterIP: None
  selector:
    app: automq

kubectl apply -f automq-statefulset.yaml

# 验证 AutoMQ 集群状态
kubectl exec -it automq-0 -n kafka -- \
  ./bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092

7.4 GreptimeDB 部署与数据接入

使用 Helm 部署 GreptimeDB：

# 添加 GreptimeDB Helm 仓库
helm repo add greptimedb https://greptimedb.github.io/helm-charts
helm repo update

# 创建命名空间
kubectl create namespace greptimedb

# 部署 GreptimeDB
helm install greptimedb greptimedb/greptimedb \
  -n greptimedb \
  --set replicationFactor=2 \
  --set storage.s3.bucket="your-bucket-name" \
  --set storage.s3.region="cn-beijing" \
  --set storage.s3.accessKey="your-access-key" \
  --set storage.s3.secretKey="your-secret-key"

# 验证部署
kubectl get pods -n greptimedb

配置 GreptimeDB 从 AutoMQ 消费数据：

# greptimedb-pipeline.yaml
# 定义从 Kafka (AutoMQ) 消费数据并写入 GreptimeDB 的流水线

apiVersion: v1
kind: ConfigMap
metadata:
  name: greptimedb-pipeline
  namespace: greptimedb
data:
  pipeline.yaml: |
    # 消费 DeepFlow Metrics
    - name: deepflow-metrics
      input:
        type: kafka
        brokers:
          - automq.kafka:9092
        topic: deepflow-metrics
        consumerGroup: greptimedb-metrics
      
      transform:
        # 将 DeepFlow 的 Metrics 格式转换为 GreptimeDB 格式
        - type: field_extractor
          fields:
            - name: metric_name
              pattern: '^(?P<metric_name>[^:]+):'
            - name: metric_value
              pattern: 'value=(?P<metric_value>[0-9.]+)'
        
        - type: timestamp_parser
          field: timestamp
          formats:
            - unix_ms
      
      output:
        type: greptimedb
        table: deepflow_metrics
        tags:
          - service
          - instance
          - endpoint
        fields:
          - metric_name
          - metric_value
        timestamp: timestamp
    
    # 消费 DeepFlow Traces
    - name: deepflow-traces
      input:
        type: kafka
        brokers:
          - automq.kafka:9092
        topic: deepflow-traces
        consumerGroup: greptimedb-traces
      
      output:
        type: greptimedb
        table: deepflow_traces
        tags:
          - trace_id
          - span_id
          - service_name
        fields:
          - operation_name
          - duration
          - status_code
        timestamp: start_time

kubectl apply -f greptimedb-pipeline.yaml

# 重启 GreptimeDB 以加载配置
kubectl rollout restart statefulset greptimedb -n greptimedb

7.5 端到端验证

# 1. 生成测试流量
kubectl run -i --tty --rm load-generator --image=busybox --restart=Never -- \
  /bin/sh -c "while true; do wget -q -O- http://order-service:8080/api/orders; done"

# 2. 在 DeepFlow Web UI 中查看服务拓扑
# 访问 http://<deepflow-server-ip>:20416
# 导航到「观测」→「服务拓扑」

# 3. 在 GreptimeDB 中查询数据
kubectl port-forward -n greptimedb svc/greptimedb 4002:4002 &

# 使用 MySQL 客户端连接 GreptimeDB
mysql -h 127.0.0.1 -P 4002 -u root

# 在 MySQL 终端中执行查询
USE deepflow;

SHOW TABLES;

SELECT * FROM deepflow_metrics 
WHERE timestamp > NOW() - INTERVAL 5 MINUTE
LIMIT 10;

SELECT 
    service_name,
    operation_name,
    AVG(duration) AS avg_duration
FROM deepflow_traces
WHERE start_time > NOW() - INTERVAL 5 MINUTE
GROUP BY service_name, operation_name;

8. AI Agent 可观测闭环

8.1 AI Agent 可观测的特殊挑战

AI Agent（如 Claude Code、Codex、Cursor）的可观测性比传统应用更复杂：

1. 长上下文窗口：AI Agent 的上下文窗口可能包含数万 Token，需要追踪上下文的使用情况
2. 工具调用链：AI Agent 会调用多个工具（文件读写、Shell 执行、API 请求），需要追踪工具调用的链路
3. Token 消耗：每次 LLM 调用都消耗 Token，需要精确统计成本
4. 非确定性行为：相同输入可能产生不同输出，需要记录完整的决策过程

8.2 基于 eBPF 的 AI Agent 行为追踪

DeepFlow 可以自动追踪 AI Agent 的所有网络请求（包括调用 LLM API 的 HTTP 请求）：

# 在 DeepFlow Web UI 中筛选 AI Agent 的流量
# 服务 = "claude-code"  OR  服务 = "codex"

# 查看 Claude Code 调用 Anthropic API 的详细信息
# 自动解码 HTTPS 流量（通过 eBPF 在内核中捕获明文）

# 示例输出：
# [2026-06-20 05:30:00] Claude Code → api.anthropic.com
#   Method: POST
#   Path: /v1/messages
#   Request Body:
#     model: claude-3-5-sonnet-20241022
#     max_tokens: 4096
#     messages: [...]
#   Response:
#     usage:
#       input_tokens: 15000
#       output_tokens: 500
#   Latency: 3.2 seconds
#   Cost: $0.15

8.3 LLM 智能分析与自动诊断

将 GreptimeDB 中存储的观测数据接入 LLM，实现智能分析：

# ai-agent-observability.py
# 使用 LLM 自动分析 AI Agent 的性能瓶颈

import openai
import greptime_db_client as gdb

# 连接到 GreptimeDB
client = gdb.GreptimeDBClient(host='greptimedb:4002', database='deepflow')

def analyze_agent_performance(agent_name, time_range):
    """分析 AI Agent 的性能问题"""
    
    # 1. 从 GreptimeDB 查询观测数据
    query = f"""
    SELECT 
        timestamp,
        service_name,
        operation_name,
        duration,
        token_usage
    FROM deepflow_traces
    WHERE service_name = '{agent_name}'
      AND timestamp BETWEEN '{time_range[0]}' AND '{time_range[1]}'
    ORDER BY timestamp
    """
    
    traces = client.query(query)
    
    # 2. 将观测数据发送给 LLM 进行分析
    prompt = f"""
    分析以下 AI Agent 的追踪数据，找出性能瓶颈和优化建议：
    
    {traces}
    
    请重点关注：
    1. Token 消耗最高的操作
    2. 延迟最高的工具调用
    3. 可能的上下文溢出问题
    4. 工具调用失败的模式
    """
    
    response = openai.chat.completions.create(
        model="claude-3-5-sonnet-20241022",
        messages=[
            {"role": "system", "content": "你是一个可观测性专家，擅长分析 AI Agent 的性能问题。"},
            {"role": "user", "content": prompt}
        ]
    )
    
    analysis = response.choices[0].message.content
    
    # 3. 将分析结果存储回 GreptimeDB
    client.insert(
        table="ai_agent_analysis",
        data={
            "timestamp": datetime.now(),
            "agent_name": agent_name,
            "analysis": analysis,
            "token_cost": response.usage.total_tokens
        }
    )
    
    return analysis

# 使用示例
analysis = analyze_agent_performance(
    agent_name="claude-code",
    time_range=("2026-06-20 05:00:00", "2026-06-20 06:00:00")
)

print(analysis)

9. 性能优化与生产最佳实践

9.1 eBPF 程序性能调优

9.1.1 减少 eBPF Map 查找次数

// 不优化：每次都需要查找 Map
SEC("kprobe/tcp_sendmsg")
int trace_v1(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    
    // 每次都查找
    struct proc_info *info = bpf_map_lookup_elem(&proc_map, &pid);
    if (!info) return 0;
    
    // 使用 info
    return 0;
}

// 优化后：使用 per-CPU Map 缓存
SEC("kprobe/tcp_sendmsg")
int trace_v2(struct pt_regs *ctx) {
    // per-CPU Map 无需锁，性能更高
    struct proc_info *info = bpf_map_lookup_elem(&percpu_proc_map, &cpu_id);
    // ...
}

9.1.2 使用 Ring Buffer 替代 Perf Event Array

// 不推荐：Perf Event Array（每个事件都需要一次内存拷贝）
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));

// 推荐：Ring Buffer（零拷贝）
void *rb = bpf_ringbuf_reserve(&events, sizeof(event), 0);
if (rb) {
    // 直接写入 Ring Buffer
    memcpy(rb, &event, sizeof(event));
    bpf_ringbuf_submit(rb, 0);
}

9.2 DeepFlow 数据采样与存储优化

对于高流量场景（QPS > 10000），建议开启采样以避免存储过载：

# deepflow-sampling-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: deepflow-agent-config
  namespace: deepflow
data:
  agent.yaml: |
    # 智能采样：只采集异常请求（延迟 > P99 或状态码 >= 400）
    sampling:
      enabled: true
      policy: intelligent
      
      # 或者固定采样率（10% 采样）
      # policy: random
      # rate: 0.1
      
    # 限制每个 Agent 的上报速率
    max_upload_rate: 10000  # 每秒最多上报 10000 条 Span
    
    # 压缩上报数据（使用 LZ4 压缩算法）
    compression: lz4

9.3 GreptimeDB 查询与压缩策略

-- 创建分级压缩策略
-- 热数据（最近 1 天）：不压缩，快速查询
-- 温数据（1 天 ~ 7 天）：LZ4 压缩
-- 冷数据（> 7 天）：Zstd 压缩，归档到 S3 Glacier

-- 创建压缩策略
ALTER TABLE deepflow_metrics SET (
    'compression' = 'LZ4',
    'ttl' = '30 days',  -- 自动删除 30 天前的数据
    'index.type' = 'INVERTED'  -- 使用倒排索引加速标签查询
);

-- 创建物化视图（预聚合常用查询）
CREATE MATERIALIZED VIEW IF NOT EXISTS mv_service_p99 AS
SELECT
    service_name,
    date_trunc('minute', timestamp) AS time_bucket,
    quantile(0.99)(duration) AS p99_latency
FROM deepflow_traces
GROUP BY service_name, time_bucket;

10. 总结与展望

10.1 本文技术栈的价值

10.2 eBPF 技术的未来方向

1. eBPF 在 Windows 上的支持：Microsoft 正在开发 Windows eBPF（github.com/microsoft/ebpf-for-windows），未来可以实现跨平台的可观测性
2. eBPF 与 Wasm（WebAssembly）的结合：使用 Wasm 编写 eBPF 程序，更安全、更便携
3. eBPF 在边缘计算中的应用：在资源受限的边缘设备上，eBPF 的轻量级特性非常有
   （完）