tetragon tracingpolicy 必须显式指定正确 symbol 或 address 才能挂载 kprobe/uprobe；kprobe 需内核导出符号且非 notrace，uprobe 需容器内带 debuginfo 的二进制及动态符号；Eventkind: trace、symbol/binarypath 等字段缺一不可，且大小写敏感、命名空间需精准匹配。
怎么让 Tetragon 的 tracing policy 正确挂到 kprobe/uprobe 上
必须明确一点：Tetragon 的 tracingPolicy 不会自动帮你找函数地址或符号，它只按你写的 symbol 或 address 去 attach。写错符号名、没开 debuginfo、内核版本不匹配——三者任一出问题，policy 就静默失效，连日志都不报。
- 用
kprobe时，symbol必须是内核导出的符号（cat /proc/kallsyms | grep do_sys_open能搜到才行），不能写sys_open这类别名 -
uprobe的binaryPath必须是容器内真实路径（比如/usr/bin/curl），不是宿主机路径；且该二进制需带调试信息（file /usr/bin/curl输出含debug字样） - Tetragon 默认只加载
/etc/tetragon/policies/下的 YAML，改完要sudo systemctl restart tetragon或用tetra apply -f policy.yaml
为什么 kprobe symbol 写对了却没触发事件
常见假阴性：符号存在，但 probe 没生效。根本原因通常是内核配置或符号可见性限制。
- 检查内核是否启用
CONFIG_KPROBES=y和CONFIG_KPROBE_EVENTS=y（zcat /proc/config.gz | grep KPROBE） - 某些符号（如
__x64_sys_openat）在较新内核中被标记为notrace，kprobe无法 attach，得换do_filp_open这类更底层且可 trace 的函数 - 使用
bpftool prog list确认 program 是否已加载；再用bpftool perf event show看对应 tracepoint 是否 active
uprobe 的 symbol 名怎么查才靠谱
别猜，也别信文档里的例子。容器里跑的进程，符号得从那个环境里实时扒。
- 进目标容器：
docker exec -it <id> sh</id>，然后装readelf或objdump - 查函数符号：
readelf -Ws /usr/bin/curl | grep ' open$'（注意结尾空格，过滤重载） - 查动态符号表（.dynsym）而非 .symtab：
objdump -T /usr/bin/curl | grep 'open'，因为 uprobe 只认动态链接符号 - 如果函数是 inlined 或编译优化掉了（比如
-O2），可能根本不出现在符号表里——这时只能退到 syscall 级别用 kprobe
tracingPolicy YAML 里哪些字段实际影响挂载成败
看似可选的字段，有些是硬性依赖。少一个，probe 就不会注册。
-
eventKind: trace是必须的，漏写会导致 Tetragon 当作普通 policy 处理，完全忽略 kprobe/uprobe 字段 -
kprobe下必须有symbol或address，二者不可同时为空；uprobe下binaryPath和symbol都不能为空 -
matchPIDs如果用了pid字段，值必须是容器 init 进程 PID（1在容器命名空间里），不是宿主机 PID；更稳妥用processName匹配 - 字段名大小写敏感：
symbol不是Symbol，binaryPath不是binarypath
最常被忽略的是符号生命周期——uprobe 绑定的进程退出后，probe 自动卸载；但若 policy 里写了 processName: curl 却没限制 Namespace，Tetragon 可能去 attach 宿主机上的 curl，而不是你预期的那个容器实例。盯住 namespace 和 containerName 字段的实际取值，比调参数重要得多。