【Falco】规则加载与 falcoctl：默认集、远程与热加载边界
内容提要
本文介绍Falco 0.44.1规则加载机制，核心是规则文件如何进入进程及热更新边界。规则来源包括包内快照、本地挂载和falcoctl OCI分发，均需在rules_files中声明。加载失败表现为启动报错、规则缺失或行为未更新。热加载由watch_config_files控制，关闭时可用SIGHUP触发。falcoctl只负责落盘，不自动进入内存，需区分文件加载与字段富化问题。
延伸解读
规则加载链路：从文件到内存的每一跳
规则要生效，必须经过“文件落盘→rules_files声明→引擎解析”三步。falcoctl只负责把OCI工件写到磁盘，不会自动让Falco加载；Helm的follow开关也只管更新文件，不保证进程内规则已刷新。若只盯着OCI digest变化就判定“规则已更新”，容易在审计中留下假阳性。排障时应先确认文件是否在rules_files指向的路径，再检查热加载是否触发。
热加载的边界：watch_config_files与SIGHUP
Falco 0.44.1中，watch_config_files: true时，Falco会监视配置和规则文件变更并自动reload；若关闭，则需用SIGHUP手动触发（如kill -1 $(pidof falco)），或直接重启服务。热加载能保留libsinsp状态表，而完整重启会清空进程/FD上下文，短期内可能出现富化空洞。注意：监视只针对rules_files已声明的路径，falcoctl落到未引用目录时，监视再灵敏也不会加载。
默认规则集的覆盖陷阱
发行包自带的falco_rules.yaml会随版本覆盖，自定义逻辑若写进去，升级后可能“规则消失”。正确做法是把本地覆盖放在falco_rules.local.yaml、rules.d或独立artifact中。rules_files按字母序加载目录内YAML，后文件可override，因此10-base.yaml与99-local.yaml的命名会变成事实上的优先级协议，应写入变更规范。
Q&A
Falco 0.44.1 中，规则文件有哪些来源？它们都需要在 rules_files 中声明吗？
规则文件来源包括包内/镜像快照、本地挂载/ConfigMap、以及 falcoctl 从 OCI 拉取的 artifact。无论哪种来源，都必须出现在 rules_files 中，Falco 才会加载。
falcoctl 拉取规则后，Falco 会自动加载新规则吗？
不会。falcoctl 只负责将规则文件落盘，Falco 进程是否加载取决于 rules_files 是否指向该路径，以及热加载配置（watch_config_files 或 SIGHUP）是否生效。
Falco 热加载规则的方式有哪些？
Falco 0.44.1 支持两种热加载方式：开启 watch_config_files: true 自动监视并重载；或关闭该选项后，通过发送 SIGHUP 信号（如 kill -1 $(pidof falco)）手动触发重载。
为什么磁盘上已有新规则文件，但 Falco 行为仍是旧规则？
可能原因：rules_files 未指向新文件路径；热加载未开启或未触发；多副本未同步；或 falcoctl 落盘目录未被 rules_files 引用。需按加载链路逐项排查。
Falco 中 falco_rules.yaml 和 falco_rules.local.yaml 有什么区别？
falco_rules.yaml 是随软件版本覆盖的默认规则文件；falco_rules.local.yaml 仅在不存在时创建，用于本地覆盖，不会被包更新冲掉。自定义规则应放在 .local 文件或 rules.d 目录。
Falco 加载规则文件时，目录内文件的加载顺序是怎样的？
目录内按字母序加载 .yml 和 .yaml 文件。加载顺序影响覆盖关系：后加载的文件可以 override 先加载的规则，因此命名如 10-base.yaml、99-local.yaml 可控制优先级。
Falco 中 plugin 规则源与 YAML 规则文件的关系是什么？
Plugin（如 container、k8smeta）扩展的是字段和事件源，不是替代 rules_files 的规则加载方式。安装了 plugin 不等于规则已加载，两者是不同维度，排障时需区分。
