Tetragon 默认不抓 shell 子进程，因其仅监听 execve 系统调用且不追踪 fork/clone；内置命令不触发 execve，fork 出的子进程直接“隐身”。
为什么 tetragon 默认不抓到 shell 启动的子进程？
因为 Tetragon 的默认策略只监听 execve 系统调用，而很多 shell（如 bash、zsh）在执行简单命令时会用 fork+execve，但若命令是内置命令（如 cd、echo），根本不会触发 execve；更关键的是，Tetragon 的 eBPF 探针默认不追踪 fork 或 clone，所以父进程一 fork，子进程就“隐身”了。
实操建议：
- 启用
process-exec+process-fork双探针：在 Tetragon 配置中显式开启process_fork事件采集，否则所有 fork 出的子进程（包括 shell 子 shell、后台作业、nohup进程）都会漏掉 - 注意内核版本兼容性：
process_fork在 Linux 5.14+ 才稳定支持，5.10 LTS 内核需打 backport 补丁或升级内核，否则日志里只有execve，没有pid/ppid关系链 - 避免用
shell_exec类高阶抽象 API——Tetragon 不解析 shell 语法，它只看系统调用，echo $(date)这种命令只会记录一个execve("/bin/sh", ...)，不会展开子命令
tetragon-cli getevents 返回空，但 ps 明明看到进程在跑
不是没发生，是事件被过滤掉了。Tetragon 默认只上报匹配当前加载策略（policy）的事件，且默认策略往往只关注高危行为（如写入 /etc、绑定特权端口），普通 ls、cat 不触发任何规则，自然不输出。
实操建议：
- 临时绕过策略，用
tetragon-cli getevents --output-mode=raw查原始事件流，确认底层是否真有数据（比如能看到execve但没匹配 policy） - 检查策略中
process.exec.file.path的匹配逻辑：用"/bin/*"比"/bin/bash"更容易捕获，但注意 glob 不支持正则，"*sh"是无效的 - 别忽略 namespace 隔离：容器内进程的
mount_ns和pid_nsID 在 host 视角下不同，策略里若写了namespace.pid == 42，得先用tetragon-cli getnamespaces确认实际值
如何让 Tetragon 输出完整的命令行参数（argv）而不是只显示二进制路径？
Tetragon 默认只记录 process.exec.file.path（即 argv[0]），不自动采集整个 argv 数组——这是性能权衡：完整 argv 需额外内存拷贝和字符串解析，在高频 exec 场景下开销明显。
实操建议：
- 在策略 YAML 中显式声明
process.exec.args: true，否则tetragon-cli永远只显示"/usr/bin/curl"，看不到后面跟的 URL - 注意长度截断：eBPF 栈空间有限，
args默认最多取前 64 字节（含空格），超长参数会被截断；可通过编译 Tetragon 时调整BPF_MAX_ARG_STRLEN宏，但 >128 字节易触发 verifier 拒绝 - 敏感参数风险：开启
args后，密码、token、API key 可能随命令行泄露到日志，生产环境务必配合日志脱敏策略（如用process.exec.args+ 正则过滤）
用 libbpf 加载 Tetragon 的 eBPF 程序失败，报 invalid indirect read from stack
这是典型的 eBPF verifier 报错，不是 Tetragon bug，而是你手动修改了 Tetragon 的 BPF 源码（比如加了自定义字段或调试打印），但没遵守 libbpf 的栈访问规则：eBPF 不允许从栈上读取未初始化或越界的内存，尤其在结构体嵌套或数组访问时极易触发。
实操建议：
- 别直接改
process.bpf.c里的struct process_event大小——verifier 对栈变量大小极其敏感，加一个char cmdline[256]就可能超限；优先用bpf_probe_read_str()动态读，而非静态分配大数组 - 验证修改前先跑
make -C bpf clean && make -C bpf，确保生成的.o能被bpftool prog load成功加载，而不是等 Tetragon 启动时报错 - 用
bpftool prog dump xlated看反汇编，定位哪条指令触发了invalid indirect read——通常出现在*(u32*)(r10 - 128)这类栈偏移计算错误的地方
真正难的不是写策略，是理解 Tetragon 的事件模型和 eBPF verifier 的边界在哪里。很多人卡在“为什么我加了一行代码就不加载了”，其实问题不在那行代码，而在它改变了栈布局或内存访问模式。
