【Falco】Plugin 框架：container / k8smeta 与 syscall 主路径
内容提要
本文介绍Falco 0.44.1中plugin框架的作用：container和k8smeta插件在用户态丰富容器与K8s元数据，与syscall主路径在规则求值前合流。插件未加载时，依赖其字段的规则会静默失效，而非报错。排障需检查load_plugins、运行时套接字及metacollector连通性，而非仅看规则diff。
延伸解读
插件未加载时规则静默失效
依赖container.*或k8s.*字段的规则，在插件未加载时不会报错，而是因字段为空导致条件为假，规则静默失效。排障时不能只看规则diff，应检查load_plugins配置、插件库文件是否存在，以及运行时套接字或metacollector的连通性。
container与k8smeta依赖不同
container插件依赖节点上的容器运行时接口，而k8smeta插件依赖集群内部署的k8s-metacollector及网络可达性。只启用其中一个，却编写依赖另一个字段类的规则，会导致部分告警有元数据、部分没有，看似随机误报或漏报。
字段合流增加排障难度
syscall主路径与插件富化路径在规则求值前合流，规则条件不区分字段来源。这种透明性提高了可移植性，但也让字段空洞难以从条件文本中察觉。当集群内规则不命中而单机裸进程命中时，应优先怀疑合流侧的元数据问题，而非直接修改evt.type。
Q&A
Falco 0.44.1 中 container 和 k8smeta 插件的作用是什么？
container 插件通过容器运行时套接字等路径提取容器元数据，丰富 container.* 字段，并支撑部分 k8s.ns.name / k8s.pod.* 字段；k8smeta 插件对接独立的 k8s-metacollector，按节点粒度拉取 Kubernetes 资源元数据，导出 k8smeta.* 字段类。它们都在用户态丰富容器与 K8s 元数据，并在规则求值前与 syscall 主路径合流。
Falco 中插件未加载时，依赖其字段的规则会怎样表现？
插件未加载时，依赖其字段的规则不会报错，而是以条件为假的形式静默失效，即规则不会触发告警。
Falco 中 syscall 主路径和 plugin 路径是如何合流的？
syscall 主路径通过驱动（modern_ebpf 或 kmod）捕获事件，经 libscap 进入 libsinsp 维护状态；plugin 路径通过运行时套接字或 metacollector 获取元数据，由插件提取字段。两者在规则求值前合并到同一字段表，规则引擎不区分字段来源，只看到有值或为空。
Falco 中配置了插件但未加载的常见原因是什么？
常见原因是只修改了 plugins 块（描述可加载库与 init_config），却忘记在 load_plugins 中列出实际启用的插件名。load_plugins 默认常为 []，需要显式开启。
Falco 中 container 和 k8smeta 插件的依赖有何不同？
container 插件依赖节点上可见的容器运行时接口（如运行时套接字）；k8smeta 插件依赖集群内部署的 k8s-metacollector 及网络可达性。只启用其中一个，而规则依赖另一个的字段，会导致部分告警有元数据、部分没有，看起来像随机误报/漏报。
Falco 中插件加载报错、进程拒绝启动的可能原因是什么？
可能原因是插件库文件路径错误、插件 ABI 与 Falco 用户态版本不匹配，或插件依赖的库缺失。这类失败通常发生在启动加载阶段，而不是运行期偶发无告警。
Falco 中如何排查规则不命中但怀疑元数据缺失的问题？
建议按顺序核对：load_plugins 是否包含所需插件；插件库文件是否存在于容器；运行时套接字或 metacollector 网络策略是否正常；规则是否依赖仅在 k8smeta 启用后才存在的字段类。不要只 diff 规则 YAML。
Falco 中 k8saudit 插件与 container/k8smeta 插件有何区别？
k8saudit 是审计日志事件源插件，用于处理 Kubernetes 审计日志事件；container/k8smeta 是 extractor 类插件，用于丰富 syscall 事件的元数据。如果目标只是规则里写 k8s.pod.name，应先核对 container 插件与运行时套接字，而不是默认部署审计 webhook。
