【Falco】规则语言与引擎：条件、优先级与异常
内容提要
本文讨论Falco规则引擎的求值机制与失败模式，聚焦条件、优先级、异常三方面。核心观点：规则不告警常因条件字段为空或异常过宽，而非规则未加载；优先级不决定求值顺序，仅标定严重程度；排障应先验证事件进入引擎且字段非空，再调整规则。
延伸解读
条件为假与字段空：排障的关键区分
规则不告警时，常见误区是直接怀疑驱动或规则未加载。但若 `falco -L` 能列出规则，说明规则已加载，此时应优先检查条件左侧字段是否为空或未被富化。例如，依赖 `container.*` 字段的规则在插件未加载或元数据不可达时，条件会静默为假，表现为“测试机命中、集群不命中”。排障时应先验证事件进入引擎且字段非空，再调整规则，避免在错误层空转。
优先级不决定求值顺序
`priority` 仅标定告警严重程度，用于下游路由和 syslog 优先级，并不影响规则求值顺序。规则按加载顺序和 `rule_matching` 模式（`first` 或 `all`）决定匹配。将优先级从 WARNING 改为 CRITICAL 不会让后加载的规则压过先加载的宽规则。若两条规则都能匹配同一事件，只看到第一条的名字，应检查 `rules_files` 顺序和 `rule_matching` 设置，而不是调整优先级。
异常过宽：静默吞掉真实告警
`exceptions` 用于在条件为真后进一步过滤告警，但若异常元组维度过宽（如仅用进程名或镜像名），可能将真实恶意行为一并放行。官方建议同时约束 actor、action、target（如进程+路径），避免只写单一维度。运维中通过 `append` 叠加例外时，应审查例外元组是否仍包含 target，而不是只看 diff 行数。异常过宽是“已知恶意模式仍静默”的常见原因，调参时应收紧维度而非关闭整条规则。
Q&A
Falco 规则不告警，但规则文件已加载，可能的原因是什么？
规则不告警但已加载，常见原因是条件字段为空或异常过宽，导致条件静默为假或告警被异常吞掉。应先验证事件进入引擎且字段非空，再调整规则。
Falco 中 priority 字段的作用是什么？它影响规则求值顺序吗？
priority 字段标定告警严重程度，供下游路由和 syslog 使用，不决定规则求值顺序。规则求值顺序由加载顺序和 rule_matching 决定。
Falco 的 rule_matching 有哪几种模式？分别有什么特点？
rule_matching 有 first 和 all 两种模式。first 模式按文件定义顺序求值，第一条命中即停；all 模式继续匹配同事件的其余规则，但可能有性能代价。
Falco 的 exceptions 机制是什么？使用时需要注意什么？
exceptions 是规则作者声明的白名单，通过 fields/comps/values 元组从事件取值，命中则不告警。使用时应注意约束 actor、action、target 等维度，避免过宽导致检测失效。
Falco 中 append: true 的作用是什么？使用时有什么风险？
append: true 用于在已有规则或宏上追加条件或异常，而不是整条覆盖。风险是后加载的 append 若写得过宽，会静默扩大白名单，可能削弱检测能力。
Falco 规则中字段为空时，条件求值结果如何？
字段为空或类型不符时，条件求值结果恒为假，导致规则不告警。这是常见失败模式，应通过验证字段富化情况来排查。
Falco 中 Macros 和 Lists 的作用是什么？
Macros 用于命名可复用的条件片段，避免重复；Lists 是值集合，必须被宏或条件引用。它们帮助组织规则，提高可维护性。
