【Falco】丢事件与缓冲：drop 归因与 BPF iterators 门

第 4 篇 说明富化依赖事件完备性。本篇钉五轴上的 输出与丢事件轴 中「丢」的一半：共享缓冲跟不上时，事件在进入规则引擎之前就消失。读者常见误区是把 SIEM 安静写成「无威胁」，或把规则条件为假写成「驱动坏了」。真正要钉死的是：缓冲维度如何配置；drop 指标语义是什么；0.44 BPF iterators 如何服务 drop recovery；0.44.1 为何允许关掉 iterators；双引擎下证据包如何分列。

本篇在系列中的位置

篇目	核心内容
第 4 篇 · libsinsp	富化与状态表
第 5 篇 · 丢事件与缓冲	buf preset、drop 语义、iterators 门
第 6 篇 · 规则语言与引擎	条件求值与「未命中」
系列目录	全部篇目

版本锚定：Falco 0.44.1；驱动 10.2.0+driver。0.44.0 引入 BPF iterators 用于初始状态与 drop recovery；0.44.1 增加 engine.modern_ebpf.disable_iterators（及 Helm 对应项），并修复 iterators 相关问题（libs 0.25.4）。不粘贴未跑的丢包率、CPU% 或伪造 drop 曲线。 不得把 0.44.0 容器坑写成「0.44.1 仍未修复」。

一、buf preset 与缓冲维度

falco.yaml（tag 0.44.1）把 syscall 缓冲写成驱动与用户态之间的共享空间：内核写入事件，用户态消费。buf_size_preset 是索引，不是随意字节数：

约束（官方注释）：大小须为 2 的幂、为系统页大小的倍数，且 大于 2 * page_size。页很大时，较小索引可能不可用；可用 falco --page-size 在真实节点核对。默认叙事里，历史上固定约 8 MB（索引 4）；增大可降低重负载下的 drop 压力，但增加内存映射成本——缓冲在进程虚拟地址空间中映射两次（8 MB 缓冲对应 16 MB 虚拟区）。本系列不给出未测「索引 N → 丢包率 X%」结论。

modern_ebpf 专有：cpus_for_each_buffer

modern_ebpf 使用 BPF ring buffer，并允许 多个 CPU 共享一个缓冲。cpus_for_each_buffer 默认 2（一对 CPU 一个缓冲）；1 表示每 CPU 一个；0（或等于 online CPU 数）表示全体共享一个。官方动机包括：在 Kubernetes 内存限额下避免 OOM 干扰，以及遵循内核侧关于少缓冲、控内存的讨论。kmod 路径没有与之对称的「CPU↔︎buffer 映射」旋钮叙事——调参时必须先确认引擎（第 2 篇）。

drop_failed_exit

两边引擎配置块都出现：在驱动里丢弃失败的 syscall exit 事件，减少入环流量，可能降低损失，但牺牲可见性。这是有意丢弃，与「环满被迫丢」不同；规则若依赖失败路径语义，需要单独评估。

engine:
  kind: modern_ebpf
  kmod:
    buf_size_preset: 4
    drop_failed_exit: false
  modern_ebpf:
    cpus_for_each_buffer: 2
    buf_size_preset: 4
    drop_failed_exit: false
    disable_iterators: false

片段来自 falco.yaml @ 0.44.1 的引擎块结构（注释已删减）；数值是上游默认叙事，不是本仓库压测推荐。

缓冲维度的工程直觉可以收成三条，仍不写未测百分比：第一，索引越大，单缓冲越大，环满概率通常下降，内存与二次映射成本上升；第二，modern_ebpf 上减少缓冲个数（提高 cpus_for_each_buffer）可降内存足迹，但过少会增加内核侧争用；第三，kmod 与 modern 即便共用同一 buf_size_preset 数字，也不意味着总内存与争用曲线相同——CPU↔︎buffer 映射只在 modern 侧可调。调参前先读 Driver 行，否则会在错误引擎上拧错误旋钮。

二、drop 指标语义

官方把「环满导致 syscall 信息丢失」当成一等运维事件，而不是日志边角。配置面至少两层（名称以 tag 为准）：

syscall_event_drops 注释写明：阈值是「上一秒 drop 相对事件数的比例」一类口径；依赖详细 drop 载荷时，应转向 metrics.output_rule 与 metrics.kernel_event_counters_enabled 等路径（配置内 CHANGE NOTICE）。本篇不编造任何阈值下的现场百分比。

排障上必须先做的区分：

规则未命中是轴 4：事件到达引擎后条件为假或被异常吞掉。drop 是事件未到达或状态已残缺。两者可以同时发生，但证据包不同。

把 drop 当成「安全产品噪声」关掉，会直接破坏第 4 篇描述的状态愈合前提：丢得越多，线程/FD 表越容易空洞，规则面越容易出现「字段空 → 条件假 → 以为无威胁」的连锁。反过来，只盯 drop 告警、不区分 drop_failed_exit 有意丢弃与环满被迫丢，也会误伤可见性开关。指标存在的意义是把轴 5 从猜测变成可点名的失败域，而不是提供本仓库未跑的性能排行榜。

三、0.44 BPF iterators 与 drop recovery

0.44.0 把「事件流不够用时的查找路径」拆成两块：重写的用户态 /proc 解析，以及 modern BPF iterators 提供的内核侧、进程内 task/FD 遍历。官方明确：同一套机器用于（1）启动时填充初始进程表；（2）在检测到 drop 等造成的陈旧/缺失后愈合状态。iterators 避免用户态刮 /proc 的往返与字符串解析，在 modern_ebpf 可用时提供更高效的回填。

驱动线 10.2.0+driver 同步支持经 modern BPF iterators 的同步文件/任务获取；并增加 metrics.kernel_iter_event_counters_enabled，把 iterator 侧事件与 drop 计数暴露到 metrics，补齐已有的 kernel_event_counters_enabled。

对第 4 篇的含义：drop 不只丢「那一次告警机会」，还可能挖空线程/FD 表，使后续规则字段变假。iterators 降低的是愈合成本与可靠性相对 /proc 的缺口，不是把 drop 本身变成零。

与「加大 buf_size_preset」的关系也要分清：更大的环降低环满概率；iterators 改善的是已经丢过之后如何把状态补回来。只做前者不做后者，仍可能在尖峰过后留下长时间的字段空洞；只开 iterators 却让环持续满，愈合会变成跟丢事件赛跑。0.44 把两条线同时推进，排障时却必须分开验证——否则容易把「愈合路径被容器门关掉」误写成「缓冲太小」。

四、0.44.1：可禁用 iterators（容器门）

0.44.0 跟踪问题记录：modern_ebpf 在容器化部署上因新引入的 BPF iterators（drop recovery）出现可用性故障；修复与补丁尽快跟进。0.44.1（2026-06-11）的用户可见变更正是：支持禁用 BPF iterators，并随 libs 0.25.4 修复多处 iterators 相关问题。

falco.yaml @ 0.44.1 对 engine.modern_ebpf.disable_iterators 的语义：

• 默认 false：使用 iterators 做启动填充与 drop 后愈合（相对 /proc 更快、更可靠）。
• 设为 true：禁用 iterators，回退到 procfs 查找。
• 不论该开关：只要 Falco 不在 host（root）PID 命名空间，iterators 会自动禁用——否则看不到完整主机进程视图。

Helm 侧对应 driver.modernEbpf.disableIterators。这是容器可用性与可见性门，不是「关闭 drop 检测」。关闭后 drop 仍可能发生；改变的是愈合路径与相关 metrics 是否仍有 iterator 计数（配置注明：iterators 因配置或内部逻辑禁用时，iterator 计数旋钮不适用）。

容器门的另一层含义是：即便 chart 显式 disable_iterators: false，只要 Pod 没进 host PID，运行时仍会关掉 iterators。此时日志或内部逻辑若提示「disabled BPF iterators (not running in the root PID namespace…)」一类信息，应理解为可见性约束触发的自动门，不要当成配置没生效。愈合回退到 procfs 后，第 4 篇讨论的 /proc 窗口与权限约束重新成为主路径——这是机制回退，不是静默「保持 iterators 语义」。

五、双引擎下的证据包差异

flowchart TD
  symptom["No alert or missing fields"] --> q_raw{"Any scap raw events?"}
  q_raw -->|"no"| axis12["Axis 1-2 driver or negotiate"]
  q_raw -->|"yes"| q_drop{"Drop signals rising?"}
  q_drop -->|"yes"| axis5["Axis 5 buffer or consumers"]
  q_drop -->|"no"| q_fields{"Rule fields empty?"}
  q_fields -->|"yes"| axis3["Axis 3 enrichment or plugins"]
  q_fields -->|"no"| axis4["Axis 4 rule condition or exception"]
  axis5 --> eng{"Driver line modern_ebpf?"}
  eng -->|"yes"| iter["Check iterators gate and buf geometry"]
  eng -->|"no"| kbuf["Check kmod buf preset and module health"]

图：先区分「无原始事件 / 有 drop / 字段空 / 条件假」，再按引擎分列缓冲证据。节点为英文。

开放争论（与第 2、10 篇呼应）：auto 回退到 kmod 后，若 runbook 仍按 modern 的 iterators / cpus_for_each_buffer 调参，会得到无效旋钮与错误因果。容器默认是否应关闭 iterators，属于策略选择；0.44.1 把选择权交给配置，而不是删掉愈合能力。

证据包分列还影响告警解读：同一条「Falco internal: syscall event drop」类信号，在 modern_ebpf + iterators 启用、modern_ebpf + iterators 关闭、以及 kmod 三条路径上，后续应核对的 metrics 键与愈合预期并不相同。第 13 篇排障坐标系会回指本表；本篇先禁止把三条路径的 drop 叙事揉成一句「调大 buffer 即可」。没有实测 pps 时，唯一诚实的结论是：先分列引擎与门闩，再谈旋钮方向。

谱系与开放问题

内核/用户态共享环：跟不上则丢（经典观测税）
  → Falco：buf preset + drop 动作/指标
  → 0.44：BPF iterators 加速状态愈合
  → 0.44.1：容器门上可关 iterators，回退 procfs
  → 仍开放：iterators 默认策略；drop 与规则未命中的联合 SLO

开放问题：异构节点上 auto 回退后，drop 指标是否应标签化实际引擎；iterators 自动禁用时，如何避免把「愈合变慢」误报成「规则库失效」（第 10、13、16 篇）。在未完成这些可观测性之前，值班手册至少应要求记录 Driver 行与 disable_iterators 生效态，并与轴 3 字段空洞交叉核对。

本篇不写什么

• 未跑的丢包率、pps、CPU% 排行。
• 把 0.44.0 容器 iterators 故障写成 0.44.1 仍存在的缺陷。
• 规则语言求值细节（第 6 篇）；sink 背压全集（第 8 篇）。
• 伪造 metrics 时间序列。

参考资料

规范 / 官方文档 / 源码（A）

• falco.yaml @ tag 0.44.1：buf_size_preset、cpus_for_each_buffer、drop_failed_exit、disable_iterators、syscall_event_drops、metrics.kernel_*
• Falco 0.44.0 Changelog / blog（BPF iterators；10.2.0+driver；metrics.kernel_iter_event_counters_enabled）
• Falco 0.44.1 Release Notes（禁用 iterators；libs 0.25.4 修复）
• Falco Kernel Events / Kernel Events Architecture（双驱动与捕获边界）
• falcosecurity/libs drivers 10.2.0+driver（iterators 相关能力）

站内对照

• 第 2 篇 · 双引擎
• 第 4 篇 · libsinsp
• 第 1 篇 · 五轴
• PLAN.md §九篇 05

学术谱系（A）

• McCanne & Jacobson, The BSD Packet Filter, USENIX Winter 1993（内核过滤与用户态协作的代价模型入口）
• Garfinkel, Traps and Pitfalls…, NDSS 2003（状态不全时的误判）

上一篇：libsinsp：状态富化与用户态进程树

下一篇：规则语言与引擎