eBPF 可观测性与 Cilium/Tetragon 应用

• eBPF 无侵入采集的原理
• DNS/HTTP/gRPC 指标采集
• 服务依赖图自动生成

Cilium Hubble 基于 eBPF 实现「无侵入（zero-instrumentation）」的 K8s 服务拓扑与流量可视化。原理：eBPF 在内核数据路径（如 XDP/TC/socket）拦截网络包，无需修改应用、无需 sidecar 插桩，即可观测「服务间流量」。流量可视化：① 采集——eBPF 捕获「每条流量的五元组（源/目的 IP、端口、协议）」，并关联到「K8s 服务/Pod/命名空间」；② 协议解析——Hubble 解析「应用层协议」：HTTP/gRPC 的请求方法、状态码、延迟，DNS 的请求/响应，得到「协议级指标」；③ 服务依赖图——基于「流量的源/目的关系」自动生成「服务拓扑图（Service Map）」，展示「服务间依赖、流量方向、延迟、错误率」；④ 指标输出——把流量指标（每秒请求、延迟、错误率）暴露给 Prometheus，支持告警。价值：① 无侵入——不改造应用、不插桩，即时获得全链路可观测性；② 服务拓扑——自动生成「服务依赖图」，理解「谁依赖谁、流量如何流动」；③ 协议级——HTTP/gRPC/DNS 的「请求级」观测，定位「慢/错」在哪个服务间。Hubble 是「CNI 网络流量可视化的标配」，是 K8s 可观测性的重要能力。

Hubble 的核心是「eBPF 内核级采集 + 协议解析 + 服务拓扑生成」。无侵入是其最大优势（不插桩、不改造）。采集流量并关联 K8s 身份、解析 HTTP/gRPC/DNS、自动生成依赖图，提供「服务级流量可观测性」。

• Falco 的原理（内核层系统调用过滤）
• 规则引擎（规则匹配）
• 告警输出与抑制

Falco 是「内核层运行时安全」工具，检测「容器/K8s 环境的异常行为」。原理：① 内核层采集——Falco 用 eBPF/内核模块「拦截系统调用」和「内核事件」，采集「进程、文件、网络、容器」等行为；② 规则引擎——用「规则（rules）」定义「异常行为模式」：如「在容器内启动 shell」「读取敏感文件」「异常网络连接」「新建特权容器」；规则用「条件 + 输出」表达，Falco 驱动把「系统调用事件」与规则匹配；③ 告警输出——匹配到规则时生成「告警」，输出到多种渠道（stdout、文件、webhook、Alertmanager、K8s events）；④ 抑制策略——① 规则粒度控制：通过「优先级、条件」减少误报；② 排除/白名单：排除「已知正常」行为；③ 告警聚合：相似告警合并；④ 输出抑制：控制告警频率。Falco 的价值：在「内核层」实时检测「容器逃逸、恶意文件访问、异常网络」等「运行时安全威胁」，是「容器安全」的「运行时防线」。与「镜像扫描（静态）」不同，Falco 是「运行时动态」检测。

Falco 的核心是「内核层采集系统调用 + 规则引擎匹配 + 告警输出 + 抑制」。它检测「运行时异常行为」，是「容器运行时安全」。规则引擎定义「异常模式」，抑制策略控制「误报与噪音」。与静态镜像扫描互补。

• Pixie 的 eBPF 自动采集机制
• 服务拓扑与火焰图的生成
• 数据导出到长期存储

Pixie 是「开源的 eBPF 可观测性平台」，通过 eBPF 实现「无需插桩」的自动采集。① 采集机制——Pixie 用 eBPF 在集群节点（每个节点 DaemonSet）自动采集「应用层协议」：HTTP/gRPC/DNS 的流量、请求、延迟、错误，无需修改应用或加 sidecar；② 服务拓扑（Service Map）——基于采集的「服务间流量」自动生成「服务拓扑图」，展示「服务依赖、流量方向、吞吐、延迟」；③ 火焰图（Flame Graph）——用 eBPF 采集「CPU 采样/栈」生成「函数级火焰图」，可视化「CPU 热点」，无需插桩；④ 数据留存与导出——Pixie 默认「集群内留存」数据（保留一段时间），支持「导出到长期存储」：通过 PxL 脚本（Pixie 查询语言）查询数据，导出到「长期存储」（如 S3、ClickHouse、对象存储）或「OLAP 工具」，实现「长期可观测性」。Pixie 的价值：① 无侵入——eBPF 自动采集，秒级部署；② 全面——协议级流量 + 服务拓扑 + 火焰图；③ 集群内联——数据在集群内处理、留存，导出到长期存储。Pixie 是「K8s 可观测性的 eBPF 方案」的代表。

Pixie 的核心是「eBPF 无侵入自动采集 + 协议解析 + 服务拓扑/火焰图 + 集群内留存与导出」。它无需插桩即获得「服务级可观测性」，用 PxL 查询并能导出到长期存储。是「K8s 无侵入可观测性」的代表。

• eBPF 数据路径分层（XDP/TC/socket）
• 各层负载均衡的作用
• conntrack 瓶颈规避

Cilium 用 eBPF 在「数据路径」的多个层级实现「负载均衡与网络功能」，分层优化性能。① XDP 层——最早的数据路径（网卡驱动层），最快，用于「高吞吐」场景（如 DDoS 防护、快速转发）；适合「不需要状态」的早期处理。② TC 层——traffic control 层，在「内核协议栈」处理，支持「更复杂」的功能（状态、BPF 程序），是 Cilium 负载均衡的「主路径」；通过 direct routing 实现高效转发。③ socket 层——在「socket 层」用 BPF 优化「本机进程间」流量（如服务间通信），避免「穿越协议栈」的开销，提高「本地流量」性能。conntrack 瓶颈规避：传统 kube-proxy 用 iptables + conntrack，流量大时「conntrack 表满」成为瓶颈；Cilium 用 eBPF 的「BPF conntrack」或「无 conntrack」机制，把「连接跟踪」从「内核 conntrack 表」迁移到「BPF map」，规避「conntrack 表满/哈希冲突」瓶颈，提升「高并发」性能。分层意义：在不同层做「适合的优化」，XDP 最快、TC 主路径、socket 优化本地，配合 BPF conntrack 规避瓶颈，实现「高性能网络数据路径」。

Cilium 数据路径分层的核心是「按层优化」——XDP 最快（无状态）、TC 主路径（有状态）、socket 优化本地流量。conntrack 用 BPF map 替代内核表，规避「表满瓶颈」。分层 + BPF conntrack 是 Cilium 高性能的根基。

• eBPF 程序生命周期（加载、attach、detach、卸载）
• 加载/attach 失败处理
• 内核态异常与主机隔离

eBPF 程序的生命周期与故障隔离是「生产落地」的关键。① 生命周期——加载（load，把 BPF 程序送入内核并校验）→ attach（挂载到钩子点，如 kprobe/tracepoint）→ 运行（触发执行）→ detach → 卸载（unload）；由「用户态进程」管理，进程退出时自动清理。② 加载/attach 失败处理——加载失败（如校验失败、权限不足、内核不支持）时，用户态应「优雅处理」：捕获错误、记录日志、可降级（如跳过该探针）不崩溃；attach 失败（钩子点不存在、权限）同样处理，避免「程序启动失败」。③ 内核态异常隔离——eBPF 程序运行在内核，若异常（无限循环、内存越界）可能影响内核稳定；eBPF 的「安全机制」保证：① 校验器（verifier）在加载时静态检查（拒绝无限循环、越界访问、非法类型）；② 程序「受限」——有指令数限制、栈限制；③ 运行时「安全」——eBPF 不支持任意内存访问，专用于安全场景；④ 故障隔离——某个 eBPF 程序异常「不会崩溃整个内核」，而是被「校验器拒绝」或「下线」，不影响主机稳定性。核心是「eBPF 的安全设计（校验器 + 限制）保证了内核态异常不波及主机」。

eBPF 生命周期关键是「加载/attach 失败要优雅处理」，内核态异常靠「校验器 + 限制 + 安全设计」隔离。校验器在加载时拒绝不安全程序，eBPF 的限制保证「异常被隔离」，不崩溃主机。这是 eBPF 生产可用的基础。

• ClusterMesh 与 Hubble 的跨集群能力
• 跨集群流量可视化的工程边界
• 局限与解决

Cilium ClusterMesh 把「多个集群」组成「逻辑单一集群」，实现跨集群「服务发现、网络策略、负载均衡」。Hubble 在其上的跨集群流量可视化存在「工程边界」：① 能力——Hubble 能观测「跨集群流量」：ClusterMesh 的跨集群连接（cluster-aware）被 Hubble 识别，能展示「跨集群的服务依赖与流量」；② 边界/局限——① 数据本地化：Hubble 的 telemetry 默认「每个集群本地存储」，跨集群的「全局视图」需要「集中聚合」Hubble 数据（如 federated 更复杂）；② 服务身份映射：跨集群的服务/身份解析依赖 ClusterMesh 的 cluster-aware 服务发现，配置复杂；③ 延迟/一致性：跨集群的流量观测存在「数据聚合延迟」，实时性受限；④ 部署复杂度：多集群 Hubble 部署、数据汇聚、权限管理复杂。工程边界在于「多集群的可观测性聚合」——单集群 Hubble 成熟，跨集群需要「额外聚合（如 Hubble 数据集中、federated 或对接外部可观测平台）」。解决：把各集群 Hubble 数据「导出到集中平台」或用「多集群可观测性方案」聚合，实现「跨集群全局视图」。

ClusterMesh 提供跨集群网络，Hubble 能观测跨集群流量，但「跨集群的可观测性聚合」是工程边界——数据本地化、身份映射、聚合延迟、部署复杂。解决靠「集中聚合 Hubble 数据」，而非单集群原生支持。

• ClusterMesh 跨集群服务发现
• 网络策略同步
• 全局服务负载均衡

Cilium ClusterMesh 把多个集群组成「逻辑单一集群」，实现多集群网络能力。① 跨集群服务发现——ClusterMesh 用「ClusterPool 方式」把「各集群的服务」同步到「全局命名空间」，让一个集群的 Pod 能发现「其他集群的服务」；通过「cluster-aware 的 DNS 解析」和「服务网格端点同步」实现跨集群服务发现。② 网络策略同步——ClusterMesh 同步「跨集群的网络策略」：集群间部署的控制面（cluster mesh apiserver）全球同步「CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy」，让「跨集群的流量」遵循同一套安全策略，实现「多集群统一安全」。③ 全局服务负载均衡——ClusterMesh 支持「跨集群的负载均衡」：一个服务的后端「分布在多个集群」，来自某集群的请求被负载均衡到「其他集群的后端」（基于路由/亲和性），实现「全局负载均衡」、故障转移与容量扩展。价值：多集群「服务发现、统一策略、全局负载均衡」让「多集群」像「一个大集群」运作，支持「多活、容灾、跨区域扩展」。部署需「集群间互联（VPC/隧道）+ ClusterMesh 控制面」。

ClusterMesh 的核心是「跨集群服务发现（全局同步）+ 网络策略同步（统一安全）+ 全局负载均衡（多集群后端）」。它让多集群「逻辑单一」，支持多活容灾。前提是「集群互联 + cluster mesh 控制面」。

• Tetragon 的进程监控能力
• 文件访问与网络行为追踪
• 策略执行（kill/stop/notify）

Tetragon 是 Cilium 生态的「eBPF 运行时安全」工具，基于 eBPF 实现「进程监控与运行时安全」。能力：① 进程追踪——用 eBPF 追踪「进程创建/执行/退出」：记录进程、父进程、命令行、执行环境，检测「异常进程执行」；② 文件访问——追踪「文件打开/读取/写入」：检测「敏感文件访问」「异常文件操作」；③ 网络行为——追踪「网络连接（connect/accept）」，检测「异常网络连接（外连、可疑端口）」；④ 策略执行——用「TracingPolicy（追踪策略）」定义「要监控的行为」与「响应动作」：① kill——终止违规进程；② stop——停止/拦截进程；③ notify——仅通知（告警）；④ signal——发送信号。通过「策略」实现「检测 + 响应」的闭环。Tetragon 的价值：① 内核层实时——eBPF 内核级追踪，无侵入；② 行为检测——进程/文件/网络行为，检测「逃逸、恶意行为」；③ 策略响应——可执行「kill/stop/notify」，实现「自动响应」而非仅告警。与 Falco 相比，Tetragon 与 Cilium 深度集成，策略（TracingPolicy）更灵活、可执行响应动作。

Tetragon 的核心是「eBPF 追踪进程/文件/网络行为 + TracingPolicy 定义监控与响应（kill/stop/notify）」。它实现「检测 + 响应」闭环，是「内核级运行时安全」。与 Cilium 集成，策略可执行动作。

• eBPF 与 OTel 的融合方式
• eBPF 低层信号与 OTel 信号的关联
• Correlated Signals 的价值

eBPF 与 OpenTelemetry（OTel）融合，把「eBPF 采集的低层信号」与「OTel 的 Trace/Metrics/Logs」关联，实现「全栈可观测性」。融合方式：① eBPF 采集「低层信号」——网络流量、系统调用、进程行为、内核指标；② OTel 采集「应用层信号」——Trace（业务请求）、Metrics（业务指标）、Logs（应用日志）；③ 关联（Correlated Signals）——通过「共享的上下文标识」把「低层信号」与「应用信号」关联：① 用「网络连接/会话标识」关联「Trace 的流量」与「eBPF 的网络观测」；② 用「进程/线程标识」关联「eBPF 的进程行为」与「应用 Trace/Metrics」；③ 用「时间戳」对齐「低层信号与 OTel 信号」，实现「同时间窗跨层关联」。价值：① 端到端——把「应用层 Trace」与「内核层网络/系统行为」关联，定位「应用慢是底层网络还是系统问题」；② 补盲—eBPF 覆盖「无插桩的应用」（如无法改代码的组件），弥补 OTel 插桩盲区；③ 统一——低层信号纳入 OTel 生态，统一「采集、存储、查询」。落地：用 eBPF 采集器（如 Cilium Hubble、Pixie）输出 OTel 兼容信号，或「eBPF → OTel Collector」接入统一可观测平台。核心是「用共享标识 + 时间对齐」把「低层与高层信号」关联成统一的「可观测视图」。

融合的核心是「用共享上下文标识 + 时间对齐」把 eBPF 低层信号与 OTel 应用信号关联，实现「跨层可观测」。eBPF 补「无插桩盲区」，OTel 提供「统一生态」。Correlated Signals 提供「端到端、跨层」的排障视图。

• eBPF 性能开销的来源
• 开销控制手段（采样率、过滤、map 调优）
• CPU 开销评估

eBPF 可观测性在生产中的性能开销控制是「关键」，否则影响业务。开销来源：① eBPF 程序在每个「事件」上执行的开销（CPU 时间）；② map 操作开销（更新/查找）；③ 数据采集/上报开销。控制手段：① 采样率——对高频事件「采样」（如只采集 1% 的流量/请求），降低开销；② 过滤条件——在 eBPF 程序内「尽早过滤」（只处理感兴趣的事件，如按端口/PID/功能过滤），减少不必要处理；③ map 大小调优——合理设置 BPF map 的大小（避免 map 过大消耗内存、过小导致替换/丢失），按需调优；④ 指令优化——精简 eBPF 程序（减少指令数、避免复杂逻辑）；⑤ 数据上报——按需批量/采样上报，减少用户态处理。CPU 开销评估：① 用「基准测试」测量 eBPF 启用前后的 CPU 差异（如 tracepoint 命中率、perf 采样）；② 关注「高流量路径」的 eBPF 开销（网络/系统调用高频）；③ 设「开销预算」——让 eBPF 开销控制在「可接受」（如 <5% CPU）。落地：用「采样 + 过滤 + map 调优」控制开销，用「基准」评估，确保「可观测性」不「牺牲性能」。

eBPF 开销控制的本质是「用采样/过滤降低事件处理，用 map 调优平衡内存，用基准评估 CPU」。核心是「在可观测性与性能之间平衡」，避免「为了观测拖垮业务」。高频路径尤其要「采样 + 过滤」。

• eBPF 内核态（探针、BPF 程序）与用户态（map、ring buffer）
• 数据传递机制
• 交互架构

eBPF 的程序架构是「内核态（BPF 程序）+ 用户态（加载/管理）」通过「map 与 ring buffer」交互。① 内核态——BPF 程序挂载在「内核探针（kprobe，跟踪函数）/tracepoint（内核事件点）/perf_event」等钩子上，在内核事件发生时执行，采集数据；② 用户态——加载 BPF 程序、读取数据、管理程序；③ 数据传递机制——① map：内核态与用户态共享的「数据结构」（哈希表、数组、栈等），BPF 程序写入数据，用户态读取；map 是「共享存储」；② ring buffer/perf buffer：内核态向用户态「推送事件」的「环形缓冲」，BPF 程序把事件写入 ring buffer，用户态异步读取；ring buffer 是「高性能事件流」。架构：BPF 程序（内核探针触发）→ 写 map / ring buffer → 用户态加载程序读取 → 用户态处理/上报。交互要点：① 内核态「采集」、用户态「消费」，通过 map（状态）与 ring buffer（事件流）解耦；② 用户态可「更新 map 配置」控制 BPF 程序行为（如过滤器）；③ 数据流「内核 → 用户态」是「单向推送」与「共享读取」结合。这个架构实现了「低开销的内核采集 + 灵活的用户态处理」。

eBPF 架构的核心是「内核探针采集 + map/ring buffer 传递 + 用户态消费」。map 是共享状态（双向），ring buffer 是事件流（内核→用户态）。这个「内核采集、用户态处理」的架构实现「低开销、解耦」的可观测性。

• Hubble 指标暴露（Prometheus）
• 与 Prometheus 告警集成
• 流量策略告警配置

Cilium Hubble 监控落地需要「指标暴露 + 告警集成 + 策略告警」。① 指标暴露——Hubble 暴露「Prometheus 指标」（通过 Hubble 的 metrics 服务，如 hubble-metrics 上的 /metrics）：流量指标（请求总数、延迟、字节数）、错误指标（错误率）、协议指标（HTTP/gRPC/DNS）等；用 ServiceMonitor 或传统 prometheus 抓取。② 与 Prometheus 告警集成——通过 ServiceMonitor 把这指标接入 Prometheus，配置「告警规则」：如「服务间错误率 > 阈值」「延迟 P99 超阈值」触发告警；与 Alertmanager 集成通知。③ 流量策略告警——网络策略（CiliumNetworkPolicy）的「拒绝/丢弃」流量可被 Hubble 观测，配置「策略告警」：如「被拒绝的流量突增」「违反策略的连接」触发告警，检测「恶意/异常访问」。落地配置：① 启用 Hubble metrics（--set hubble.metrics.enabled="{flow,dns,http:destinationLabels=...}"）；② 部署 ServiceMonitor 接入 Prometheus；③ 配置告警规则（PrometheusRule）；④ 配置 Alertmanager 通知。价值：Hubble 提供「流量级指标」支撑「网络/服务可观测性与告警」，策略告警检测「安全威胁」。落地把「eBPF 流量观测」接入「Prometheus 告警体系」。

Hubble 监控落地核心是「暴露 Prometheus 指标 → ServiceMonitor 接入 → 告警规则 → 策略告警」。它把「流量级可观测性」接入「Prometheus 告警」，并可用「策略告警」检测安全威胁。配置涉及「metrics 启用 + 抓取 + 告警规则」。

• eBPF 相比 iptables 的性能优势
• 可观测性优势
• 策略表达优势

Cilium 基于 eBPF 的 CNI 与网络策略相比传统 iptables 有明显优势。① 性能——iptables 的规则是「线性遍历」，规则多时性能下降；eBPF 用「哈希查找 + 内核内执行」，O(1) 查找，性能高、延迟低；eBPF 数据路径（XDP/TC）比 iptables（netfilter 链）更快，支持「高并发/高吞吐」；规避 conntrack 瓶颈。② 可观测性——iptables 是「黑洞」难观测；eBPF 天然「可观测」——包经过 BPF 程序可「采集指标、流量、协议」，配合 Hubble 提供「服务拓扑、流量可视化、协议级指标」，这是 iptables 无法提供的。③ 策略表达——iptables 规则「扁平、难读、难维护」；Cilium 网络策略用「声明式 CRD（CiliumNetworkPolicy）」表达「服务间安全策略」，支持「L7 协议（HTTP/gRPC）、身份认证、语义化表达」，比 iptables 更「可读、可维护、表达力强」。Cilium 策略「按身份/标签」而非「按 IP」，更符合 K8s 「服务」语义。总结：eBPF 相比 iptables 在「性能（哈希查找 vs 线性）、可观测性（流量采集 vs 黑洞）、策略表达（声明式 CRD vs 扁平规则）」全面领先，是「现代 CNI 的演进方向」。

eBPF vs iptables 的优势是「性能（哈希查找 vs 线性遍历）、可观测性（可采集 vs 黑洞）、策略表达（声明式 CRD vs 扁平规则）」。这些优势源于「eBPF 内核内执行 + 可观测设计 + 语义化策略」，是 Cilium 竞争力的核心。

• Tetragon 与 Cilium 的安全定位差异
• kprobe vs tracing hook 的实现差异
• 边界与互补

Tetragon 与 Cilium 在「安全可观测性」上定位不同。① Cilium——聚焦「网络层安全」：用 eBPF 实现「网络策略（L3-L7）、网络流量观测、透明加密」，安全边界在「网络流量」；② Tetragon——聚焦「运行时/主机层安全」：用 eBPF 追踪「进程、文件、系统调用」等「主机行为」，安全边界在「进程/文件/系统行为」。实现差异：① Cilium 主要用「网络路径的钩子」（XDP/TC/socket，即网络数据路径的 eBPF 程序）；② Tetragon 用「内核函数挂点（kprobe/tracepoint）」和「tracing hooks」追踪「进程生命周期、系统调用、文件访问」；kprobe 是「动态函数探测」，tracepoint 是「内核事件点」，tracing hook（TracingPolicy）是 Tetragon 用于「定义自定义追踪」的机制。边界：Cilium「网络安全」，Tetragon「运行时安全」；两者互补——Cilium 管「网络流量」、Tetragon 管「主机/进程行为」。kprobe 灵活但「依赖内核函数名」（版本差异），tracepoint 更稳定；Tetragon 用「tracing hook」提供「统一的、可配置的」追踪机制，比直接 kprobe 更易用、更稳定。

边界差异是「网络安全（Cilium）vs 运行时安全（Tetragon）」。Cilium 用网络路径钩子，Tetragon 用 kprobe/tracepoint/tracing hook 追踪主机行为。Tetragon 的 tracing hook 提供「更易用、更稳定」的追踪抽象，kprobe 灵活但依赖内核函数名。

• TracingPolicy 的结构
• 进程/文件/网络追踪的编写
• 策略的响应动作

Tetragon 用 TracingPolicy 定义「要追踪的安全行为」与「响应动作」。TracingPolicy 结构：spec 包含 kprobes（内核函数追踪）或 tracepoints（内核事件点），每个 tracker 定义「事件、匹配条件、动作」。编写示例：① 进程执行——追踪「execve」类事件，匹配「特定进程/命令行」（如 args[0] 匹配 bash），触发 notify/kill；② 文件访问——追踪「openat/read」类事件，匹配「敏感文件路径」（如 /etc/shadow），触发「告警」；③ 网络连接——追踪「connect/sendto」类事件，匹配「目的 IP/端口」（如异常外连），触发「告警/拦截」。编写要点：① 定义「事件类型」（kprobe 或 tracepoint）；② 定义「匹配条件」（matchArgs 按参数匹配，matchNamespaces 按命名空间匹配）；③ 定义「动作」（notify 告警、kill 终止进程、signal 发信号、override 覆盖返回）；④ 用「selectors」精确定位「要监控的进程/容器」。TracingPolicy 让「安全观测」可配置化——定义「监控什么、匹配什么、响应什么」，实现「自定义运行时安全策略」。

TracingPolicy 的核心是「事件类型 + 匹配条件 + 响应动作」三段式。用 kprobe/tracepoint 定义事件，用 matchArgs 匹配参数，用动作（notify/kill/signal）响应。这让「安全观测」从「固定」变为「可配置策略」。

• on-cpu 与 off-cpu 分析
• 函数级火焰图
• 高频采样对生产的影响

eBPF 性能剖析用于「定位 CPU 性能瓶颈」。① on-cpu 分析——采样「正在 CPU 上执行的函数」，找到「CPU 热点」（哪些函数占用 CPU）；② off-cpu 分析——用 eBPF 追踪「进程被阻塞/睡眠」的事件（如锁等待、IO 等待、调度），找到「进程为什么不在 CPU 上」（等待什么），定位「off-cpu 瓶颈」（如锁竞争、IO 阻塞）；③ 函数级火焰图——把 on-cpu/off-cpu 采样数据生成「火焰图」，可视化「调用栈的 CPU 占用」，直观定位「热点函数」；④ 高频采样对生产的影响——采样（如每毫秒采样）会带来「CPU 开销」：① 采样越多、开销越大；② 高频采样可能影响「高吞吐、CPU 敏感」的生产系统；③ 需「控制采样频率」——在「开销与精度」间平衡，或用「过滤/定向采样」降低影响。落地：用「bpftrace/bcc」或「profiling 工具」做 on-cpu/off-cpu 采样，生成火焰图；在高频场景用「采样率控制、过滤、定向」降低生产影响。价值：on-cpu 找「CPU 热点」，off-cpu 找「等待瓶颈」，火焰图可视化，是「性能剖析」的利器，但需控制采样开销。

eBPF 剖析的核心是「on-cpu（CPU 热点）+ off-cpu（等待瓶颈）+ 火焰图可视化」。高频采样能精确定位但带来 CPU 开销，需「采样率控制 + 过滤 + 定向」平衡。on-cpu 与 off-cpu 互补，覆盖「计算瓶颈与等待瓶颈」。

• bpftrace 单行脚本的用法
• bcc 工具集（biolatency/runqlat/tcpconnect）
• 排障场景

eBPF 排障常用 bpftrace 与 bcc 工具集。① bpftrace——「单行脚本」式的高层 eBPF 工具，用一行脚本快速探针（如统计某函数的调用次数、跟踪系统调用）：bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }' 统计每个进程的 openat 调用；适合「快速诊断、临时探针」。② bcc 工具集——提供「预置工具」：① biolatency——统计「块 IO 延迟分布」，排查「磁盘 IO 慢」；② runqlat——统计「进程调度等待延迟（run queue）」，排查「CPU 竞争/调度慢」；③ tcpconnect——追踪「TCP 连接建立」，排查「网络连接问题（谁连了谁、连接失败）」。其他：execsnoop（追踪进程执行）、opensnoop（追踪文件打开）、stat（系统调用统计）。排障用法：① 磁盘慢 → biolatency 看 IO 延迟；② 响应慢但 CPU 不忙 → runqlat 看调度等待（CPU 竞争）；③ 网络连接异常 → tcpconnect 看连接建立；④ 系统调用调多 → execsnoop/opensnoop。bpftrace 快速灵活，bcc 工具集开箱即用，两者互补，是「eBPF 排障」的实用工具。

bpftrace 是「单行脚本快速探针」，bcc 是「预置工具集」。排障按「症状选工具」：IO 慢用 biolatency、调度慢用 runqlat、连接用 tcpconnect。bpftrace 灵活、bcc 开箱即用，是「eBPF 排障」的得力工具。

• 内核版本要求
• BTF/CO-RE 要求
• CAP_BPF 权限

eBPF 生产落地受「内核版本、BTF/CO-RE、权限」约束。① 内核版本——eBPF 功能依赖内核版本：基础 eBPF（4.x）、BPF 程序调优（4.15+）、BTF（5.4+）、CO-RE（5.4+）、部分新特性（5.10+）；老内核不支持新特性，需「内核版本满足」才能用；② BTF/CO-RE——CO-RE（Compile Once Run Everywhere）让「一个 BPF 程序」跨内核运行，依赖「BTF（BPF Type Format）」提供内核类型信息；内核需「开启 BTF（CONFIG_DEBUG_INFO_BTF）」，否则 CO-RE 无法工作；BTF 缺失是「常见部署障碍」；③ CAP_BPF 权限——加载 BPF 程序需要「CAP_BPF（及 CAP_SYS_ADMIN/CAP_PERFMON）」权限；容器内默认无此权限，需「特权模式/提权」或「root 运行」；限制「非特权环境」的 eBPF 部署。部署约束总结：① 内核版本要「够新」；② 内核要「开 BTF」支持 CO-RE；③ 进程要「有 CAP_BPF 权限」。这些限制了「老内核、精简内核、无特权容器」的 eBPF 落地。缓解：用「老内核降级方案」、开 BTF、用特权容器/专用 agent。eBPF 生产落地需评估这些「部署前提」。

eBPF 部署约束是「内核版本 + BTF/CO-RE + CAP_BPF 权限」三要素。内核版本决定功能、BTF 决定 CO-RE 兼容、权限决定能否加载。这些约束影响「老内核、精简内核、无特权容器」的落地，需「评估前提 + 缓解方案」。

• eBPF 版本兼容性（内核差异）
• CO-RE 机制（编译一次到处运行）
• BTF 与 libbpf 的作用

eBPF 程序的版本兼容性与内核升级风险是「生产落地」的关键。问题：不同内核版本「结构体、函数签名、字段偏移」不同，传统 BPF 程序「编译时锁定」内核版本，跨内核运行会「崩溃/失效」（字段偏移变化）。① CO-RE（Compile Once Run Everywhere）——「编译一次、到处运行」：BPF 程序「编译为通用形式」，运行时用「BTF + libbpf」「重定位」到具体内核的字段/类型，解决「跨内核兼容」；② BTF——提供「内核类型信息」（结构体布局、字段偏移），CO-RE 运行时用 BTF 做「字段重定位」；③ libbpf——用户态库，负责「加载 BPF + BTF 重定位 + CO-RE 处理」，运行环境需「libbpf 支持」。内核升级风险：① 内核升级可能「改变字段偏移、函数签名、结构体布局」，无 CO-RE 的旧程序会「失效」；② 有 CO-RE 的程序「自动适配」新内核（重定位），但「重定位失败」或「语义变化」仍可能出问题；③ 内核升级可能「移除/改名」某些函数/钩子点，导致 attach 失败；缓解：① 用 CO-RE + BTF + libbpf 保证「兼容」；② 内核升级前「测试 eBPF 程序」；③ 用「版本兼容」的钩子点（tracepoint 而非 kprobe）。CO-RE 让 eBPF「跨内核兼容」，但「内核升级」仍需「测试与监控」。

eBPF 版本兼容的核心是「CO-RE（编译一次到处运行）+ BTF（类型信息）+ libbpf（重定位加载）」。CO-RE 解决「字段偏移差异」，但内核升级仍需「测试」——钩子点变化、语义变化是「升级风险」。CO-RE 降低兼容成本，但「验证」不能省。

• eBPF 安全观测的局限
• 内核提权后的绕过手段
• 检测盲区与评估

eBPF 安全观测虽有强能力，但存在「对抗局限」与「检测盲区」。① 盲区/局限——① eBPF 观测「内核行为」，但「已提权的攻击者」可「操纵内核」；② 攻击者若「提权到 root/内核」，可「卸载/篡改 eBPF 程序」或「绕过 BPF 钩子」；③ 加密流量（TLS）无法在数据面解密，只能看到「连接元数据」非内容；④ 竞态——高并发下「漏采样/漏检」；⑤ 用户态绕过——攻击者用「非标准系统调用/直接系统调用」规避「常见钩子」。② 内核提权后的绕过——攻击者获取内核权限后：① 卸载/禁用 eBPF 程序；② 修改内核数据结构（绕过检测逻辑）；③ 直接调用内核函数（绕过 BPF 钩子）；④ 隐藏自身进程（rootkit 手法）。此时「eBPF 观测」可能「失效或被欺骗」。③ 评估——评估「检测盲区」：① 明确「eBPF 观测的边界」（能看什么、不能看什么）；② 做「红队/对抗测试」验证「绕过手段」；③ 「分层防御」——不依赖单一 eBPF 观测，配合「内核完整性、签名、异常检测、不可变基础设施」；④ 承认「eBPF 是纵深防御的一层」，而非「万能」。对抗局限的根本：eBPF 观测「运行在内核」，一旦攻击者「控制内核」，观测本身「可被操纵」。评估盲区是「安全设计」的一部分——了解「能精确检测什么、哪些会被绕过」。

eBPF 安全观测的局限核心是「观测依赖内核，攻击者提权后可操纵观测本身」。绕过手段（卸载/篡改/直接调用）与盲区（加密、竞态、用户态）需评估。应对靠「分层防御 + 对抗测试 + 明确边界」，不依赖单一观测。