【Tetragon / eBPF】事件导出路径：JSON、gRPC、tetra 与过滤边界
内容提要
Tetragon v1.7.0事件导出支持JSON文件、gRPC和管道三种路径。allow/deny过滤仅作用于JSON文件，不影响gRPC；field filter按客户端裁剪字段，redaction在进程缓存中修改参数。默认JSON路径为/var/run/cilium/tetragon/tetragon.log。排障时需区分各sink的过滤差异。
延伸解读
过滤边界：JSON 与 gRPC 的可见性差异
v1.7.0 中，allow/deny 名单仅作用于 JSON 文件导出，不影响 gRPC 流。这意味着通过 tetra CLI 直接连接 gRPC 时，仍会看到未被名单过滤的事件。排障时需先确认命令是否通过管道读取 JSON，否则可能误判事件缺失原因。
field filter 与 redaction 的全局影响
field filter 按客户端裁剪字段，JSON 导出配置后文件缺字段，但独立 gRPC 客户端若不携带相同 filter 则仍见完整字段。redaction 在进程缓存构造时修改参数和环境变量，因此所有 sink（包括 gRPC）都会看到打码后的内容，不能假设 gRPC 可见明文。
排障要点：区分 sink 与过滤层级
事件缺失时，先判断是文件 sink 的 allow/deny 或 field filter 导致，还是内核 selector 已丢弃。Exporter.Send 在限流时静默丢弃并计数，表象类似 denylist，但指标不同。日志文件路径默认在 /var/run/cilium/tetragon/tetragon.log，注意 Helm 可能修改位置。
Q&A
Tetragon v1.7.0 中，allow/deny 过滤是否会影响 gRPC 导出的事件？
不会。allow/deny 过滤只作用于 JSON 文件 sink，不影响 gRPC 导出。即使事件被 JSON denylist 丢弃，通过 tetra CLI 使用 gRPC 时仍会看到未过滤的事件。
Tetragon 默认的 JSON 导出文件路径是什么？
默认路径是 /var/run/cilium/tetragon/tetragon.log。
Tetragon 的 field filter 如何影响 JSON 导出和 gRPC 客户端？
field filter 按 GetEvents 客户端裁剪字段。如果 JSON exporter 配置了 field filter，文件中的对象会缺少字段；独立的 gRPC 客户端除非自己带上相同的 filter，否则仍会看到完整字段。管道输入 tetra 的 JSON 已经被 exporter 裁剪，无法恢复。
Tetragon 的 redaction 功能是否只影响 JSON 导出？
不是。redaction 在进程缓存构造时修改参数和环境变量，因此 gRPC 客户端拿到的 Process.arguments 也可能被脱敏。所有 sink 共享缓存中已修改的字符串。
如何通过 tetra 命令消费 JSON 文件中的事件？
可以使用管道将 JSON 文件内容输入 tetra，例如：kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents -o compact。此时 tetra 读取的是已经过文件 sink 过滤的事件。
Tetragon 中 allow/deny 过滤的匹配逻辑是什么？
过滤规则是一行一个 JSON 对象，行与行之间是 OR 关系，同一对象内字段是 AND 关系。仅配置 allowlist 时默认拒绝；denylist 与 allowlist 同时命中时 denylist 优先。实现为 whitelist.MatchOne(ev) && blacklist.MatchNone(ev)。
Tetragon 中 redaction 的配置示例是什么？
示例：{"redact": ["--password(?:\\s+|=)(\\S*)"]}，将 --password=foo 替换为 --password=*****。也可以按二进制限制，如 {"binary_regex": ["(?:^|/)foo$"], "redact": ["-p(?:\\s+|=)(\\S*)"]}。
