运维监控与可观测 - 公有云AI技术文章封面

eBPF 可观测性实战：零侵入式的云原生应用监控，比传统方案强在哪？

作者

阿里云上云采购季 2核2G云服务器99元/年 续费同价

不改一行代码，不装一个 Agent，看透你的 K8s 集群里所有网络调用和系统调用。

做了 5 年运维，我对「监控」这件事有两个刻骨的领悟：

  1. 没人愿意给应用加监控代码。开发说「功能还没写完，哪有时间埋点」
  2. Agent 装多了服务器扛不住。Prometheus、Filebeat、APM Agent 一装，20% 资源先拿去跑监控。

直到我发现 eBPF——它让我在不碰应用代码、不装额外 Agent 的情况下，直接从内核层面拿到「上帝视角」。

eBPF 到底强在哪？

传统的可观测性方案是这样的：

应用代码埋点 → SDK/Agent 上报 → 后端存储 → 可视化
     ↑                      ↑
   侵入应用              消耗资源

eBPF 的方案是这样的：

Linux 内核 ↔ eBPF 程序（挂载在 kprobe/tracepoint/网络事件上）
                    ↓
              用户态采集器（如 Cilium/Pixie）
                    ↓
              Prometheus/Grafana

核心区别：eBPF 运行在内核态，不碰用户态代码。

维度 传统方案 eBPF 方案
对应用的侵入性 需要 SDK/Agent 零侵入
性能开销 5-15% CPU 1-3% CPU
覆盖范围 埋点了才有 100% 覆盖
部署复杂度 每个应用单独配置 一次部署全集群生效
数据粒度 取决于埋点密度 系统调用级粒度
支持语言 每种语言单独 SDK 语言无关

实战一：用 bpftrace 5 分钟定位性能瓶颈

bpftrace 是 eBPF 的「瑞士军刀」——不需要编译，写一行脚本就能追踪内核事件。

# 安装 bpftrace (Ubuntu/Debian)
sudo apt install bpftrace

# 追踪某个进程的所有系统调用（替换 12345 为 PID）
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_* /pid == 12345/ { 
    printf("%s\n", probe); 
}'

# 统计进程的系统调用耗时 TOP 10
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_* /pid == 12345/ {
    @start[tid] = nsecs;
    @name[tid] = probe;
}
tracepoint:syscalls:sys_exit_* /pid == 12345 && @start[tid]/ {
    $duration = (nsecs - @start[tid]) / 1000000;
    @latency_ms[@name[tid]] = hist($duration);
    delete(@start[tid]);
}
END {
    clear(@start);
    clear(@name);
}
'

# 追踪所有 TCP 连接（看谁在连你的服务）
sudo bpftrace -e '
kprobe:tcp_connect {
    $sk = (struct sock *)arg0;
    printf("进程 %s (PID=%d) 正在连接...\n", comm, pid);
}
'

实战二：Pixie —— K8s 原生零侵入监控

Pixie 是 New Relic 开源的 eBPF 监控平台，专为 Kubernetes 设计。一条命令部署，立刻看到所有 Pod 的网络流量、SQL 调用、HTTP 请求。

# 部署 Pixie 到 K8s 集群
# 第一步：安装 pixie CLI
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"

# 第二步：部署到集群
px deploy

# 第三步：查看集群状态
px get clusters

# 第四步：用 PxL 脚本查询数据
px run px/service_stats

# PxL 脚本示例：查看某个 Pod 的 HTTP 请求延迟
# 保存为 http_latency.pxl

import px

# 统计每个 endpoint 的 P50/P95/P99 延迟
df = px.DataFrame(table='http_events', start_time='-5m')

df = df.groupby(['req_path', 'resp_status']).agg(
    request_count=('latency', px.count),
    p50_latency_ms=('latency', px.quantile(0.50)),
    p95_latency_ms=('latency', px.quantile(0.95)),
    p99_latency_ms=('latency', px.quantile(0.99)),
)

df = df[df.request_count > 10]  # 过滤低频请求
px.display(df.sort_values('p95_latency_ms', ascending=False))

# 命令行执行 PxL 脚本
px run -f http_latency.pxl

实战三：用 Cilium Hubble 看透 K8s 网络

Cilium 是 K8s 的网络插件，它内置的 Hubble 组件能用 eBPF 画出服务间的调用拓扑图。

# 安装 Cilium + Hubble（使用 Helm）
helm repo add cilium https://helm.cilium.io/
helm upgrade --install cilium cilium/cilium \
    --namespace kube-system \
    --set hubble.relay.enabled=true \
    --set hubble.ui.enabled=true

# 启动 Hubble CLI
cilium hubble port-forward &

# 查看实时服务拓扑图
hubble observe --namespace default

# 查看某个 Pod 的网络流量（带 HTTP 详情）
hubble observe --from-pod myapp/nginx-abc123 --protocol http

# 过滤 HTTP 5xx 错误
hubble observe --http-status 500-599 --namespace production

# 查看被拒绝的网络连接（NetworkPolicy 效果验证）
hubble observe --verdict DROPPED

# 验证 NetworkPolicy 效果
# deny-all.yaml - 默认拒绝所有入站流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
# allow-frontend.yaml - 只允许 frontend 访问 backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

eBPF vs 传统方案：成本对比

以一个有 50 个微服务的 K8s 集群为例：

项目 传统方案（APM Agent） eBPF 方案（Pixie+Hubble）
部署 Agent 数量 50 个 Sidecar/Agent 0 个
额外 CPU 消耗 ~8 Core（15%） ~2 Core（3%）
额外内存消耗 ~16 GB ~4 GB
应用代码改动 每个服务加 SDK 零改动
覆盖的服务 装了 Agent 的 所有 Pod 自动覆盖
开发接入时间 每服务 2-4 小时 0 小时
月度云成本增量 ~¥3,500 ~¥800

对中小团队来说，eBPF 方案每年能省 3 万以上的云资源费用，还能减少开发团队的接入负担。

3 个注意事项

  1. 内核版本要求：eBPF 需要 Linux 4.9+，但推荐 5.4+。一些老旧的 CentOS 7（内核 3.10）不支持，需要先升级内核或迁移到较新的发行版。

  2. 安全考虑：eBPF 程序运行在内核态，权限极高。务必审查 eBPF 程序来源，不要随意加载未经验证的 eBPF 程序。Cilium/Pixie 这些知名项目可以放心用。

  3. 不是万能药：eBPF 擅长网络、系统调用、文件 I/O 层面的观测，但对于应用层的业务指标（如订单转化率），你还是需要埋点。eBPF 是底线监控，业务指标做顶层监控，两者互补。

👤 作者简介

一枚在大中原腹地（河南）卖公有云的从业者，主营腾讯云/阿里云/火山云，曾踩坑无数，现专注AI大模型应用落地。关注公众号「公有云cloud」，围观AI前沿动态~

博客：y1cloud.cn

发表评论