进程端口容器溯源

要解决的问题

排障时最让人恼火的场景：某个端口突然被占用、一个陌生进程吃满 CPU、一个不认识的容器凭空出现在节点上。第一反应通常是 kill -9，但过不了多久它又回来了——因为只杀死了“结果”，没有回答“是谁启动的”。

进程端口容器溯源（witr） 把排障的第一问固定为：这玩意儿是谁启动的。它用一套称为 witr 的溯源思路，把翻 ps 树、猜父进程、对着 docker inspect 发呆的体力活，压缩成一条聚焦父链与启动上下文的排查路径。

核心能力

技能围绕四类溯源对象工作：

• 进程：某个 PID 属于谁、父进程是谁、用什么命令启动的
• 端口：哪个进程在监听，它又是谁拉起来的
• 容器：容器对应哪个 Compose 编排或父进程
• 文件：某个文件正被哪个进程持有或写入

标准流程分四步：

1. 发现异常（CPU 飙高 / 端口占用 / 陌生进程）
2. 用 witr 拉出完整父链与启动上下文
3. 判断是预期服务还是异常（入侵 / 泄漏）
4. 根治：修配置、限权限，而不是只 kill

适用边界与注意点

• 溯源完成后对照清单检查：父链账户是否可信、启动命令与预期是否一致、容器是否来自已知编排、异常是否需安全响应
• 常见陷阱：只 kill 不溯源导致反复出现；误杀系统关键进程引发雪崩；忽略容器与宿主关系导致看不全
• AI 输出以官方为准；涉及疑似入侵等安全事件时，请按公司安全响应流程处置，必要时先隔离再排障