【Falco】输出面：sink 白名单与 gRPC 删除门

规则引擎命中之后，告警还必须离开进程。本篇钉输出轴：0.44.1 仍承认哪些 sink、gRPC output 为何绝不能再写进 runbook、背压失败长什么样，以及如何与第 5 篇的驱动/缓冲 drop 分列证据包。

输出轴的误判成本很高：安全同事看见 SIEM 空窗，会写成「本周无运行时告警」；平台同事看见节点 CPU 升高，会去调 buf preset。两边都可能对，也可能都错——若 stdout 已有命中而 HTTP 无，问题在接线；若任何 sink 都无且 drop 在涨，问题在捕获。本篇提供把这两种故事拆开的词汇表。

不写 Splunk/ELK 逐步截图，不把已删除的 gRPC 写成当前能力。读完应能：列出 0.44.1 sink 白名单、指出 gRPC 删除的版本门、并用一张表区分队列背压与驱动 drop。

本篇在系列中的位置

篇目	核心内容
第 7 篇 · 规则加载与 falcoctl	规则如何进入进程
第 8 篇 · 输出面	sink 白名单、gRPC 删除门、背压
第 9 篇 · Plugin 框架	container / k8smeta 与主路径
系列目录	关键问题、阅读路径、全部价值点

版本锚定：Falco 0.44.1。输出通道以 tag falco.yaml 中 Stable 块为准。0.44.0 Changelog / blog / PR #3798：drop gRPC output and server support——grpc_output 与 grpc 顶层配置及整条 gRPC 代码路径已删。迁移方向官方写明：HTTP output 或 Falcosidekick 等转发，而不是「继续找 gRPC 开关」。

一、stdout / file / http 等配置面

tag 0.44.1 将下列通道标为 Stable，可同时启用多个：

格式层还有 json_output 等开关：把同一告警变成 JSON 行，供 webhook / 侧车消费。append_output（Sandbox）可按规则/源/标签追加字段，不改变「通道是否存在」这一白名单问题。多通道并行时，任一通道失败不应被解读成引擎未命中——先在最简单的 stdout/file 上确认命中，再查 http/program。

stdout_output:
  enabled: true

http_output:
  enabled: true
  url: "http://falcosidekick:2801/"

上例只示范键位；URL、证书与侧车拓扑须按环境核对，本文不提供未实测的联调记录。program_output 的 keep_alive 决定是每条告警 fork 一次还是长管道写入；长管道场景下缓冲与信号处理更敏感，官方文档对 SIGTERM 与缓冲关闭有专门提醒——部署前应读 tag 文档对应段落，而不是从旧 blog 抄管道示例。

二、gRPC output 已删（版本门）

官方 Introducing Falco 0.44.0 写明：去掉 grpc_output、grpc、整条 gRPC 路径及仅为其引入的 c-ares 依赖。Helm chart BREAKING-CHANGES 同步：不得再设 falco.grpc.enabled / falco.grpc_output.enabled。弃用周期从 0.43 的警告走到 0.44 的删除，中间若有人「暂时忽略警告」，升级日就会变成静默断流。

升级后门的经典表象：引擎侧其实在命中（若仍写文件或 stdout 能看见），但旧 gRPC 客户端侧永久空窗——容易被写成「Falco 没检测到」。这是输出轴版本门，不是规则条件问题。修复动作是改接线，不是改 condition。

本系列后文（第 12 篇）会把 gRPC 删除与 legacy eBPF、gVisor engine 并列进破坏性清单；本篇只要求：任何 0.44.1 部署清单若仍出现 gRPC sink，视为文档债务，直接改接白名单通道。站内旧笔记、第三方 Terraform module、复制粘贴的 values.yaml 都是常见藏身处——升级检查单应显式 grep grpc。

三、背压与失败表象

输出路径上至少两层缓冲语义（tag falco.yaml 注释）：

1. outputs_queue：规则引擎与各 output channel 之间的队列（基于 TBB concurrent bounded queue）。capacity: 0 表示无界；设上限后队列满时丢当前事件并继续事件循环——注释明确类比内核侧 buffer 满时的 drop。无界队列在注释里的风险是内存耗尽后进程被 OOM kill；有界队列的风险是静默丢告警。二者都不是「规则变少了」。
2. buffered_outputs：作用于支持缓冲的 channel 实现（注释点名 file_output、program_output、stdout_output）。关闭则每条告警刷缓冲，CPU 更高；开启则 tail 日志时可能看到长时间延迟（官方 Output Channels 亦提示可用 --unbuffered / -U）。把「日志很久才出现」写成「检测延迟几十秒」之前，应先排除这一层用户态缓冲。

http_output 另有连续超时等参数；下游慢或不可达时，失败落在「已格式化告警送不出去」，与「规则未命中」不同。HTTP 通道与 stdout 同时开启时，应用「stdout 有、HTTP 无」作为输出轴烟测，而不是一上来重装驱动。侧车未就绪、NetworkPolicy 丢包、证书校验失败，都属于输出轴，证据在连接与 HTTP 状态，不在规则 YAML。

无环境则不伪造队列深度或 http 状态码；只保留上述配置语义。有环境时，应先用最小 stdout 证明引擎命中，再逐个打开下游通道——这是输出轴的二分法，对应第 1 篇「先点名轴」口诀在 sink 层的落地。

四、与轴 5 丢事件的区分

五轴里「输出与丢事件」常被写成一条，排障时必须拆开：

若 stdout 已打印命中，却无下游——优先本篇。若任何 sink 都无、且 drop 在涨——优先第 5 篇，再回指轴 1–2 是否根本无原始事件。把两类计数画在同一张「Falco 丢了」图表上而不加标注，会让值班在错误层上调 buf preset 或乱改 http URL。

监控设计上的最低要求：输出轴至少能回答「引擎命中计数」与「各 sink 成功/失败」是否同向；捕获轴至少能回答 drop 是否在涨。两者缺一，就无法完成第 13 篇排障坐标系要求的分列证据包。

五、下游只接到仍存在的 sink

0.44.1 白名单（概念表，键名以 tag 为准）：

响应自动化、工单、SOAR 属于第 15 篇边界：本系列承诺到「告警进入仍存在的 sink」；不写具体 SIEM 产品菜谱。Falcosidekick 等转发器是下游适配层，不是 0.44.1 重新发明的 gRPC 替代协议——它们通常消费 HTTP/stdout，再扇出到聊天或工单系统。

开放问题：无界 outputs_queue 在内存压力下的 OOM 风险，与有界队列主动丢告警之间，哪一侧应成为默认生产建议——以你们威胁模型与节点内存配额为准，本篇只要求显式选择并与第 5 篇 drop 分列监控。无论选哪侧，都要把「丢告警」写进事故定义，避免只有内核 drop 被人看见、用户态 queue drop 无人认领。

本篇不写 Splunk/ELK/SOAR 逐步菜谱、不复活 gRPC sink、不做未测吞吐或 CPU% 排行；驱动缓冲细节回第 5 篇，响应生态边界见第 15 篇。

参考资料

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

• Falco 0.44.1 falco.yaml：stdout_output / syslog_output / file_output / http_output / program_output；buffered_outputs；outputs_queue
• Falco Output Channels
• Falco 0.44.0 Release Notes / Changelog：chore!: drop gRPC output and server support（#3798）
• 官方 blog Introducing Falco 0.44.0（迁移到 HTTP 或 Falcosidekick）
• falcosecurity/charts BREAKING-CHANGES.md：Dropped gRPC output and server

站内对照（A/B）

• 第 5 篇 · 丢事件；第 1 篇 · 五轴；PLAN.md §七.1、§九 · 08

上一篇：规则加载与 falcoctl

下一篇：Plugin 框架