上一篇咱们聊了为什么要dump不少兄弟可能会问“现场怎么抓 Dump特别是生产环境的 Linux 容器不敢乱东西怕把服务搞挂了。”这问题问到点子上了。抓 Dump 就像给病人抽血化验时机、手法、样本类型缺一不可。今天这篇我就把压箱底的实战经验掏出来从 Windows 到 Linux 容器手把手教你安全、完整地抓取 Dump。少踩坑多干活。一、Linux 容器环境稳字当头在 Linux 上抓 Dump尤其是 Docker 容器里核心原则就一个能不装新软件就不装能复用运行时自带的工具就复用。生产环境不是你的测试机多一个依赖就多一分风险。1. 锁定“嫌疑人”精准找到问题进程抓 Dump 第一步得先知道抓谁。别上来就kill或者乱grep咱们要优雅。️ 官方推荐dotnet-trace ps如果你已经装了dotnet-dump或dotnet-trace工具这是最稳的方式# 安装工具如果还没装 dotnet tool install --global dotnet-dump dotnet tool install --global dotnet-trace # 列出所有 .NET 进程 dotnet-trace ps⚠️ 老炮儿提醒dotnet-trace ps依赖/proc文件系统。如果容器权限受限或镜像被极致裁剪可能看不到进程。这时候别慌看下面这个“野路子”。 兜底方案ps/proc组合拳当官方工具失灵或者你压根没装工具时用系统原生命令#查看所有.net进程 ps aux | grep dotnet # 查找高 CPU/内存的 dotnet 进程 ps -eo user,pid,%cpu,%mem,vsz,rss,stat,etimes,command | \ awk { if (($3 0 || $4 0) ($5 0 || $6 0)) { print $0 } } | \ grep dotnet为什么这么写%cpu / %mem过滤掉僵尸进程和空跑进程。vsz / rss看虚拟内存和物理内存泄露的进程通常 RSS 异常高。etimes看运行时长刚启动的进程一般不是泄露元凶。如果还不确定直接进/proc/pid/看cmdline和maps这是最底层的真相。2. 容器内 Dump首选createdump这是我最推荐的方式。为什么因为createdump是 .NET Runtime 自带的不用额外安装任何东西零侵入、零风险。第一步找到createdump在哪find /usr/share -name createdump典型路径长这样/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.15/createdump⚠️ 坑点预警不同 .NET 版本路径不同别硬编码路径用find动态找或者通过dotnet --info确认运行时版本。第二步进容器抓 Dump# 进入业务容器 docker exec -it container_name bash # 抓 Full Dump关键 /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.15/createdump 1 -u -f /tmp/dump_full.dmp参数拆解别瞎用1容器内主进程 PID 通常是 1但务必用ps aux二次确认有些容器用了tini或supervisorddotnet 进程可能是 7、13 这种。-uFull Dump 的关键开关。不加这个默认是 Mini Dump里面没有托管堆和模块信息拿到 Windows 上分析就是“巧妇难为无米之炊”。-f指定输出路径。强烈建议输出到/tmp或挂载的 Volume别写到应用目录。万一磁盘满了Dump 写一半应用也挂了雪上加霜。 为什么强调-u因为 Linux 下抓的 Dump 要拿到 Windows 的 Visual Studio 或 dotMemory 分析Full Dump 会把所有托管 DLL、堆快照、线程栈都打包进去。Mini Dump 在跨平台分析时经常报“缺少符号”或“无法加载模块”排查效率直接腰斩。3. 宿主机 Dumpdotnet-dump的备选方案如果容器实在进不去或者createdump被删了只能在宿主机上抓。前提宿主机必须装 .NET Runtime别以为宿主机没跑 .NET 应用就不用装dotnet-dump依赖运行时库。# 安装 dotnet-dump dotnet tool install --global dotnet-dump # 列出可抓的进程 dotnet-dump ps # 抓 Full Dump dotnet-dump collect --type Full --process-id 1902⚠️ 跨容器 PID 陷阱宿主机看到的 PID 和容器内的 PID 不一样dotnet-dump ps列出的是宿主机视角的 PID直接用就行别手动换算容易算错。4. 终极杀招崩溃自动抓 Dump无人值守很多时候程序崩溃OOM、StackOverflow、未处理异常发生在一瞬间等你收到告警登录服务器进程早没了现场也凉了。这时候你需要自动抓 Dump让程序在“咽气”的瞬间自己给自己拍个遗照。第一步配置环境变量在启动 .NET 应用前注入以下环境变量# 开启 Mini Dump 自动收集 export DOTNET_DbgEnableMiniDump1 # 开启崩溃报告强烈推荐 export DOTNET_EnableCrashReport1 为什么要开DOTNET_EnableCrashReport开启后崩溃时除了 Dump还会生成一个.crashreport.json文件。这个 JSON 里记录了所有线程的堆栈并且会标记crash: true的线程。这简直是神器面对几百个线程的 Dump你不用一个个翻直接搜crash: true一秒钟定位到“凶手”线程。第二步容器权限配置Docker/K8s 必看在容器里抓 Dump 需要ptrace权限否则工具会报错。Docker Composeservices: app: cap_add: - SYS_PTRACEKubernetesyamlcontainers: - name: app securityContext: capabilities: add: - SYS_PTRACE⚠️ 安全提示SYS_PTRACE允许进程跟踪其他进程存在一定安全风险。生产环境建议配合网络策略和只读文件系统使用。二、Windows 环境简单但别大意Windows 下抓 Dump 确实简单但“简单”不等于“随便”。1. 任务管理器最快但有坑操作右键进程 → “创建转储文件” → 选“完整转储”。适用场景开发机、测试环境、非核心服务。⚠️ 生产环境慎用任务管理器抓 Dump 会短暂挂起进程如果进程正在处理关键事务可能导致请求超时甚至连接断开。而且它抓的 Dump 格式有时和dotnet-dump不完全兼容分析时可能报版本不匹配。2.dotnet-dump生产环境首选# 安装 dotnet tool install --global dotnet-dump # 列出进程 dotnet-dump ps # 抓 Full Dump dotnet-dump collect --type Full -p 12448优势挂起时间更短对应用影响更小。输出格式标准跨平台分析无障碍。支持--diagnostic-port可以非侵入式附加。三、老炮儿的血泪总结场景推荐工具关键参数/注意点Linux 容器内createdump-u必须加PID 务必确认输出到/tmpLinux 宿主机dotnet-dump需装 Runtime用宿主机 PID别手动换算Linux 崩溃自动环境变量DOTNET_DbgEnableMiniDump1SYS_PTRACE权限Windows 测试任务管理器快但可能挂起进程格式兼容性一般Windows 生产dotnet-dump--type Full影响最小格式标准最后唠叨三句Dump 文件大小Full Dump 可能几个 G抓之前先看磁盘空间df -h不是摆设。抓完立刻拷走别留在服务器万一磁盘满Dump 删不掉服务起不来你就成了“删库跑路”的嫌疑人。分析要趁热Dump 放久了符号文件丢了版本对不上了分析难度指数级上升。 下篇预告Dump 抓到了然后呢面对几百 MB 甚至几个 G 的文件是不是有点懵不知道用 WinDbg、dotnet-dump 还是 Visual Studio下一篇《Dump 分析工具大阅兵选对武器事半功倍》我会把市面上主流的 Dump 分析工具拉出来“遛一遛”。从轻量级的dotnet-dump analyze到功能强大的 Visual Studio再到内存分析神器 MAT帮你梳理它们各自的优缺点和适用场景。工具选得好下班下得早记得收藏下期带你挑一把最顺手的“手术刀”。