1. 分布式系统排查难的不是命令而是思路分布式系统问题排查这件事我从最早的单体应用运维一路做到现在管着几十个微服务、上百个实例的集群最大的感受是真正让人抓狂的从来不是你记不住某个命令而是你根本不知道该从哪一层下手。一台机器上的问题你 top、free、iostat 三板斧下去基本就有感觉了但换成分布式系统一个用户下单失败可能牵扯到网关、鉴权、订单、库存、支付、消息队列、缓存、数据库七八个组件中间还隔着网络、容器编排、服务发现你能看到的现象只有一个偶发超时剩下的全是黑盒。这篇文章我想聊的就是这套实战思路——怎么从一个模糊的现象出发一步步把问题范围收缩到某个具体的组件、某个具体的参数最后定位到根因。同时我也会把几个容易踩坑但又特别高频的场景讲透比如有线网络卡顿这类底层问题怎么排查通过远程通道接入 Linux 服务器做现场诊断时有哪些讲究以及在云计算环境下做分布式排查跟自建机房有哪些不一样的地方。适合已经有一定 Linux 和网络基础、正在负责线上系统稳定性的运维、后端和 SRE 同学看也适合那些刚接手分布式项目、遇到问题就只会重启的开发者。我得先说一句可能有点反直觉的话分布式排查的核心能力不是排而是缩。你要在最短时间内用一个又一个证据把可能是任何地方变成大概率是这里。下面我从方法论开始一层层往外铺。2. 排查之前必须先建立的三张底图很多同学一遇到报警就直奔服务器敲命令敲了半天发现连这个服务部署在哪几台机器上都不清楚这就属于典型的没有底图就开船。我个人的习惯是任何一次正式排查之前先在脑子里或者纸上把三张图调出来。2.1 服务拓扑图谁调用了谁分布式系统的调用关系往往比我们记忆中的复杂得多。你以为订单服务只调库存实际上它还异步发消息给积分、通知、风控这些下游又各自回调。所以第一件事是把当前故障链路相关的调用拓扑画出来标清楚同步调用和异步调用、强依赖和弱依赖。我一般用两个办法快速还原拓扑一是看链路追踪系统里的服务依赖图如果你们接了的话二是直接翻配置文件里的注册中心和下游地址列表。这里有个细节静态配置里的依赖清单往往是过时的真正准确的是运行时抓出来的调用关系。我踩过一次坑按照老文档去查一个已经不存在的下游白白浪费了半小时。拓扑图的价值在于当某个接口报超时时你能立刻列出这条链路上有哪几个可能的故障点而不是无头苍蝇一样去猜。2.2 资源与指标图正常长什么样第二张图是基线。分布式排查里最容易被忽略的一点是你得知道正常是什么样子。某个接口平时 P99 就是 800ms那它跑到 900ms 根本不算异常反过来一个平时 5ms 的接口突然变成 50ms哪怕绝对值很小也值得警惕。所以我会提前把关键指标的正常区间记下来各服务的 QPS、响应时间分布、线程池活跃数、连接池占用、GC 频率、内存水位、磁盘 IO 利用率。这些数据从监控系统里一拉就有但关键在于你要能一眼看出哪个指标偏离了它的日常形态而不是盯着一个孤立的数字发呆。提示别只看平均值。分布式系统的故障常常藏在尾延迟里平均值被大量正常请求一平均就看不出来了。P95、P99、P999 才是你的主战场。2.3 变更时间线最近动了什么第三张图其实是条时间线。我敢说线上百分之七八十的故障都和最近的某次变更有关——发版、扩缩容、配置调整、证书更新、网络策略变更、依赖升级。所以排查第一动作应该是问一句最近两小时、这两天系统动过什么把变更记录和故障开始时间对齐如果高度吻合那基本方向就有了。哪怕不完全吻合也能帮你排除掉一大批无关变量。我见过很多次大家吭哧吭哧查了半天底层网络最后发现是前一晚有人改了个连接池上限没走评审。这三张图准备齐了你才算真正站在了排查的起跑线上。3. 从现象到定位一套可复用的收缩法有了底图接下来就是系统性收缩。我把它总结成四问法每一问都在把范围往小里逼。3.1 第一问影响面有多大先别急着看技术细节先看影响范围。是全量用户都受影响还是只有某个地域、某个版本、某类设备是持续性的还是脉冲式的是所有接口都慢还是只有某几个接口影响面的形状往往直接指向根因类型。举个例子如果只有某个可用区的实例出问题那大概率是那一侧的网络或宿主机故障如果是集群里所有实例同时变慢那更可能是共享依赖——数据库、缓存、注册中心出毛病了如果是脉冲式的、每隔几分钟抖一下那要重点怀疑定时任务、缓存刷新、GC 或者连接池的周期性行为。这一步不需要任何高深工具把监控大盘上的曲线形状看仔细就行但恰恰是最多人跳过的一步。3.2 第二问是资源瓶颈还是逻辑问题确定影响面之后下一个岔路口是这个慢是资源不够还是逻辑有问题区分方法很直接——看资源指标。如果故障期间 CPU 打满、内存溢出、磁盘 IO 饱和、带宽跑满那就是资源瓶颈方向是扩容或者优化资源使用。如果资源指标很平稳CPU 才 20%、内存充足、网络也没满但请求就是慢那问题多半在逻辑层面锁竞争、线程池排队、连接池不够、下游阻塞、序列化耗时、慢查询。我遇到过最典型的一次是接口超时所有机器资源都很闲最后查出来是某个共享连接池的最大连接数配得太小请求全堵在获取连接那一步。资源监控一点异常都没有但瓶颈实实在在存在。3.3 第三问问题在链路的哪一跳如果是逻辑问题那就得靠链路追踪把一次请求拆成若干段看每一段的耗时。一个请求从网关进来经过鉴权、业务处理、查缓存、查数据库、调用下游、返回每一跳都有耗时。你把这些耗时按顺序排开哪一段突然变长问题就在哪一段附近。这里有个经验不要只看最慢的那一跳要看耗时增量的分布。有时候是某一跳从 2ms 涨到 500ms很明显但有时候是每一跳都均匀地多了 3ms累加起来就超时了这时候问题往往出在更底层——比如系统调用、网络往返、或者时间同步。3.4 第四问改一个变量能不能复现或缓解前面三问如果还没定位就到动手环节了。在可控范围内改一个变量——把某台机器摘掉、把某个下游切走、把某个配置调大、重启某个组件——然后看现象有没有变化。每次只改一个变量这是铁律否则你永远不知道是哪个改动起了作用。如果摘掉某台机器后问题消失说明问题集中在那台机器上如果切走某个下游后响应恢复正常那故障点就在那个下游如果改什么都是老样子那可能问题在更外层或者是个复合故障。这套四问法不依赖任何特定工具但它能保证你的排查是收敛的而不是发散乱撞。4. 有线网络卡顿最容易被甩锅也最该被认真对待的一类问题只要系统变慢第一个被怀疑的往往是网络。是不是网络又卡了这句话我在无数个故障群里见过。但说实话真正的网络层问题其实不多多数是应用层把自己拖慢了。不过这不代表网络排查可以糊弄恰恰相反你得有本事用证据把网络排除掉或者把网络问题坐实。4.1 卡顿的几种典型形态先分清卡顿这个词太笼统了先给现象分类时延高但不大丢包请求都很慢但没有明显报错。这种多半是链路拥塞、路由绕行或者队列积压。丢包引发重传TCP 层不断重传表现为毛刺、超时、连接不稳定。这通常是链路质量差、网卡或交换机端口有问题。连接建立慢新建连接特别慢但连接建好后正常。这往往和 DNS 解析、握手过程、SYN 队列有关。间歇性大面积不通一会儿好一会儿坏。要怀疑链路抖动、双工模式不匹配、广播风暴。分清楚是哪一种排查方向完全不同。4.2 我常用的排查顺序拿到一台嫌疑机器我会按这个顺序过一遍第一步看网卡本身的状态。用ethtool看协商速率和双工模式。我踩过一个大坑有台机器的网卡因为网线老化速率从千兆降到了百兆双工还协商成了半双工结果一整批请求慢得离谱。这种问题在监控上几乎看不出来只有看网卡状态才发现。# 查看网卡协商速率、双工模式、链路状态 ethtool eth0 # 查看网卡收发包统计重点看 errors、dropped、overruns ip -s link show eth0第二步看丢包和重传。用netstat -s或者ss -s看 TCP 重传、校验和错误等全局统计的增量。注意是增量不是累计值——累计值大不代表现在有问题。# 每隔一秒采样一次 TCP 相关统计 watch -n 1 netstat -s | grep -iE retrans|error|timeout第三步看实时连接状态。ss -ant能列出所有 TCP 连接状态。如果看到大量SYN-SENT说明连接建不起来对端不通或丢包大量CLOSE-WAIT说明应用没正确关闭连接大量TIME-WAIT是正常现象但数量异常高时要关注端口耗尽。第四步用抓包坐实。前面几步都只是怀疑tcpdump才是最终判决。抓一段流量重点看有没有重传、有没有乱序、握手耗时多少。这一步稍微进阶但一旦你掌握了排查效率会有质的飞跃。# 抓取指定端口上跟某个对端的交互存文件后分析不要直接打到终端刷屏 tcpdump -i eth0 -w /tmp/cap.pcap host 10.0.0.5 and port 8080注意抓包文件可能很大抓的时候一定加过滤条件抓完及时清理。生产环境上长时间无过滤抓包很容易把磁盘写满反而制造新故障。4.3 一个排查心得网络问题最忌讳的是上来就怀疑网络。我的习惯是反过来先假设网络是好的用证据证明应用层有问题只有当应用层排查到卡在发送/接收这一步时才转向网络排查。这样能避免大量无效的抓包和瞎猜。另外同一机房内的服务调用尽量走内网地址跨机房、跨区域调用要格外关注时延和带宽。很多网络卡顿的根因其实是某个配置误把内网调用写成了公网地址白白绕了一大圈。5. 通过远程通道接入 Linux 做现场诊断的注意事项很多线上服务器你不能直接物理接触得通过跳板机或者统一的接入通道连过去排查。这个过程本身也是个技术活弄不好会造成二次伤害。5.1 接入前的准备我不会一上去就敲命令而是先想清楚要看什么。列个清单要看进程状态、线程栈、内存分布、磁盘 IO、网络连接、最近日志。带着问题上去效率比漫无目的地逛高一倍。接入时有个基本原则能用只读命令就别用写命令能用采样就别用全量。线上环境的首要目标是别把正在挣扎的系统压垮。# 看进程的资源占用按 CPU 或内存排序 top -o %CPU # 采样一分钟的进程级 IO比一次性快照更能看出趋势 pidstat -d 1 60 # 抓一份线程栈连续抓几次可以看出哪段代码在卡 jstack pid /tmp/stack1.txt5.2 会话与操作留痕正规的接入通道一般会有会话审计你敲的每一条命令都会被记录。这不是为了监视你而是故障复盘时能还原当时到底做了什么。我强烈建议你自己也养成留痕的习惯——把关键命令的输出重定向到临时文件排查完再统一分析同时记录自己每一步的假设和结论。这样做的好处是万一一次排查没定位下次换班的人能接着你的思路走而不是从头再来一遍。5.3 常见踩坑点别在高负载机器上跑全量扫描类命令。比如对整个大目录做grep、对整个磁盘做find这些操作本身会吃掉大量 IO让本来就很脆弱的系统雪上加霜。注意权限边界。很多生产账号是受限的你看到的进程信息、打开的连接可能不完整。如果发现关键信息缺失先确认是不是权限问题别急着下结论。留意时区。跳板机、目标服务器、日志系统、监控系统如果时区不一致对齐时间线时能把人逼疯。排查前先统一确认各处的时区设置。断开连接前留个清白。临时文件该删的删该改的配置改回去别给下一班的人留坑。6. 云计算环境下分布式排查的特殊性云上跑分布式系统和自建机房有一个本质区别你失去了一部分对底层资源的可见性和控制权。物理机时代网络不通你可以去机房换根网线、看交换机指示灯到了云上很多东西变成了黑盒排查方法也得跟着变。6.1 那些云上特有的玄学问题可用区之间的时延。同一地域不同可用区之间的网络时延虽然不高但相比同机架内的机器还是有差距。如果你的服务对时延敏感又恰好把相互依赖的组件部署在了不同可用区那日常就能感受到抖动。排查时先确认各组件的部署分布。共享资源的邻居效应。云主机底层可能存在资源争抢你的实例资源监控看着正常但实际性能就是上不去。这种情况比较隐蔽通常表现为莫名其妙的性能波动且和你的业务负载没有强相关。弹性伸缩带来的实例漂移。云上经常做自动扩缩容实例会不断新建、销毁。如果排查时你抓的 IP 或实例 ID 是几分钟前的可能那个实例早就不存在了。所以云上排查要养成习惯先拉一份当前的实例列表再基于最新列表定位。网络策略和安全组的隐藏限制。容器编排和云平台常常有额外的网络策略层一个连接不通可能是安全组没放行也可能是网络策略拦了还可能是服务网格在做流量劫持。排查时要按层确认别只盯着防火墙。6.2 云上排查的发力点在云环境里我更多依赖平台提供的可观测能力。日志服务、指标监控、链路追踪、事件中心这四样基本能覆盖大部分场景。尤其是事件中心这一类产品特别容易被忽略——扩容失败、健康检查异常、实例被驱逐这类事情往往在那里有明确记录比你自己一层层查起来快得多。另外镜像和启动脚本也是云上的高频故障点。一个实例老起不来、起来就挂很多时候是启动脚本里的某个依赖没准备好或者镜像里少了个关键配置。排查这类问题时把实例的启动日志完整拉出来看比在应用日志里大海捞针高效得多。7. 典型故障案例与排查实录光讲方法论有点干我挑两个真实感比较强的案例把上面的思路串一遍。7.1 案例一集群整体响应变慢但资源都很闲现象是某天下午开始核心接口的 P99 从 200ms 涨到了 1.5 秒影响面是全量的。看资源监控CPU、内存、磁盘、网络全都很平稳。按收缩法走影响面是全量 → 排除单机故障指向共享依赖。接着看链路追踪发现耗时集中在查缓存这一跳。再看缓存集群的监控发现它的 CPU 不高但网络连接数和命令处理队列长度在缓慢上升。顺着连接数这个线索查到应用侧发现有个新上线的定时任务会周期性创建大量短连接去访问缓存连接关闭不及时逐渐把连接池占住了。根因是一个没做好连接复用的任务。资源层面毫无异常但共享的连接池被打爆了。这个案例的教训是资源闲不等于没瓶颈共享的连接、队列、锁都可能是隐性瓶颈。7.2 案例二间歇性的接口毛刺某个服务每隔十几分钟抖一下毛刺持续一两秒其他时候完全正常。这种问题最难查因为它不可复现。我先把时间线拉出来发现毛刺的间隔和某个日志切割、缓存批量刷新的周期很接近。继续深挖确定是缓存预热任务在批量回源瞬间打满下游数据库的连接。数据库连接被占住的那一两秒其他请求全卡住了。解决方式其实很简单把批量预热改成小批量、限速地慢慢灌进去。但找到根因花了大半天因为它藏在周期性行为里静态看指标根本看不出来。这个案例的心得是面对脉冲式、间歇性的问题一定要去对齐周期性行为的时间线——定时任务、日志轮转、缓存刷新、批量同步、GC 周期列出来挨个排除。8. 常见问题速查与避坑清单最后整理一份我平时用得最多的速查表排查时对着过一遍能省不少来回。现象优先怀疑方向常用抓手全量接口变慢、资源闲共享依赖、连接池、锁竞争链路追踪、连接数监控单机或单可用区异常宿主机、网络、节点故障摘除节点验证、节点事件脉冲式毛刺定时任务、缓存刷新、GC周期行为时间线对齐偶发超时、无规律网络重传、慢依赖tcpdump、下游耗时分布连接建不起来安全策略、端口耗尽、DNSss 连接状态、策略放行记录起不来、起来就挂启动脚本、镜像、依赖顺序实例启动日志、事件中心再补几条我个人踩出来的经验都是常规文档里不太会写的第一排查过程中随手记录。写下你的每个假设、验证结果、下一步计划。人在高压下特别容易绕圈记录能帮你保持清醒也方便交接。第二改配置之前先想好怎么回滚。哪怕只是调大一个参数也要记住原值。我见过因为改配置没记录最后连回滚都不知道回滚到哪的。第三分清楚临时缓解和彻底修复。重启、摘节点、切流量都是缓解手段能帮你争取时间但一定要在恢复后找到根因否则同样的问题还会准时上门。第四别迷信重启大法。重启能让现场消失但它也把唯一的证据销毁了。能在重启前抓的信息尽量抓尤其是线程栈、连接状态、临时文件这类重启就没了的东西。说到底分布式系统排查这件事工具和命令只是表层真正拉开差距的是你有没有一套稳定的、收敛的思路以及你在压力下能不能保持冷静、有条理地一步步验证。这套东西没有捷径都是在一次次真实故障里磨出来的。多复盘、多记录、把每次故障都变成一次认知升级几次之后你会发现那些曾经让你手足无措的玄学问题其实都有它清晰的因果链。