凌晨两点十七分监控告警把我从床上拽了起来。某个订单接口的P99从200ms一路涨到3秒线上已经在零星报错。我摸黑爬起来ssh到跳板机面对的却是比告警更让人烦躁的状况生产环境的可观测平台权限被临时收紧链路的Trace断在半路Kibana里的日志因为TraceID对不上根本拼不出完整调用链。那一刻我退化成了一只caveman——一个原始人手里只有终端、日志和一颗愿意敲石头的脑袋。但就是这种最原始的排障方式二十分钟内帮我定位到了问题。这让我开始认真思考caveman这个标签背后的方法论。最近技术社区里这个词越传越开大家用它调侃printf调试法用它形容极简终端工作流也用它概括一种把复杂问题拆成最原始状态再动手的做事方式。这篇博文就聊聊我自己的caveman式排障经历、可复制的操作流程、以及我在极简工作流上踩过的坑和划过的边界线。1. 为什么最笨的caveman调试法反而救了我1.1 那晚的线上事故工具全废只剩日志先说那晚的具体情况。服务是Java写的调用链大概是网关 - OrderService - PaymentClient - Redis。告警平台只告诉我响应时间超过阈值SkyWalking里的Trace断在OrderService内部就没了后续Kibana里查同一笔订单的日志因为追踪ID在异步线程里没传透硬是拼不出完整链路。我试了大概十分钟去折腾那些高级工具结论是权限不够、数据不全、链路断裂。再耗下去用户投诉就要升级了。于是一咬牙退回到最原始的打法——直接把代码拉下来逐行读OrderService的执行路径把可能耗时的节点列出来用最笨的time 日志去打点验证。那天最后让我定位到问题的不是任何APM面板而是三行临时日志[CAVEMAN_TMP] orderId100239 stageenter cost2ms [CAVEMAN_TMP] orderId100239 stageredis_get cost2481ms [CAVEMAN_TMP] orderId100239 stagepayment_call cost150ms问题出在Redis读取用户余额这一步偶发耗时超过2秒。进一步追是连接池在特定线程模型下被耗尽拿连接等太久。1.2 为什么printf调试法被嘲笑却常常最快caveman debugging这个词翻译过来就是原始人调试法最典型的形态就是到处写print/console.log。它被嘲笑是因为看起来毫无技术含量但实战中你不得不承认当系统复杂到一定程度最直接的观测手段往往比层层包装的工具更可信。这里面的原理其实很简单。现代可观测性工具走的是采集 - 聚合 - 采样 - 展示的路径中间每一层都会引入信息损耗。采样率一降你看不到那笔出问题的请求链路ID没传透你拼不出调用关系聚合粒度太粗你连是入口慢还是数据库慢都分不清。而caveman方式打印出的每一行都是那笔真实请求在真实代码路径上的实时状态中间没有采样、没有聚合、没有缓存。信息通道极短信息可信度极高。我用一个类比来解释监控平台是机场的塔台雷达负责看整个空域的宏观态势caveman调试是你在跑到跟前用肉眼盯着那架飞机——目标不明确、只要盯住一个点时肉眼反而比雷达更快更准。1.3 和高端调试工具的实时对比一个真实场景的重现后来我在测试环境完整重现过那个问题顺手做了一次对比。用IDE Remote Debug连上去看变量启动要几十秒线程暂停会影响并发复现用APM想看方法级耗时得等数据上报周期而我敲一条Arthas命令几秒钟就看到了结果trace com.example.OrderService createOrder #cost 200trace直接贴在运行中的JVM上观测方法耗时完全不需要改代码、不需要重新发布。它看起来是个工具但精神上非常caveman——绕过一切中间层直接对进程下手。所以我对最笨方法的定义是不是不用工具而是绕过那些看起来很先进但链路很长的工具用最短路径拿到最可信的事实。复杂工具是给复杂问题准备的但很多问题在被你定位之前并不知道自己有多复杂。2. 一套可以照抄的caveman调试实操流程2.1 第一步永远是二分法缩小怀疑区间很多新手一上来就在整个调用链里撒网每个方法都加日志结果日志刷得飞起问题反而淹没在噪音里。caveman的做法是一次只问一个问题。以订单接口为例执行路径是Controller - OrderService - PaymentClient - Redis。我先问接口最外层是入口参数不对还是出口结果不对用日志确认入口和出口都正常后把中间层一分为二前半段服务内部处理还是后半段外部依赖调用通过时间戳分割一眼就能看出耗时集中在哪一段。这个二分过程是有技巧的。不要每层都加日志那相当于不二分直接遍历。正确的做法是加入口、出口两点日志先确认问题不在外层再加入中间点的日志确认问题在前半还是后半然后继续二分直到把可疑范围缩小到几十行代码以内。通常四到五次二分就能锁定一个具体的类和方法。2.2 临时埋点的正确姿势日志级别、格式与清理临时埋点最怕两件事被正式日志淹没或者排障结束忘了删。我自己的规矩是统一用WARN级别不用INFO。WARN在正式环境通常不会被过滤而且和业务INFO混在一起时更好辨认。日志里必须带业务主键和时间。比如订单号、用户ID、stage名称、耗时毫秒数。没有时间戳的日志等于白打没有主键的日志没法串联同一次请求。埋点格式统一带前缀。我用CAVEMAN_TMP_这样排查时一条grep就能全捞出来收尾时一条grep就能确认清零。一次只改一个节点。改完立刻验证带着上一轮的结论进入下一轮而不是一次埋十个点然后对着海量日志发呆。实际打日志的代码长这样以Java为例其他语言同理long start System.currentTimeMillis(); try { UserBalance balance userCache.get(userId); log.warn([CAVEMAN_TMP] orderId{} userId{} stageredis_get cost{}ms, orderId, userId, System.currentTimeMillis() - start); } catch (Exception e) { log.warn([CAVEMAN_TMP] orderId{} userId{} stageredis_get error{}, orderId, userId, e.getMessage()); }这段代码的作用是把读缓存这一步单独框出来测耗时。如果问题不在这一步日志会告诉你cost很小那就可以快速排除这个节点继续往下一个怀疑点挪。2.3 生产环境不重新发布也能临时观测的三种姿势生产环境改代码要发版成本太高。这里我给三个先别急着改代码的办法按优先级排列动态调整日志级别如果应用用的是Logback/Log4j2很多框架支持通过运维接口或Arthas动态改某个类的日志级别把本来DEBUG级别的日志临时放出来看一眼再关掉。Arthas在线观测watch看方法入参返回trace看方法内部耗时thread看线程状态。注意Arthas在生产环境attach JVM是有安全风险的大厂基本都要走审批。用完必须stop不要在线上留着。测试环境复现如果生产不好动就在测试环境压测复现。这看起来慢实际上更稳。问题是偶发的先把复现条件摸清楚比在生产环境反复试探安全得多。三种方式的决策原则就一句话**能不改代码就不改代码能不在生产动手就不在生产动手。**caveman不代表莽撞代表的是用最直接的方式到达目标。2.4 完整案例一次订单超时问题的排查全过程我把那晚的完整排查链路写出来方便你照着走一遍。目标是定位为什么订单接口偶发超时3秒。第一步入口出口打点确认问题在OrderService内部而不是网关或上游。日志显示[CAVEMAN_TMP] orderId100239 controller_in cost3ms [CAVEMAN_TMP] orderId100239 controller_out cost3011ms入口到出口确实花了3秒问题在Controller之后。第二步在OrderService内部按调用顺序打三个点查余额(Redis)、调支付(PaymentClient)、写订单状态(DAO)。[CAVEMAN_TMP] orderId100239 stageredis_get cost2481ms [CAVEMAN_TMP] orderId100239 stagepayment_call cost150ms [CAVEMAN_TMP] orderId100239 stageorder_update cost20ms一目了然耗时几乎全在Redis读取上。第三步拆Redis这一步。是网络慢、单命令慢、还是连接获取慢继续细化埋点[CAVEMAN_TMP] orderId100239 stageredis_connection_wait cost2380ms [CAVEMAN_TMP] orderId100239 stageredis_command cost80ms终于破案——等连接等了两秒多命令本身只花了80ms。这是典型的连接池耗尽借不到连接在那里傻等。第四步验证结论。用thread命令看当时的线程堆栈果然一批线程阻塞在JedisPool的borrowObject上。根因是压测脚本留下的连接泄漏在某些线程模型下偶发触发。整个过程用了二十分钟。没有改一行正式代码只在测试环境加临时日志复现验证。这就是caveman调试法最典型的胜利——它不提供全局视图它只帮你验证一个又一个具体的假设。3. 从调试推广到日常caveman式极简开发环境的搭建3.1 为什么我最终把主力工作场景搬进了终端caveman精神帮我解决的不只是排障还有日常开发体验。前两年我特别沉迷全家桶IDE项目一启动CPU风扇直接起飞。有个典型场景联调时IDE卡死怎么都点不动我一怒之下切到命令行用vim改代码、用命令行跑测试、用tail看日志那晚的效率高到离谱。从那之后我开始有意识地给高频动作做终端化改造。我不是让你彻底放弃IDE很多重度重构场景IDE依然强。我的建议是把读代码、查日志、跑命令这三个最高频动作搬到终端因为这些场景IDE做得并不快。维持一个大多数时候在终端关键场景切IDE的双轨工作流是最务实的caveman化。3.2 我的极简工具清单与替换理由用途传统工具替代工具核心理由文件搜索findfd更快默认遵守.gitignore输出可读性强文本搜索grep -rripgrep (rg)速度快一个数量级语法高亮清晰查看文件catbat自带语法高亮、行号、Git改动标记历史命令搜索CtrlR 翻fzf模糊搜索按一下就能找到想要的命令会话保持裸SSHtmux断线不丢会话分屏协作方便终端本身系统默认iTerm2 / Windows Terminal WSL配色、字体、快捷键都可定制这套组合没有一个是必须的但它们合起来的效果是我90%的日常操作不用离开键盘。找文件是fd搜内容是rg看代码是bat切历史命令是fzf思路完全不被打断。3.3 我的zshrc里收益最高的几段配置直接上干货这几段在我所有开发机上都是标配换新机器五分钟就能恢复手感# 高频别名减少键盘损耗 alias ggit alias kkubectl alias ddocker alias dcdocker compose # 当前目录下的代码搜索自动忽略依赖目录 cf() { rg -l $1 --glob !node_modules --glob !vendor --glob !target --glob !dist } # 按修改时间倒序显示文件找刚才改过的文件非常好用 alias lfls -lt | head -20 # 历史命令去重 增加条数配合fzf用 export HISTSIZE10000 export HISTFILESIZE20000 setopt HIST_IGNORE_ALL_DUPS # tmux会话快速进入或创建 ta() { tmux attach -t $1 2/dev/null || tmux new -s $1; }两条经验补充一下。第一别在配置里堆一堆自己看不懂的alias每加一条都要想清楚我到底用不用得上。第二setopt HIST_IGNORE_ALL_DUPS配合fzf特别爽历史命令不再刷屏重复项模糊搜索一按一个准。3.4 一条命令复现工作流的setup脚本思路我在新机器上安家靠的是一份setup脚本它做的事情很简单检测系统类型、装工具、写配置。这里不贴完整脚本太长且每个人需求不同我把骨架和关键点拆出来你自己拼装反而更合适#!/usr/bin/env bash set -euo pipefail # 1. 判断包管理器 if command -v apt-get /dev/null; then PMapt; elif command -v brew /dev/null; then PMbrew; elif command -v dnf /dev/null; then PMdnf; fi # 2. 安装核心工具 # $PM install fd-find ripgrep bat fzf tmux # 3. 写zshrc片段到用户目录 cat ~/.zshrc EOF # caveman core aliases alias ggit EOF # 4. 配置tmux # tmux新会话默认开启一个良好的状态栏 echo set -g mouse on ~/.tmux.conf echo setup done. run source ~/.zshrc写脚本一定要set -euo pipefail打头不然中途某个命令失败后面的配置还是继续跑很容易留下一台配置半残的机器。另外配置类的东西尽量幂等跑两次不会出问题这样以后更新环境没有心理负担。4. caveman的边界什么时候该原始什么时候必须上重武器4.1 我真实踩过的caveman失效场景caveman方法不是万能的我至少有三次被它反噬的经历印象非常深刻。第一次是内存缓慢泄漏。现象是服务每隔几天就会OOM一次print调试法只能看到内存慢慢涨但你根本不可能靠println看清是哪块对象在堆积。这种问题必须用MAT分析heap dump看支配树、找泄漏点光靠日志就是大海捞针。第二次是跨服务调用链断裂。我在A服务埋点发现耗时正常但下游B服务就是报错本地日志只能看到当前服务的视角。这种场景必须靠全链路追踪把A到B到C串起来单点caveman日志是拼不出全局真相的。第三次是历史趋势对比。用户反馈最近接口越来越慢但这种慢是渐变式的今天的日志和上周的日志对比量级上根本看不出差异。这种必须靠监控平台的时间序列曲线才能看到从哪天开始斜率变了。4.2 判断用哪种方式的决策清单踩过这些坑之后我给自己总结了下面这张决策清单遇到问题先按顺序过一遍问题是否在我最近改过的代码里是先caveman快扫不是直接上监控平台看趋势。问题只出现在当前服务内部还是跨多个服务跨服务直接走全链路追踪不要单点打印。是否涉及内存、线程池、GC是别浪费时间print直接抓dump、看堆栈。问题是否偶发且无规律是caveman埋点加压测复现无规律但高频先看监控曲线找出触发时段。核心原则**先用廉价手段验证可能性再用昂贵手段确认全局。**caveman是廉价手段但不是唯一手段。一台只有锤子的人会把所有问题看成钉子caveman主义最大的风险就在这儿——手里println用顺手了遇到所有问题都想println。4.3 两条腿走路的团队配置建议对团队来说我的建议是同时保留两条链路并且在文档里写清楚各自的使用场景。一条是极简链路日志聚合 grep Arthas 一段临时埋点模板。服务于日常开发、快速定位、测试环境复现。一条是重型链路APM全链路追踪 指标监控 日志平台 Profile工具。服务于跨服务排查、容量规划、趋势分析、生产环境宏观观测。这两条链路的服务对象其实是排查阶段和确认阶段。排查阶段用极简链路快速建立假设确认阶段用重型链路全局验证。我见过最痛苦的团队是把全部希望寄托在APM一个工具上面板上全是图但遇到问题时没人知道该看哪张图。反而是那种日志很干净、脚本很顺手、Arthas很溜的工程师常常第一个定位到根因。对我个人来说caveman不是一个标签而是一种态度先用脑子理解系统的运行逻辑再选择最合适的信息通道去验证。工具再贵重也替代不了对系统本身的熟悉程度。把这个态度练成习惯之后你会发现所谓高级工具和原始方法之间的边界越来越模糊——因为不管用什么目的只有一个尽快逼近那个唯一的真相。
