sysdig 实时查看容器进程父子关系需用 -p "%proc.ptid %proc.pid %proc.name" container.id=%cid 对齐输出，否则顺序错乱无法识别；必须过滤容器 id，避免混入宿主机进程；proc_tree 不反映真实 fork 关系，易漏短命进程。
sysdig 怎么实时看到容器里所有进程的父子关系
直接用
sysdig -p "%proc.ptid %proc.pid %proc.name" container.id=%cid</p> <p>关键不是加 <code>-l或翻文档，而是得让
%proc.ptid 和 %proc.pid 对齐输出——否则你根本分不清谁是父、谁是子。默认输出里进程名在前、ID 在后，顺序错乱就白看了。
- 必须加
container.id=%cid过滤，否则混着宿主机进程一起刷，一眼看不出归属 - 别信
sysdig -c proc_tree：它只按启动时间排，不反映真实 fork 关系，容器里常有短命进程漏掉 - 如果想固定观察某个容器，先
docker ps | grep xxx拿到CONTAINER ID，再代入%cid，别图省事用container.name——名字带下划线或特殊字符时会匹配失败
用 sysdig 抓容器的实时网络连接，为什么 netstat 看不到的连接它能抓到
因为 sysdig 是从系统调用层（connect、accept、bind）抓的，不是读 /proc/net。只要进程调了这些 syscall，哪怕 socket 立即 close、还没来得及进 netstat 的表，sysdig 也能记一笔。
- 最简命令：
sysdig -p "%evt.time %container.name %proc.name %fd.name" "evt.type=connect or evt.type=accept and container.id=%cid" -
%fd.name会显示10.244.1.5:42892->10.244.2.3:8080这种格式，注意箭头方向：左边是本端，右边是远端 - 别漏掉
evt.type=accept——很多服务（如 nginx）是父进程 accept 后 fork 子进程处理，只抓connect会漏掉服务端视角 - 如果看到大量
UNKNOWN替代%container.name，说明该事件发生在容器启动前或退出后，检查container.id是否还存活
sysdig inspect 输出里 container.id 和 k8s.pod.name 对不上怎么办
不是数据错了，是 sysdig 默认不自动关联 Kubernetes 元数据。它能读到 container.id，但 pod 名、namespace 这些得靠 -k 参数连 kube-apiserver 才行，本地离线跑肯定为空。
- 线上集群必须加
-k https://<kube-apiserver>:6443 -K /path/to/kubeconfig</kube-apiserver>，否则k8s.*字段全是空 -
container.image有时显示镜像 ID 而非 tag，是因为容器运行时没传--image标签，或者用了 buildkit 构建——这时得结合docker inspect <cid> | grep Image</cid>反查 - 遇到
container.id显示为host，说明该事件属于宿主机进程（比如 CNI 插件），不是容器内进程，别强行往 pod 上套
为什么 sysdig 实时视图卡顿、丢事件，而 top 却很流畅
因为 sysdig 默认把所有事件塞进内存缓冲区再格式化输出，一旦事件速率超过终端刷新能力（尤其开 -p 自定义模板时），就会堆积、延迟甚至丢弃。这不是机器性能问题，是输出路径瓶颈。
- 加
-n 1000限制总事件数，或用-F强制 flush 每条输出（适合管道进grep） - 避免在
-p里写复杂条件嵌套，比如"%if (container.id != \"\") then ... else ..."，解析开销大，直接用 shell 过滤更稳 - 真要长期监控，别用
sysdig -p直连终端，改用sysdig -w trace.scap录下来，再用sysdig -r trace.scap -p "..."回放
真正麻烦的是事件时间戳精度——sysdig 用的是内核 ktime_get_real_ts64，在虚拟机或开启 TSC 不稳的 CPU 上，两个连续事件可能时间倒流，这时候按 %evt.time 排序反而误导人。
