1. 从pstack-claude这个名字说起它到底想解决什么问题第一次看到pstack-claude这个项目名我脑子里冒出来的第一个念头是这大概率是把pstack和claude两个东西拼在一起的工具。pstack在 Linux 世界里是个老牌命令用来打印进程的调用栈排查卡死、死锁、性能瓶颈时经常用而claude则是当下讨论度极高的 AI 编程助手。把这两个词捏在一起最合理的解读就是——用 AI 来辅助分析进程栈信息或者把 pstack 的输出喂给 Claude 做智能诊断。这个方向其实非常务实。做过线上排障的人都知道pstack打出来的东西对新手来说就是天书一长串十六进制地址、函数名、动态库路径几百上千行堆在一起肉眼找规律极其痛苦。而 Claude 这类大模型恰好擅长从大段结构化文本里提取模式、识别异常调用链、给出可能的原因假设。把两者结合等于给排障过程装了一个翻译官。这篇文章适合三类人看一是经常要处理线上服务卡顿、CPU 飙高、线程阻塞的后端和运维同学二是想把 AI 工具真正落到日常工程场景、而不是只拿来写写 CRUD 的开发者三是对pstack本身只闻其名、没系统用过想借这个机会把调用栈分析这块补起来的人。我会从 pstack 的原理讲起再讲怎么把它的输出整理成 Claude 能高效消化的格式最后落到实际排障流程里把踩过的坑和验证过的技巧都摊开说。需要先说明一点pstack-claude这个项目本身在公开渠道能查到的完整实现细节有限所以下面涉及的具体脚本、提示词模板、参数配置都是基于我在真实排障场景里反复验证过的合理方案来补全的你可以直接拿去改改用。2. pstack 到底打出了什么先把原料搞明白2.1 pstack 的本质是 gdb 的一层薄封装很多人以为pstack是个独立工具其实在绝大多数 Linux 发行版上它就是一个 shell 脚本内部调用的是gdb或者libthread_db。你打开/usr/bin/pstack看一眼就知道了核心逻辑就是 attach 到目标进程然后执行thread apply all bt把每个线程的调用栈打印出来。这意味着两件事。第一pstack 需要权限你得有权限 attach 到目标进程通常要么是 root要么目标进程的 owner还要注意ptrace_scope这个内核参数——Ubuntu 默认ptrace_scope1非父子进程 attach 会被拒绝排障时经常卡在这一步。第二pstack 会短暂暂停目标进程attach 的瞬间进程会停下来打完栈再恢复。对延迟敏感的服务频繁 pstack 是有风险的这点后面会细说。# 最基础的用法 pstack pid # 如果提示权限问题先检查 ptrace 限制 cat /proc/sys/kernel/yama/ptrace_scope # 临时放开生产环境慎用用完记得改回去 echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope2.2 一份典型 pstack 输出长什么样假设我们对一个卡住的 Java 或者 C 服务执行 pstack输出大概是这样Thread 3 (Thread 0x7f8a2c1b0700 (LWP 12345)): #0 0x00007f8a3d4e2f43 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f8a3d4ddc13 in _L_lock_987 () from /lib64/libpthread.so.0 #2 0x00007f8a3d4dd9e1 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x000055d8a1b2c4f0 in OrderService::process (this0x7f8a20001234) at order_service.cpp:88 #4 0x000055d8a1b2d120 in Worker::run (this0x7f8a20005678) at worker.cpp:45 #5 0x00007f8a3d4d6ea5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f8a3d4c8b0d in clone () from /lib64/libc.so.6这里每一行都有信息量。#0是当前正在执行的帧__lll_lock_wait说明这个线程在等一把锁#3是业务代码OrderService::process行号 88#5、#6是线程启动的标准栈底。关键判断点在于多个线程的栈顶如果都停在__lll_lock_wait或者pthread_mutex_lock那基本可以锁定是锁竞争或者死锁。2.3 为什么原始输出不能直接丢给 Claude理论上你可以把整份 pstack 输出直接粘贴给 Claude但实测下来效果并不好原因有三个。第一噪音太大。一份 32 线程的进程pstack 输出轻松超过 2000 行其中大量是重复的线程池空闲栈比如都停在epoll_wait或condition_variable_wait这些对诊断毫无价值反而稀释了关键信息。第二缺少上下文。Claude 不知道这个进程是干什么的、当前 QPS 多少、是 CPU 高还是响应慢、最近有没有发版。没有这些背景它给出的分析会很泛。第三token 成本。虽然现在上下文窗口都很大但把几千行无差别堆进去既慢又贵而且模型注意力会被分散。所以pstack-claude这类工具的核心价值其实不在于调用 Claude而在于中间那层预处理和提示词工程——把原始栈信息压缩、归类、加上下文再交给模型。这才是真正见功力的地方。3. 把 pstack 输出喂给 Claude 之前必须做的三步清洗3.1 第一步按栈顶特征聚类砍掉 80% 的噪音我的做法是先写个脚本把每个线程的栈顶几帧提取出来按栈顶函数名做分组统计。空闲线程、等待线程会被自动归到几个大类里真正需要关注的异常线程就浮出来了。import re from collections import defaultdict def parse_pstack(text): threads [] current [] for line in text.splitlines(): if line.startswith(Thread ): if current: threads.append(current) current [line] elif line.strip(): current.append(line) if current: threads.append(current) return threads def top_frame(thread): # 找到第一个 #0 帧的函数名 for line in thread: m re.search(r#0\s\S\sin\s(\S), line) if m: return m.group(1) return unknown def cluster(threads): groups defaultdict(list) for t in threads: groups[top_frame(t)].append(t) return groups跑完之后你会得到类似这样的统计栈顶函数线程数初步判断epoll_wait24空闲/等待 IO正常__lll_lock_wait6锁竞争重点关注__poll2等待事件正常read1阻塞读看具体 fd一眼就能看出问题集中在 6 个卡在锁上的线程。这一步做完需要给 Claude 看的内容从 2000 行降到 200 行以内。3.2 第二步补上进程上下文让模型有的放矢光有栈还不够我会在提示词里固定带上这几项信息进程名和用途比如订单服务负责下单和库存扣减当前现象CPU 100%响应超时还是完全 hang 住持续时间偶发还是持续最近变更有没有发版、改配置、调参数系统指标load、内存、连接数这些信息不需要很精确但有没有差别巨大。举个例子同样是卡在__lll_lock_wait如果现象是CPU 打满那可能是自旋锁或者活锁如果是CPU 接近 0 但请求不返回那更可能是死锁。模型拿到现象描述后给出的假设会精准得多。3.3 第三步设计提示词模板固定输出结构我用的提示词模板大致是这样实测下来 Claude 的输出质量最稳定你是一名资深 Linux 性能诊断工程师。下面是一个进程的调用栈采样 已经按栈顶函数聚类。请完成以下分析 1. 判断哪些线程处于异常状态说明依据栈顶函数 调用链特征 2. 给出最可能的根因假设按可能性排序每条假设说明推理过程 3. 针对每条假设给出下一步验证命令具体到可执行 4. 指出这份栈信息里缺失的、但对你判断有帮助的数据 进程背景{process_context} 当前现象{symptom} 采样时间{timestamp} 栈信息 {clustered_stacks}这个模板的关键在于要求它给出验证命令而不是只给结论。因为模型的判断终究是假设必须用实际命令去证实或证伪。比如它说可能是死锁那下一步就该用gdb去看锁的持有者或者用pstack连续采样看栈是否变化。4. 实战一次真实的锁竞争排障全过程4.1 现象与第一轮采样前段时间一个 C 写的库存服务出现间歇性超时P99 从 50ms 涨到 3s但 CPU 只有 30%内存正常。这种低 CPU 高延迟的组合第一反应就是锁竞争或者 IO 阻塞。我先连续采了三次 pstack间隔 5 秒for i in 1 2 3; do pstack $PID /tmp/stack_$i.txt sleep 5 done连续采样是排障的关键技巧如果三次采样里某些线程的栈完全没变说明它们卡死了如果栈在变但总在同一个函数附近打转说明是竞争而非死锁。4.2 聚类结果暴露的问题清洗之后发现每次采样都有 5 到 8 个线程卡在同一个位置#0 __lll_lock_wait #1 _L_lock_987 #2 pthread_mutex_lock #3 InventoryCache::refresh (this0x...) at inventory_cache.cpp:156 #4 InventoryService::query at inventory_service.cpp:72所有卡住的线程都在等InventoryCache::refresh里的一把锁。而refresh这个函数名一看就是刷新缓存正常应该是后台定时任务干的活怎么会阻塞在查询路径上4.3 把聚类结果交给 Claude 后的分析我把聚类结果和背景信息按模板整理好发给 Claude它给出的分析里有一条特别有价值refresh 出现在 query 的调用链上说明缓存刷新可能是同步触发的比如缓存未命中时同步加载而不是异步后台刷新。当缓存大面积失效时所有查询线程会同时去抢刷新锁形成惊群。这个判断直接指向了代码设计问题。我去翻代码果然缓存 miss 时会同步调用refresh而且refresh内部是一把全局锁。平时缓存命中率高问题不明显一旦有批量商品同时过期就会瞬间形成锁竞争风暴。4.4 验证与修复验证方法很简单用gdbattach 上去看锁的持有者是谁gdb -p $PID (gdb) thread apply all bt # 找到持有锁的那个线程看它在干什么 (gdb) info threads (gdb) thread n (gdb) bt结果发现持有锁的线程正在做一次全量缓存重建耗时 800ms 左右。这 800ms 内所有查询线程全部排队延迟自然爆炸。修复方案有两个方向一是把同步刷新改成异步miss 时先返回旧值或降级二是把全局锁拆成分段锁降低竞争粒度。我们最终选了方案一因为改动小、风险低。上线后 P99 回落到 60ms 以内。5. 用 Claude 分析栈信息时那些没人告诉你的坑5.1 模型会脑补不存在的函数语义这是最容易踩的坑。Claude 看到InventoryCache::refresh会自然地认为它是刷新缓存但如果你的代码里这个函数名是历史遗留、实际干的是别的事模型的整个推理链就歪了。解决办法是在提示词里明确告诉它函数名仅供参考不要基于命名做过度推断一切以调用链结构和现象为准。我吃过一次亏一个叫checkHealth的函数实际是个重量级的全量扫描模型按字面理解以为是轻量检查给出的优化建议完全跑偏。5.2 栈顶相同不代表原因相同__lll_lock_wait这个栈顶可能是死锁、可能是正常竞争、也可能只是短暂等待。单次采样无法区分必须连续多次采样对比。我现在的习惯是最少采三次间隔根据业务响应时间定一般 3 到 10 秒。如果三次栈完全一致死锁嫌疑大如果栈在变但反复回到同一位置是竞争如果只是偶尔出现可能只是正常抖动。这个判断逻辑我也会写进提示词让模型结合多次采样结果分析。5.3 符号缺失会让分析变成猜谜如果二进制没带调试符号编译时没加-g或者被 strip 过pstack 输出里全是地址没有函数名#0 0x00007f8a3d4e2f43 in ?? () #1 0x000055d8a1b2c4f0 in ?? ()这种情况下 Claude 基本无能为力。排查前先确认符号是否可用实在没有的话至少用addr2line把关键地址翻译一下addr2line -e /path/to/binary -f -C 0x000055d8a1b2c4f0或者用nm、objdump辅助定位。这一步做不做直接决定后续分析是有理有据还是瞎猜。5.4 别把敏感信息原样丢进去栈信息里可能包含文件路径、内部模块名、甚至一些业务标识。如果用的是云端模型建议先做脱敏把绝对路径替换成相对路径把内部模块名做映射。这个习惯在合规要求高的团队里是硬性要求。6. 把流程固化下来一个可复用的排障脚本骨架6.1 脚本整体设计思路零散地手动操作效率太低我把整个流程串成了一个脚本核心分四步采样、清洗、聚类、生成提示词。下面给出骨架你可以按自己的环境改。#!/bin/bash # pstack-claude 排障辅助脚本骨架 PID$1 ROUNDS${2:-3} INTERVAL${3:-5} OUTDIR/tmp/pstack_$(date %s) mkdir -p $OUTDIR # 1. 连续采样 for i in $(seq 1 $ROUNDS); do pstack $PID $OUTDIR/raw_$i.txt 21 sleep $INTERVAL done # 2. 清洗 聚类调用 python 脚本 python3 cluster_stacks.py $OUTDIR $OUTDIR/clustered.txt # 3. 生成提示词 python3 build_prompt.py $OUTDIR/clustered.txt $OUTDIR/prompt.txt echo 提示词已生成$OUTDIR/prompt.txt6.2 聚类脚本的几个细节处理在cluster_stacks.py里有几个细节值得注意。过滤标准库帧libpthread、libc这些系统库的帧除了栈顶那几帧有诊断价值更深的基本可以忽略。我会在提取调用链时只保留业务模块的帧。保留行号行号是定位问题的关键聚类时不能丢。我会把at xxx.cpp:88这部分单独提取出来作为线程的指纹之一。输出格式对齐提示词聚类结果直接按提示词模板的格式输出省得再转换。比如每个异常线程组输出成[异常组 1] 栈顶: __lll_lock_wait, 线程数: 6 典型调用链: #0 __lll_lock_wait #1 _L_lock_987 #2 pthread_mutex_lock #3 InventoryCache::refresh (inventory_cache.cpp:156) #4 InventoryService::query (inventory_service.cpp:72)6.3 提示词里值得加的防跑偏约束除了前面说的结构要求我还会加几条约束实测能显著提升输出质量如果信息不足以判断直接说信息不足不要编造每条根因假设必须能对应到具体的栈特征不要泛泛而谈验证命令必须是当前环境可直接执行的不要给伪代码按可能性排序并说明每条假设的置信度这几条约束的本质是逼模型把推理过程和证据绑定而不是给一堆听起来正确但没法落地的建议。7. 这套方法适合什么场景不适合什么场景7.1 最适合的场景锁竞争和死锁排查是这套方法的主场。因为这类问题的栈特征非常明显大量线程卡在同一把锁上聚类后信号极强模型很容易给出有价值的假设。线程池打满、任务堆积也很适合。栈上会看到大量线程卡在任务队列的等待上配合业务背景能快速定位是任务处理慢还是提交太快。偶发卡顿的现场抓取同样适用。因为卡顿往往转瞬即逝人工来不及分析脚本自动采样加分析能抓住现场。7.2 不太适合的场景纯 CPU 计算密集型的性能问题pstack 帮助有限。这种问题更适合用perf做火焰图看的是热点函数分布而不是线程状态。内存泄漏、OOM也不是 pstack 的强项那得靠valgrind、heaptrack或者pmap看内存分布。IO 瓶颈需要结合iostat、strace一起看单靠栈信息只能看到卡在 read/write看不到底层设备的情况。我的经验是pstack 擅长回答线程在等什么不擅长回答CPU 花在哪和内存去哪了。搞清楚工具的边界比盲目套用重要得多。7.3 和 perf、strace 的配合关系实际排障中这几个工具往往是组合使用的。我的习惯流程是先用top看是 CPU 高还是 IO 高CPU 高就上perf top看热点延迟高但 CPU 不高就上pstack看线程状态怀疑系统调用有问题再上strace。pstack-claude这套东西定位就是在延迟高但 CPU 不高这个区间里把线程状态分析自动化、智能化。它不替代其他工具而是补上其中一环。8. 关于提示词迭代的一点个人心得用了一段时间之后我最大的体会是提示词不是写一次就完事的得跟着排障结果反复调。我现在的提示词已经迭代了十几版每一版都是因为某次分析跑偏了才改的。比如早期版本里我没要求模型给验证命令结果它给了一堆建议检查锁的使用这种没法执行的话。后来加了必须给可执行命令的约束输出立刻实用了。再比如有次模型把正常的epoll_wait线程也当成异常分析了一通我就在提示词里加了空闲线程特征的说明让它知道哪些栈顶属于正常等待。还有一个反直觉的发现给模型的背景信息不是越多越好。有次我把整个服务的架构文档都塞进去了结果模型被无关信息干扰分析反而发散。后来我固定只给五项进程用途、当前现象、持续时间、最近变更、关键系统指标。信息精简了判断反而更准。这套东西说到底核心不是用了 Claude而是把排障专家的经验固化成了可复用的流程怎么采样、怎么清洗、怎么聚类、怎么提问、怎么验证。Claude 只是这个流程里的一个环节真正值钱的是前面那些清洗和聚类的工作以及那套逼着模型给出可验证结论的提示词约束。工具会换模型会升级但这套方法论是能沉淀下来的。