【Falco】排障坐标系：五轴否证与双引擎证据包
内容提要
本文介绍Falco 0.44.1排障方法，核心是“先点名轴，再下钻模块”。五轴包括：驱动加载、libscap协商、libsinsp富化、规则引擎、输出与丢事件。排障时需按引擎（modern_ebpf或kmod）分列证据，一次否证一轴，避免误改规则或重装。常见问题如无告警、规则静默、字段为空等，需对应检查驱动、协商、富化或输出，并区分Falco与Tetragon的因果，不混用证据。
延伸解读
先点名轴，再下钻模块
排障时先明确问题属于五轴中的哪一轴，再深入对应模块。例如，DaemonSet Ready 但无告警，优先检查驱动加载（轴1）或协商（轴2），而不是直接重装或改规则。一次只否证一轴，避免将可恢复的轴2问题放大成双故障。
双引擎证据分列
modern_ebpf 和 kmod 在轴1、轴2及部分轴5的排障证据不同，必须分列。例如，modern_ebpf 需检查 BTF、ringbuf 和特定 CAP，而 kmod 需检查 .ko 加载和签名。auto 回退时需确认实际引擎。混用证据会导致误判。
区分 Falco 与 Tetragon 的因果
Falco 的“无告警”不能用 Tetragon 的 collectionKey 解释，Tetragon 的 JSON allow/deny 也不能用于 Falco 的 HTTP sink。两者可同节点运行，但证据包不可混贴。需要强制执行时，应转向 Tetragon，而非在 Falco 五轴中“加一条阻断”。
Q&A
Falco 排障时，为什么强调“先点名轴，再下钻模块”？
因为不同症状对应不同的故障轴，先确定是驱动加载、libscap协商、libsinsp富化、规则引擎还是输出丢事件，再针对该轴检查具体模块，可以避免盲目重装或改规则，防止将可恢复的问题放大成双故障。
Falco 进程在跑但完全没有 syscall 事件，应该优先检查哪个轴？
优先检查轴2（libscap协商）或轴1（驱动加载）。先确认驱动是否真正加载，API/Schema版本是否匹配，不要直接断定“没有攻击”。
Falco 中 modern_ebpf 和 kmod 引擎在排障时有什么不同？
modern_ebpf 需要检查 BTF/ringbuf 可用性、CAP_SYS_BPF 等权限、sysfs/tracefs 挂载；kmod 需要检查 .ko 是否加载、签名/DKMS、完整特权。auto 回退时还要确认实际使用的引擎。排障时证据包必须标明引擎类型。
Falco 升级后“什么都没有”可能是什么原因？
可能是用户态与驱动版本不匹配（如用户态 0.44.x 但驱动仍是 0.43 世代），导致 libscap 协商 API/Schema 版本失败。应先确认用户态与驱动是否成对，而不是检查规则语法。
Falco 规则在实验机响但在集群不响，可能是什么原因？
可能是富化字段为空（如 fd.name、container.id 等），或条件依赖的上下文缺失，属于轴3问题；也可能是规则条件永假、异常过宽或优先级阴影，属于轴4问题。需要分别检查 libsinsp 状态和规则求值。
Falco 引擎已命中但 SIEM 没有收到告警，应该检查什么？
应检查轴5输出与丢事件：确认 sink 是否仍指向 gRPC（0.44 起 gRPC output/server 已不存在），检查输出配置和下游可达性，以及是否有背压或丢事件（如 buf_size_preset 设置）。
Falco 和 Tetragon 的排障五轴有什么区别？
Falco 的五轴是 Driver → libscap → libsinsp → 规则引擎 → 输出/丢事件，主要解决检测告警缺失或噪声；Tetragon 的五轴是血缘/Hook/策略加载/过滤分层/强制执行，主要解决策略和导出问题。两者不能混用证据，Falco 的“无告警”不能用 Tetragon 的 collectionKey 解释。
