网络可观测性（Network Observability）是可观测性工程中最靠近基础设施、却又越来越靠近业务语义的一个方向。传统运维视角下的网络监控，关注的是带宽、丢包、重传、路由这些链路层与传输层指标；而微服务时代的网络可观测性，更多是回答这样的问题：
要回答这些问题，单纯靠应用内埋点（即 APM）是不够的，因为很多问题根本不在应用的代码路径上；而只看传统的 SNMP、NetFlow 也不够，因为它们看不到 L7 协议语义，也看不到 Kubernetes 的容器上下文。
扩展可编程内核的伯克利包过滤器（eBPF，extended Berkeley Packet Filter）技术的成熟，使得”在内核中直接捕获网络事件、在采集点注入容器元数据、在用户态做 L7 协议解析”这条路径变得工程化可行。本文围绕这条主线，依次讲解：
网络可观测性必须分层来看。每一层能回答的问题不同，采集成本、实现难度也不同。
按照开放系统互连（OSI，Open Systems Interconnection）模型，网络可观测性一般聚焦三层：
三者并不是彼此替代的关系，而是互相补充。一个 5xx 错误爆发时，L7 指标会告诉你”哪个接口、哪个客户端、错误码是多少”，L4 指标会告诉你”是不是背后有大量连接被 RST 掉了”，L3 指标会告诉你”底层有没有物理丢包或路由黑洞”。
单体架构时代，一次用户请求的路径基本就是：浏览器 → 负载均衡（LB）→ 应用服务器 → 数据库。监控这四个节点就基本看清了全貌。
微服务架构下，一次用户请求可能涉及几十次内部调用，调用之间通过 HTTP/gRPC/消息队列（MQ，Message Queue）串联。此时：
所以，L7 网络可观测性填补的恰恰是 APM 埋点覆盖不到的盲区：无侵入、面向东西向流量、以”网络行为”为第一视角来看服务间交互。
下面这张表是一个粗略的能力对比。
| 能力 | L3（IP） | L4（TCP/UDP） | L7（应用） |
|---|---|---|---|
| 网络是否通 | 是 | 是 | 间接 |
| 是否丢包 / 重传 | 有限 | 是 | 否 |
| 建连耗时 | 否 | 是 | 间接 |
| 请求耗时（应用视角） | 否 | 近似 | 是 |
| 错误码 / 业务错误 | 否 | 否 | 是 |
| 区分用户、租户、接口 | 否 | 否 | 是 |
| 成本（CPU/存储） | 低 | 中 | 高 |
| 是否需要协议解析 | 否 | 否 | 是 |
| 能否反映 TLS 内的细节 | 否 | 否 | 是（需要解密） |
传统网络监控的数据来源包括：
这些方案的共性局限：
基于 eBPF 的方案则具备：
sched_process_exec、cgroup
相关钩子，可以在事件源头就带上容器元数据。这是本文所有工具的共同技术底座。
不同工具采用的 eBPF Hook 点差别不小，理解这些 Hook 点的语义，是看懂工具架构的前提。
套接字过滤器是最古老的 BPF 程序类型之一。程序被挂到一个套接字（socket）上，内核会把该 socket 上收到的数据包拷贝一份传给程序，程序返回保留多少字节（0 表示丢弃该副本）。
特点：
典型使用者：tcpdump（libpcap 会生成 cBPF
程序）、BCC 工具链里的一些抓包脚本。
/* 伪代码：一个最朴素的 socket filter，保留所有 TCP 报文 */
SEC("socket")
int sk_filter_prog(struct __sk_buff *skb) {
if (skb->protocol != __constant_htons(ETH_P_IP))
return 0;
__u8 proto = load_byte(skb, ETH_HLEN + offsetof(struct iphdr, protocol));
if (proto != IPPROTO_TCP)
return 0;
return -1; /* -1 表示全部保留 */
}在网络可观测性产品中，socket filter 通常不是主力，因为它的副本开销在高吞吐场景偏大。
Linux 流量控制（Traffic Control，简称 TC）子系统提供了
clsact 这个特殊 qdisc，允许把 eBPF
程序分别挂到入向（ingress）和出向（egress）。
特点：
Cilium 对 TC Hook 的使用最为激进：策略执行、服务负载均衡、可观测性采集都通过 TC 程序实现。Cilium Hubble 的流日志，主力来源就是挂在 TC ingress/egress 上的程序。
SEC("tc")
int tc_ingress(struct __sk_buff *skb) {
struct flow_key key = {};
parse_l3_l4(skb, &key);
struct flow_stats *st = bpf_map_lookup_elem(&flow_map, &key);
if (!st) {
struct flow_stats zero = {};
bpf_map_update_elem(&flow_map, &key, &zero, BPF_ANY);
st = bpf_map_lookup_elem(&flow_map, &key);
}
if (st) {
__sync_fetch_and_add(&st->rx_packets, 1);
__sync_fetch_and_add(&st->rx_bytes, skb->len);
}
return TC_ACT_OK;
}XDP 是 Linux 网络栈中最早的可编程点，挂在网卡驱动（甚至网卡硬件，如部分 Mellanox 网卡）上。
特点：
sk_buff
之前就判断是否要丢弃，单核 PPS 可达数千万量级。因此 XDP 并不适合直接用来做 L7 可观测性，但它可以承担：
Cilium 在 XDP 层做过负载均衡加速；Tetragon、Hubble 在可观测路径上主要还是靠 TC 与 kprobe。
kprobe 允许在任意内核函数入口/返回处挂探针。网络可观测性里常用的几个：
tcp_sendmsg /
tcp_recvmsg：采集应用写入/读取 TCP
缓冲区的大小、所处进程上下文。tcp_close：连接关闭时计算连接总时长、重传计数。sk_data_ready：有数据到来时触发，可以关联到具体
socket。inet_csk_accept：TCP accept
完成时，采集服务端新连接信息。kfree_skb：内核丢包入口，用于精细化分析丢包原因（通过
kfree_skb_reason，Linux 5.17+）。kprobe 的优点是灵活：没有 TC 程序那么严格的限制，能直接拿到内核结构体字段。缺点是与内核版本强绑定，函数签名或内部结构变动会打破程序。
一站式编译一次到处运行（CO-RE，Compile Once – Run Everywhere）和 BPF 类型格式（BTF，BPF Type Format）缓解了这个问题，Hubble 和 DeepFlow 都以 CO-RE 方式分发 eBPF 程序。
应用层流量越来越多使用传输层安全协议（TLS，Transport Layer Security）加密。从 TC/socket filter 这种”网卡之后、应用之前”的位置看，拿到的是密文，无法解析 HTTP 等应用协议。
解决思路是在用户态库里挂 uprobe：
SSL_read /
SSL_write，入口拿到缓冲区指针，返回时缓冲区中是明文。crypto/tls：Go
将 TLS 实现自带，因此需要对 Go 二进制里的
crypto/tls.(*Conn).Read、crypto/tls.(*Conn).Write
做 uprobe；由于 Go 的栈布局与 ABI 与 C 不同，还需要特殊的
uretprobe 实现，详见 Pixie 的
go_tls_tracer。SSLEngine：Java
虚拟机（JVM，Java Virtual Machine）里的 TLS 由 JSSE
实现，可以挂到 sun.security.ssl.* 相关 JNI
符号，但覆盖面有限；实务中常配合字节码织入。这样在不拿到服务端私钥、不做中间人代理的前提下，就能在源进程与目的进程两端的用户态”明文位置”采集到 HTTP/gRPC 明文。DeepFlow、Pixie、Hubble 的 L7 TLS 解析都采用这条路径。
Cilium 是基于 eBPF 的 Kubernetes 容器网络接口（CNI，Container Network Interface）实现，Hubble 则是在 Cilium 之上构建的网络与安全可观测性层。
Cilium 的核心理念：
从可观测性视角看，Cilium 在每个 Pod 的 veth 上挂了 TC 程序，这些程序天然能看到每个数据包，且已经持有了”来自哪个 Pod、去往哪个 Pod”的身份信息。这是 Hubble 得以低成本生成 L3/L4/L7 流日志的基础。
Hubble 的组件从节点到集群呈三级结构：
hubble）：命令行工具，连接 Relay
或单节点 Daemon。+--------------+ +--------------+ +--------------+
| Hubble UI |<---->| Hubble Relay |<---->| Hubble Daemon| (node A)
+--------------+ | |<---->| Hubble Daemon| (node B)
^ +--------------+ +--------------+
| ^
| gRPC | eBPF Map
| |
hubble CLI ----------> Hubble Relay Cilium AgentHubble 的流事件由 flow.Flow Protobuf
定义，主要字段：
{
"time": "2026-04-22T09:12:31Z",
"verdict": "FORWARDED",
"source": {
"identity": 18432,
"namespace": "frontend",
"pod_name": "web-7c8f6d9f6b-abc12",
"labels": ["app=web", "version=v1"]
},
"destination": {
"identity": 24815,
"namespace": "order",
"pod_name": "order-svc-5f9c8d7b6-xyz34",
"labels": ["app=order-svc"]
},
"l4": {
"TCP": {"source_port": 51234, "destination_port": 8080}
},
"l7": {
"type": "REQUEST",
"http": {"method": "POST", "url": "/api/v1/orders", "protocol": "HTTP/1.1"}
}
}Hubble 提供两类指标：
cilium_* 指标，通过 /metrics
暴露，重点反映节点上的 Cilium 数据面状态。hubble_* 系列指标，覆盖 L3/L4/L7 维度。典型指标：
hubble_flows_processed_total：按源/目的标签、判决、L7
协议等维度计数的流事件总数。hubble_drop_total：按丢包原因（policy-denied、invalid-packet
等）聚合。hubble_tcp_flags_total：TCP
标志位计数，用于发现大量 RST、SYN 等异常。hubble_http_requests_total /
hubble_http_response_duration_seconds：L7 HTTP
维度指标。hubble_dns_queries_total /
hubble_dns_responses_total：DNS 观察。这些指标默认不会全部开启，需要通过 Cilium 配置显式启用，因为 L7 维度的高基数（High Cardinality）指标会显著放大 Prometheus 的成本。
以下命令在实际运维中高频使用。
# 查看最近的流事件，带 Kubernetes 上下文
hubble observe --namespace order
# 仅看 L7 HTTP 流量，且状态码 >= 500
hubble observe --protocol http --http-status '5..'
# 查看丢包事件，按丢包原因分组
hubble observe --verdict DROPPED --output json | jq '.drop_reason' | sort | uniq -c
# 查看某 Pod 的出入流量
hubble observe --pod order/order-svc-5f9c8d7b6-xyz34
# 按服务标签过滤
hubble observe --to-label app=payment --from-label app=web
# 查看 DNS 查询
hubble observe --protocol dns典型输出：
Apr 22 09:12:31.517 frontend/web-...abc12:51234 -> order/order-svc-...xyz34:8080 HTTP/1.1 POST /api/v1/orders FORWARDED
Apr 22 09:12:31.519 order/order-svc-...xyz34:8080 -> frontend/web-...abc12:51234 HTTP/1.1 500 Internal Server Error (12.3ms) FORWARDEDHubble UI 基于累积的流事件自动生成服务依赖图：节点是 Pod/Service/Workload，边是观察到的调用方向，边的属性包含请求速率、错误率、时延。
这张图的工程价值在于：
Cilium 使用
CiliumNetworkPolicy（CNP）描述网络策略。Hubble
可以清楚展示：
这在灰度收紧零信任网络（Zero Trust Network）策略时非常关键：你可以先把策略跑在”审计模式”，用 Hubble 观察会被拒绝哪些流量，再真正开启强制执行。
以下是最小化的 Cilium + Hubble Helm 部署片段。
# values.yaml
kubeProxyReplacement: strict
k8sServiceHost: kube-apiserver.cluster.local
k8sServicePort: 6443
hubble:
enabled: true
metrics:
enabled:
- dns:query;ignoreAAAA
- drop
- tcp
- flow
- icmp
- http
relay:
enabled: true
ui:
enabled: true对应安装：
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
--namespace kube-system \
-f values.yaml
# 访问 Hubble UI
cilium hubble uiPrometheus 侧，给 Hubble Relay / Daemon 加
ServiceMonitor：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: hubble
namespace: kube-system
spec:
selector:
matchLabels:
k8s-app: hubble
endpoints:
- port: hubble-metrics
interval: 30sGrafana 侧，Cilium 官方提供了一整套仪表盘，覆盖 L3/L4/L7 指标与策略审计。
Tetragon 同样出自 Isovalent（Cilium 团队），但关注点不同：它不是为了做流量分析，而是为了做运行时安全可观测。
TracingPolicy 这个自定义资源（CR，Custom
Resource）描述要挂哪些
kprobe、过滤条件、以及命中后的动作。下面这条策略，观测并记录所有对 /etc/shadow
的读取，且来自容器内进程的操作会被杀死：
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: audit-etc-shadow
spec:
kprobes:
- call: "security_file_permission"
syscall: false
args:
- index: 0
type: "file"
- index: 1
type: "int"
selectors:
- matchArgs:
- index: 0
operator: "Equal"
values:
- "/etc/shadow"
matchActions:
- action: Sigkill再来一个：监控对外发起的 TCP 连接，过滤非集群内的目的地址，辅助发现横向移动或 C2 外联。
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: egress-connect-monitor
spec:
kprobes:
- call: "tcp_connect"
syscall: false
args:
- index: 0
type: "sock"
selectors:
- matchArgs:
- index: 0
operator: "NotDAddr"
values:
- "10.0.0.0/8"
- "172.16.0.0/12"Falco 同样是运行时安全工具，但：
两者都有生产案例，选型看团队栈：以 Cilium 为底座，Tetragon 更顺滑；已有 Falco 生态则无必要切换。
Tetragon 事件可以通过 JSON 流输出：
kubectl exec -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact在生产中一般把事件通过 Fluent Bit / Vector 收敛到 Kafka，再入 SIEM（Splunk、Elastic、阿里云 SLS、腾讯 CLS 等）进行长期留存与关联分析。事件与 Hubble 的流事件可以用 Pod 身份、时间戳做 Join，把”安全事件”与”网络动作”串起来。
Pixie 2019 年起由 Pixie Labs 开源，后被 New Relic 收购，现为云原生计算基金会（CNCF，Cloud Native Computing Foundation）沙箱项目。它的核心卖点是”零埋点、协议自动解析”。
整体上 Pixie 强调”数据不出集群”：默认情况下原始事件、协议负载都只存在 PEM 的内存/本地盘中，出集群的只有用户通过 PxL 脚本结果显式导出的数据。
Pixie 在内核 uprobe / kprobe 以及 socket 缓冲区上采集数据，在用户态 PEM 做协议识别与解析。目前内建支持：
识别使用”协议指纹”策略：从 socket 的第一批字节中，尝试匹配已知协议的起始模式（如 HTTP 的方法前缀、MySQL 的握手包结构），匹配成功后，给该 socket 打上协议标签，后续按对应的状态机解析。
Pixie 的数据查询语言叫 PxL，语法类似 Python + Pandas：
import px
df = px.DataFrame('http_events', start_time='-5m')
df = df[df.resp_status >= 500]
df.svc = df.ctx['service']
df.latency_ms = df.latency / 1e6
df = df.groupby(['svc', 'req_path', 'resp_status']).agg(
count=('latency_ms', px.count),
p99=('latency_ms', px.quantiles),
)
px.display(df, 'slow_requests')脚本在 Vizier 上解析，下发到每个 PEM 并发执行。这种模式相当于”把查询推到数据侧”，避免把原始数据集中存储。
官方基准显示，Pixie 默认配置下：
限制：
Pixie 提供 OTLP Exporter
相关能力（otel 插件及 px.export
接口），可以把 PxL 查询结果按 OpenTelemetry Metrics/Traces
协议发往外部后端。这样，Pixie
既可以作为独立观测平台使用，也可以作为 OpenTelemetry
生态里的”数据源”。
DeepFlow 由云杉网络开源，是目前国内网络可观测领域最成熟的开源项目，在 CNCF Landscape 有登记。
AF_PACKET
用于看完整网络包（容器虚拟网卡、主机网卡、物理交换机镜像），两者互补。+--------------------+ +--------------------+
| deepflow-agent | gRPC(fb) | deepflow-server |
| （K8s DaemonSet） |<----------->| （Go 集群服务） |
| - eBPF 采集 | | - 元数据同步 |
| - AF_PACKET 采集 | | - 流 / 指标 / 跟踪 |
| - L7 协议解析 | | - ClickHouse 写入 |
+--------------------+ +--------------------+
^
| SQL
v
+-----------+
| ClickHouse|
+-----------+
^
|
+-----------+
| Grafana |
+-----------+deepflow-agent 用 Rust 编写，eBPF 程序使用 CO-RE 形式分发。deepflow-server 用 Go 编写，存储基于 ClickHouse。Grafana 侧有官方的 DeepFlow 数据源插件，提供专用查询语言。
AutoTagging：agent 与 Kubernetes API、云平台 API 同步资源信息，给每条流/每条 L7 记录自动打上：
AutoTracing：在 eBPF 层采集 TCP socket 的五元组、L7 请求响应对，同时记录进程/线程上下文。当一个进程”收到请求 A 后发出请求 B”时，可以通过时间相邻、socket 关联、线程局部存储（TLS，Thread Local Storage）的令牌传递（如 HTTP 头里的 X-Request-ID）推断 A 与 B 的调用关系，从而构造无埋点的调用链。
对没有显式 Trace ID 的应用，这种启发式推断不是百分百精确，但在工程上可以覆盖 80% 的场景，对于老系统的”第一张调用图”非常有价值。
DeepFlow 的数据存于 ClickHouse，提供专用的 SQL 扩展：
SELECT
request_resource,
response_code,
countIf(response_code >= 400) AS err_count,
quantileTDigest(0.99)(response_duration) AS p99_ms
FROM flow_log.l7_flow_log
WHERE time >= now() - INTERVAL 5 MINUTE
AND l7_protocol = 'HTTP'
AND pod_ns = 'order'
GROUP BY request_resource, response_code
ORDER BY err_count DESC
LIMIT 50;Grafana 插件将这些语义化的维度暴露为下拉框，上手门槛比手写 SQL 低。
# deepflow-values.yaml （Helm）
global:
image:
repository: registry.cn-beijing.aliyuncs.com/deepflow-ce
grafana:
enabled: true
service:
type: NodePort
deepflow-agent:
clusterNAME: prod-cluster
updateStrategy:
type: RollingUpdate
resources:
requests:
cpu: 500m
memory: 500Mi
limits:
cpu: 2
memory: 2Gihelm repo add deepflow https://deepflowio.github.io/deepflow
helm install deepflow -n deepflow --create-namespace \
deepflow/deepflow -f deepflow-values.yaml| 维度 | Hubble | Pixie | DeepFlow |
|---|---|---|---|
| 定位 | Cilium 可观测层 | 通用 K8s 可观测 | 全栈（云 + 云原生） |
| 是否绑 CNI | 是（Cilium） | 否 | 否 |
| L7 协议覆盖 | HTTP/DNS/Kafka 等 | HTTP/DB/MQ 等较多 | HTTP/DB/MQ/Dubbo 等最多 |
| 存储 | 节点内存 + 指标后端 | 节点内存（列式） | ClickHouse（集中） |
| 调用链 | 有限 | 基于 L7 事件 | AutoTracing |
| 自定义策略语言 | 否 | PxL | SQL |
| 数据是否出集群 | 可选 | 默认不 | 集中存储 |
| 生态 | CNCF Graduated 一部分 | CNCF Sandbox | CNCF Landscape（国产） |
| 社区语言 | 英文 | 英文 | 中英双语，国内活跃 |
DeepFlow 的突出优势是”既做网络包又做 eBPF，L7 协议覆盖广”；劣势是相比 Hubble，与 Cilium 的策略联动不那么深。
当 NPM 深入到 L7（以本文讨论的 Hubble/Pixie/DeepFlow 为例），它开始能够看见：
这恰恰是 APM 的传统地盘。但两者的视角仍然不同：
场景一：NPM 能抓到，APM 抓不到。
场景二：APM 能抓到，NPM 抓不到。
HTTPS、gRPC、TLS-over-MySQL 等加密协议占比越来越高。对基于网络层/传输层采集的可观测系统来说，这意味着如果不做特殊处理，只能看到密文流、统计流量大小与连接生命周期，拿不到 L7 语义。
常见解密路径有三种：
SSL_read/SSL_write（以及 Go
crypto/tls、Node/Python ssl
等）函数入口/返回点采集明文缓冲区。这是
Pixie、DeepFlow、Hubble L7 HTTPS 的主流做法。关键点：
/proc/<pid>/root/<libpath>；TLS 1.3 默认使用会话票据实现会话恢复，这意味着：
SSL_read/SSL_write。HTTP/2 在单条 TCP 连接上多路复用（Multiplexing）多个流（Stream），每个流用唯一的 Stream ID 标识。对协议解析器而言，这带来两个挑战：
在 eBPF 中完全实现 HPACK 解码并不现实（eBPF 指令数限制、无堆、无动态循环），主流做法：
golang.org/x/net/http2/hpack、Rust 的
h2 等）还原完整请求。这也是为什么 Pixie、DeepFlow 在用户态 Agent 占 CPU 不低：真正的协议解析成本都在那里。
gRPC 使用 HTTP/2 作为传输，content-type 为
application/grpc，方法名放在 :path
伪头里（形如
/package.Service/Method），状态码在响应 Trailer
的 grpc-status 里。解析要点：
:path、:status、grpc-status、grpc-message；对于”一个 socket 上跑的是什么协议”这个问题，常见识别策略：
GET、POST 等方法开头；MySQL
以长度前缀 + 握手包；Redis 以
*<number>\r\n；Kafka 以 ApiKey。unknown，避免误报。解析器本身要求：
feed(partial_bytes)。memcpy，使用索引与视图。“这个系统里哪些服务在互相调用”，对新接手系统、对故障影响面分析、对安全基线审计，都是最先需要回答的问题。传统做法：
这些都难以跟上变化速度。基于网络流量自动发现服务拓扑，是网络可观测工具的天然能力。
从原始流到服务拓扑图，需要多级聚合：
每一级聚合都会失去细节，但对应不同的使用者：SRE 看应用级，开发看服务级，排障看实例级，取证看流级。
px/service_graph 脚本，按 Service / Endpoint
展示调用关系与指标。在 Istio / Linkerd 等基于 sidecar 的服务网格（Service Mesh）中，每个 Pod 旁边都有一个代理进程（Envoy / linkerd-proxy）。网络层看到的流量是：
app A -> envoy A -> envoy B -> app B如果按 IP 聚合，会把 “app -> envoy” 的 127.0.0.1 回环流量与 “envoy -> envoy” 的跨节点流量都保留。拓扑图如果不做特殊处理，会出现大量”自己调自己”的边。
处理思路：
DeepFlow、Pixie、Hubble 都有针对 Istio 的”合并 sidecar”能力，但各家实现成熟度不同，部署前建议用灰度环境验证。
Istio 基于 Envoy sidecar，天然会产生丰富的 L7 指标：
istio_requests_total：按源/目的
workload、响应码、协议聚合的请求计数；istio_request_duration_milliseconds：请求时延直方图；istio_tcp_sent_bytes_total /
istio_tcp_received_bytes_total：非 HTTP TCP
流量。这些指标来自 Envoy 的 Prometheus 端点，经过 Istio 的
telemetry 配置塑形。也就是说：装了 Istio
并打开默认 telemetry，就已经有一套相当像样的 L7
观测数据了。
代价是 sidecar：每个 Pod 多出一个 Envoy 进程，资源占用（CPU 50m~200m、内存 50MiB~200MiB），延迟新增 1~3 毫秒。对大规模集群与对延迟敏感的负载，这是显著的成本。
eBPF 路径（Hubble/DeepFlow/Pixie）不需要 sidecar，资源开销通常只集中在 DaemonSet 上，但也有自己的代价：
所以现实中不少团队选择共用：Istio 负责服务治理与 L7 基线指标，Hubble/DeepFlow 负责网络层排障与安全。
Cilium 提供了”无 sidecar”的服务网格方案：
优势：
劣势：
选型上：追求简洁、绝对性能、统一 eBPF 栈 → Cilium Service Mesh；需要复杂流量治理与成熟生态 → Istio。
eBPF 程序把事件送到用户态主要靠两种机制：
perf_event_array：较老的机制，每 CPU
一个环形缓冲区；BPF_MAP_TYPE_RINGBUF（Linux
5.8+）：单一全局环形缓冲区，带原子保留接口，性能更好。在大流量下，用户态消费速度跟不上内核生产速度，缓冲区会溢出，事件丢失。工程上常见应对：
bpf_ringbuf_reserve/commit 配合批
poll）；高吞吐链路上，采全量流日志既不经济也没必要。常见策略：
对指标（计数、直方图）用 BPF Map 内聚合，仅周期性导出，可降低几个量级的数据量。对需要排障的原始事件，则必须尽量保全。工程上常用的分层策略：
一旦进入 HPACK 解码、MySQL 协议解码这些工作，CPU 开销会显著上升。经验数据（参考 Pixie/DeepFlow 官方测试）：
生产部署一定要给 Agent 预留 CPU，并在高峰做压力测试。
要把 TCP 连接的全生命周期串起来，必须维护一张”连接 -> 状态”的表。高峰时连接数可能达到百万级，相应 BPF Map 需要按连接条目大小 ×连接数做预留，常见配置：
超时清理策略：
tcp_close 挂 kprobe，主动释放；BPF_MAP_TYPE_LRU_HASH，让内核按最近使用淘汰。云杉网络在电信、移动、联通的多个省级 IT 系统里都有 DeepFlow 部署案例，典型规模：
中国移动公有云 / 私有云的大规模 Kubernetes 平台（万级节点）在 2023~2024 年陆续把网络可观测栈从传统 NetFlow 迁移到 eBPF 方案：
腾讯内部的容器平台（腾讯云操作系统 TCOS、TKE）在多个场景下使用 eBPF 做网络可观测：
tcpex 等内部工具采集 TCP
层指标，关联到容器；公开资料上，腾讯 TKE 也提供”网络可观测”增值功能，底层是基于 eBPF 的流日志 + 服务拓扑。
国内多家大型银行在生产网与开发测试网推行零信任改造，网络可观测是其中关键一环：
这里的工程挑战不是技术不够，而是合规与留痕要求极高，任何漏采都可能在监管检查中出问题。
pclntab/.gopclntab、通过 DWARF 或
Go 版本特定的偏移表来定位。SSL_read
符号的问题。当单节点 PPS 超过 100 万级，即便 eBPF
程序很精简，perf_event 或 ringbuf
仍可能丢事件。判断方法：
bpftool prog show 可观测 eBPF
程序运行次数；BPF_RB_AVAIL_DATA、BPF_RB_RING_SIZE
等字段，可计算填充率；应对：先在采集侧过滤（丢弃控制面流量、本地回环等），再上采样。
默认 Hubble 仅在节点上保留最近几万条流事件（环形缓存）。要长期存储，需要：
忽略这一点的团队，事后排障时经常发现”事件已经被 Hubble 自己的环形缓存覆盖了”。
DeepFlow agent 默认资源请求较低，但在高流量节点实际占用可能远超请求，触发 OOMKilled。部署清单务必：
Pixie 不支持非 Kubernetes 部署。混合环境（Kubernetes + 虚拟机 + 裸机）下，Pixie 只能覆盖一部分。这类场景下，DeepFlow 通常是更好的选择。
流事件的时间戳来自节点本地时钟，多节点合并分析时，时钟偏差会导致拓扑边乱序、P99 计算不准。建议：
node_timex_offset_seconds）；CLOCK_MONOTONIC），用于同机事件排序。同名 Namespace（如多个集群都有 order
命名空间）聚合时会撞车。工程上建议：
cluster_name，所有事件统一带上集群标签；cluster/namespace/service
三元组渲染。eBPF 程序上线时会被内核验证器校验。大的 L7 解析程序经常撞上：
bpf_loop()（5.17+）。CO-RE 工具链可以缓解，但复杂协议解析仍然要尽量把工作推到用户态。
| 场景 | 推荐方案 |
|---|---|
| 纯 Kubernetes、已用 Cilium | Hubble（可加 Tetragon 做安全） |
| 纯 Kubernetes、未用 Cilium，业务协议丰富 | Pixie 或 DeepFlow |
| 混合云：Kubernetes + VM + 裸机 | DeepFlow（双数据面原生支持） |
| 强安全合规要求 | Tetragon + Hubble + SIEM |
| 需要深度调用链且不想改代码 | DeepFlow AutoTracing 或 Pixie PxL |
| 研发主导、看重 SQL/脚本能力 | DeepFlow（ClickHouse 内 SQL）或 Pixie（PxL） |
| 追求极简、想让 NPM 与服务网格合一 | Cilium Service Mesh + Hubble |
以下清单可作为上线 checklist：
bpf
子系统源码：kernel/bpf/、net/core/filter.c。上一篇：eBPF 可观测性全景：bcc、bpftrace、libbpf 的工程路径
下一篇：Continuous Profiling：Parca、Pyroscope、Grafana Beyla
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / observability
eBPF 如何实现零侵入、内核级、低开销的可观测性：从 kprobe/uprobe/tracepoint/fentry 钩子机制，到 bcc 工具集、bpftrace 脚本语言、libbpf+CO-RE 可移植编程，再到 Pixie、DeepFlow、Grafana Beyla 等商业化工具，结合内核版本兼容性与生产部署实战。
2026-04-22 · architecture / observability
从 CPU/heap/goroutine/lock/off-CPU 等 Profiling 种类出发，比较采样与插桩两类 profiler 的工作原理，深入 Go pprof、Java async-profiler/JFR、Python py-spy、Pyroscope、Parca eBPF Profiling，以及 OpenTelemetry Profiles 的最新进展，给出国内字节美团的真实落地经验与工程坑点。
2026-04-22 · architecture / observability
深入剖析持续性能分析（Continuous Profiling）的原理、架构与落地实践，覆盖 Parca、Pyroscope、Grafana Beyla 三大主流方案，包含 eBPF 采样、符号解析、火焰图、差异分析以及字节跳动、美团的生产案例与工程坑点。
2026-04-22 · architecture / observability
从 Metrics、Logs、Traces 到 Profiling、eBPF、OpenTelemetry 与 SLO 治理，面向中国工程团队的可观测性系统化手册。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。