在微服务架构中，Python 与 Ruby 写的服务经常被打包成容器镜像交付。当线上出现 CPU 占用异常或接口延迟陡增时，开发团队需要用 py-spy 和 rbspy 这类采样分析器快速定位热点函数。这两款工具分别面向 Python 和 Ruby，它们不依赖在代码里埋点，而是周期性读取目标进程的内存与调用栈来完成性能画像。然而容器带来的进程隔离、能力限制和文件系统封装，让原本在物理机上一条命令就能搞定的事变得复杂。本文从原理、部署和实战三个层面，说明如何让它们在容器里正常工作。
py-spy 与 rbspy 的底层采样机制差异
py-spy 利用 Linux 的 process_vm_readv 系统调用以及 ptrace 机制，直接附着到目标 Python 解释器进程，解析其内部的 PyFrameObject 结构来获取当前调用栈。因为 Python 是解释执行，解释器自身维护了完整的帧对象链表，py-spy 只需读取对应内存地址就能拿到函数名与行号，不需要目标程序配合。这种设计让它能附着到已经运行的容器进程，但也要求分析器进程具备读取目标进程内存的权限。
rbspy 面对的 Ruby 情况略有不同。Ruby 同样有解释器内部的结构体，但早期版本对多线程支持复杂，rbspy 采用定时发送 SIGURG 信号并结合 ptrace 单步或读取寄存器的方式来抓取每个线程的调用栈。较新版本则更多依赖 process_vm_readv。无论哪种路径，核心都依赖操作系统允许的跨进程内存访问。在容器里，如果目标进程在另一个 PID 命名空间，或者当前容器缺少 SYS_PTRACE 能力，这些系统调用就会返回权限错误。
理解这一点很关键：py-spy 和 rbspy 并非通过日志或代理工作，而是操作系统级的“旁观”。因此所有隔离边界都会成为障碍。下面这段伪代码展示了 py-spy 附着失败时的典型错误来源：
// py-spy 内部简化逻辑
match ptrace::attach(pid) {
Ok(_) => read_python_stack(pid),
Err(e) => eprintln!("无法附着进程 {}: {}", pid, e),
// 容器中常因 EPERM 退出
}
Docker 环境下赋予分析器必要权限
最直白的方案是在运行分析容器时添加 --cap-add=SYS_PTRACE 并共享目标容器的 PID 命名空间。例如目标服务容器名为 web-api，可以启动一个临时调试容器：docker run --rm --pid=container:web-api --cap-add=SYS_PTRACE python:3.11-slim py-spy top --pid 1。这里 --pid=container:web-api 让调试容器看到和 web-api 完全相同的进程列表，--cap-add 补回了被 Docker 默认丢弃的 ptrace 能力。
如果不想开放 ptrace，也可以采用特权模式 --privileged，但这会赋予容器几乎所有主机权限，仅建议在受信任的临时排障场景使用。对于 rbspy，同样的方式适用：docker run --rm --pid=container:ruby-svc --cap-add=SYS_PTRACE rbspy/rbspy top --pid 1。需要注意目标 Ruby 进程若以非 root 用户运行，调试容器内的 rbspy 也应以能读取该用户进程的身份执行，否则仍会被拒绝。
另一种更安全的做法是把分析器直接装进业务镜像的调试标签（tag）中，平时不运行，排障时通过 kubectl exec 或 docker exec 进入已有权限的容器内部执行。这样避免了跨容器 PID 挂载，权限边界清晰。示例如下：
FROM python:3.11-slim RUN pip install py-spy # 正常启动命令保持不动 CMD ["python", "app.py"]
构建时打两个标签，myapp:latest 与 myapp:debug，后者仅多了工具。线上仍跑 latest，出问题临时把副本镜像换成 debug 并 exec 进去执行 py-spy record -o profile.svg --pid 1。
Kubernetes 中的共享进程命名空间与排障实践
Kubernetes 默认每个 Pod 内的容器共享同一个 PID 命名空间，这本来有利于调试，但若你的目标进程在别的 Pod，就需要用 kubectl debug 创建临时排障容器并声明 target 指向目标 Pod。命令如：kubectl debug -it --image=python:3.11-slim --target=web-api --share-processes my-pod -- sh，进入后安装 py-spy 即可看到 1 号进程是目标服务。若集群启用了 Pod 安全策略限制 SYS_PTRACE，需要在排障容器的 securityContext 中显式允许。
对于 Ruby 服务，rbspy 在 Kubernetes 中的限制相同。可以在 Deployment 里为容器增加 securityContext.capabilities.add: ["SYS_PTRACE"]，但长期开放会增加攻击面。推荐做法是平时关闭，通过临时排障容器开启。下表对比两种方案的取舍：
| 方案 | 权限暴露面 | 操作复杂度 | 适用场景 |
|---|---|---|---|
| 业务容器常开 SYS_PTRACE | 高 | 低 | 内部测试集群 |
| 临时排障容器挂载 PID | 低 | 中 | 生产环境受限排障 |
| 调试镜像 exec 进入 | 中 | 低 | 单容器 Pod 快速查错 |
实际排障时，如果 py-spy 报 Permission denied，先确认 cat /proc/1/status 中 CapEff 是否含 ptrace 位；rbspy 卡住多半是信号被 seccomp 过滤，可在排障容器加 securityContext.seccompProfile.type: Unconfined。掌握这些细节，容器化后的性能分析不再束手无策。
py-spyrbspycontainer_profiling修改时间：2026-08-18 12:42:33