如何在K8s中使用heaptrack剖析长期运行的C++ gRPC服务

从现有进程输出和配置判断，heaptrack提前终止采集是两个明确原因导致的：

• 进程生命周期绑定错误：ps输出显示PID1为/bin/sh /usr/bin/heaptrack ./grpc_server，说明heaptrack实际被shell包装层托管，没有直接作为1号进程运行。heaptrack默认的启动追踪逻辑在fork出grpc_server子进程后，会误判追踪任务结束，仅完成初始2秒的基础数据采集就直接退出，没有持续附着到长运行的服务进程上。
• 容器权限不足：GKE默认的容器安全策略会拦截ptrace系统调用，heaptrack依赖ptrace注入内存分配钩子、持续采集分配堆栈，缺少对应权限时，注入后的追踪逻辑无法持续运行，会直接终止采集流程。

1. 镜像构建调整 #

不要默认把heaptrack作为服务启动入口，避免每次服务启动都自动采集无效的启动阶段数据，同时补全符号表依赖保证堆栈可解析：

FROM ubuntu:20.04
# 原有编译、依赖安装逻辑保留
RUN apt-get update && apt install -y --no-install-recommends \
    heaptrack \
    libc6-dbg \
    libstdc++6-10-dbg \
    # 按需安装gRPC、业务依赖对应的dbg符号包
    && rm -rf /var/lib/apt/lists/*
# 原有服务二进制拷贝、配置逻辑保留
# 默认直接启动服务，不挂载heaptrack
ENTRYPOINT ["./grpc_server"]

2. K8s部署配置调整 #

必须放开ptrace相关权限，否则heaptrack无法正常附着进程：
在容器配置段新增securityContext字段，修改后的Deployment配置核心段如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: grpc-server
        image: grpc_server_container_repo
        # 新增安全上下文配置
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE
          seccompProfile:
            type: Unconfined
        resources:
          requests:
            memory: "54Gi"
            cpu: "14"
          limits:
            memory: "64Gi"
            cpu: "16"
        ports:
        - name: grpc
          containerPort: 8080

注意：GKE 1.22+版本默认使用Container-Optimized OS节点，默认seccomp规则会拦截ptrace调用，必须添加上述配置才能让heaptrack正常工作。

3. 运行时采集操作 #

推荐等服务完全启动、运行稳定后再手动附着采集，避免启动阶段的内存分配数据干扰业务问题排查：

1. 服务部署就绪后，执行命令进入容器：
   kubectl exec -it <实际Pod名称> -c grpc-server -- /bin/bash
2. 查询grpc_server进程的PID：
   pidof grpc_server
   由于修改了ENTRYPOINT为直接启动服务，此时返回的PID一般为1。
3. 启动heaptrack附着到目标进程开始采集：
   heaptrack -p <上一步查询到的PID>
4. 保持该终端会话运行，正常发起业务请求、压测，复现你要排查的内存问题。
5. 采集完成后，在heaptrack运行的终端按Ctrl+C终止采集，heaptrack会自动将全周期采集的数据flush到当前目录下的heaptrack.grpc_server.<PID>.gz文件，使用kubectl cp将该文件拷贝到本地，即可用heaptrack_gui打开分析。

常见踩坑说明 #

• 如果必须从服务启动阶段就开始采集，要确保ENTRYPOINT使用纯exec格式，不要被shell包装：直接写ENTRYPOINT ["heaptrack", "./grpc_server"]，不要加sh -c前缀，同时必须配置上述securityContext权限。但这种方式会采集大量服务初始化阶段的内存分配数据，不推荐用于业务运行期的内存泄漏、内存占用问题排查。
• 如果执行heaptrack附着时提示权限错误，进入容器执行cat /proc/self/status | grep CapEff，核对返回的capabilities掩码是否包含SYS_PTRACE对应的权限位，确认securityContext配置生效。
• 不需要在容器内安装heaptrack-gui，采集完成后将gzip压缩的结果文件拷到本地分析即可，避免浪费容器资源。

内容的提问来源于stack exchange，提问作者demalegabi