1.摘要

前几天在高可用架构群里做的分享，关于排查问题的过程中有可能遇到的一些场景和应对的思路。

2.背景

首先是背景介绍，之前在qcon分享上提过，这里简单介绍一下。

• 业务背景：微博主要面对的是大数据量、高负载的业务压力，并且会伴随着突发的请求峰值；
• 技术背景：大规模的基于linux系统的集群；使用java作为主要语言；一些外部的框架比如tomcat、storm、hbase等；一些自研的系统比如rpc框架motan、服务发现config service等。不同企业和行业采用的方案可能有区别，但从问题排查这个角度来说都是类似的。

在这个背景之上，今天要讨论的是一些影响线上服务可用性的问题，关于如何排查，和如何改进系统的一些建议。

3.排查

问题排查相对于设计系统或者编码来说是一个反向推导的过程，这个过程往往比理解原因或者解决问题复杂。

举个生活中的例子，邻居家的小孩很调皮，有一天拿弹弓玩，把我家玻璃打破了，这是个正向的推导逻辑，很好理解；但是反过来，我到回家，看到玻璃破了，想知道原因，这个过程就要复杂的多。

对于影响线上系统可用性的问题，都可以总结成这样一个模式：一个根本原因，经过一条或几条传播路径，最后表现出某些现象。

举个例子，比如由于内存泄露，导致操作系统吃swap了，导致处理变慢，导致依赖它的服务超时，导致处理线程堆积，导致服务不可用。这里的内存泄露是根本原因，服务不可用是现象，其它是传播路径。

但原因、路径和现象不是一一对应的，我在以往排查的问题的过程中，遇到的绝大多数都不是完全相同的问题，比如表现相同的问题，原因和路径完全不一样；或者相同的根本原因，通过不同路径表现出不同的现象。

还是刚才那个例子，应用吃swap的问题，可以是因为堆外内存泄露，可以是机器上启动了其它消耗内存的程序，还可以是numa配置引发的；同样，堆外内存泄露可能导致吃swap，也可能导致oom，还可能什么现象都没有。

所以单纯的看一些案例，了解“A会引发B”，对于今后问题排查来说有一些帮助，但是帮助不大，实际排查的过程中很多案例不能直接通过现象得出原因。

更进一步，可以通过某个案例去了解“在出现B现象时，我可以通过某某手段去分析”，这种学习手段的办法会好一些，但是还不够。

随着新技术的使用和越来越高的访问峰值，新的问题层出不穷，如果技术上的倾向激进一些，必然会碰到无法通过现有案例解释的问题，此时更多是学习一些解决问题的思路。

还是回到今天的分享，关于排查问题。我理解的排查就是一步步的收集线索、分析线索最终定位原因的过程，今天要讲的是如何更有效的发现和利用线索。

我在这里把线索分为三类：known-known，known-unknown，unkonwn-unknown。之后分别跟大家探讨一下每一种的应对思路和手段。

3.1.known-known

known-known，就是你想要知道，并且已经获取到的一些信息。比如日志，或者业务表现，或者监控图上反应出来的信息。

一般来说，需要获取的信息大概分几类：

1. 服务表现：问题的具体表现（出错、超时等）、应用日志、依赖服务的状态等
2. 系统状态：操作系统指标（系统管理的各种资源的状态、系统日志等）、vm指标（主要是gc）
3. 硬件指标：cpu、内存、网络、硬盘是否达到瓶颈

我们是通过框架定制+自研/开源工具的方式来获取上面说的几类信息，比如业务相关的指标是通过框架层输出日志+ELK/graphite之类生成图形。

系统的监控用的是新浪内部的监控系统，也可以用开源的工具比如Cacti/Zabbix，运维这方面我不专业，就不展开了。

一般的监控系统应该可以提供上面这些信息，而对于分布式的系统来说，除了上面说的线索，还有非常重要的线索就是已知数据的定量分析和归类，比如：

1. 重现概率
2. 时间点
3. 问题的共同特征

这些线索很可能因为描述的不够清楚而被忽略，但在实际排查中很可能非常有价值。

比如“不是全部请求都出错”，或者“刚才数据库和web服务都出问题了”之类，如果换成“线上请求有1/3出错，都是电信用户的请求”或者“web服务18:12:11开始报异常，数据库18:12:30开始出现慢请求”，效果是不一样的。

举个案例，以前出现过一次线上未读数偶发清不掉的问题。出现问题时没有发现明显的异常，日志也没有问题，当时我们重启了前端服务，但是没有效果。

之后我们统计了一下1分钟内出现问题的请求占正常请求的比例，大约是1/8，而这个服务依赖的另一个服务正好是8个实例，于是我们进一步统计出问题的请求，果然都调用到了同一个实例，于是当时下掉了这个可能有问题的实例，服务恢复了。

再之后通过进一步分析出问题的实例，找到了原因，那台机器在tcp超时后没有断开连接，而是直接把连接返回了连接池，导致下一次使用这个连接的时会取得上一次请求的返回值，对于计数这个场景，相当于每次返回的都是别人的数据。

总结一下关于known-known类的线索，主要是在不丢失信息的情况下，对信息做定量和归类分析，定位进一步的排查方向。

3.2.known-unknown

接下来是known-unkonwn，这个是指你想要知道但目前还不知道的信息，一般指不能直接看到的信息。可能你会疑惑为什么会有这个跟上面有什么区别。

还是举个案例：应用出现了慢请求问题，业务逻辑的处理时间好像没问题，假设这个时候我记起看到过tcp文章里说socket有个接收队列，我隐约感觉这里可能有问题，应该看看有没有堆积，但是不知道怎么看，这个时候要怎么办？

一个很自然的想法是，那就上网查一下怎么看就是了，用不了10分钟就能解决。但是在实际排查问题的过程中，绝大多数情况下我并不会花10分钟去查研究怎么看队列长度，更有可能的做法是去花2分钟查一下gc情况，花2分钟看看系统日志，再花3分钟去确认一下应用日志是不是看错了。

造成这个现象的原因大致有两个，首先是因为在排查问题的过程中，收集到的线索更多是用来排除可能性，而不是用来证明可行性，在得到线索内容之前，我很难说某个线索比另一个线索更有价值，这时会很自然的倾向于那些时间成本更低的工作。

其次，心理学上有个现象，叫做“熟悉偏好”，指的是人们在熟悉的事情和不熟悉的事情之间更喜欢选择熟悉的，回避陌生的事情。在排查问题，尤其是线上问题的过程中，表现的尤其明显。当出现了问题之后，很多同学更倾向于利用已有经验排查问题。

以上两个原因跟技术关系不大，但是造成了虽然知道应该去获取某些信息，但实际上总会拖到实在没招的时候再去想办法查看“我觉着应该知道的信息”，实际浪费的时间远远大于新知识的学习时间。

如何获取这些隐藏的信息，我个人的经验是使用工具，不管是系统还是应用都可以给我们提供很多工具，在qcon的演讲里也提到了一些。无论是系统提供的，还是第三方的，还是自己开发的都可以辅助我们发现更多的线索。

但是就像刚才说的，问题排查过程中，工具的学习和使用成本是需要考虑非常重要的因素。我列举几点经常用到的信息和我期望能达到的效率，供大家参考。

1. 30秒获取整体服务情况：请求量、响应时间分布、错误码分布。这里主要是用业务的监控系统。

2. 3分钟了解某台机器的负载情况：最耗cpu的线程和函数（cpu）、tcp连接状态统计和buffer堆积状态（网络）、程序的内存分布，最耗内存的对象（内存）、当前是哪个程序在占用磁盘io、gc情况。

   这里主要是linux和java的一些辅助工具：top/perf/netstat/iotop/jmap/jstat等等。

3. 3分钟了解请求的链路情况，网络传输、系统调用、库函数调用、应用层的函数调用的调用链、输入、输出、时长。

   这里也有linux和java的一些辅助工具，tcpdump/strace/ltrace/btrace/housemd等。最近我们也在完善用于集群的调用链分析工具trace，希望在足够完善之后能开源出来。

4. 3分钟检索当前系统的快照情况：线程栈情况、某个变量的值、存储或者缓存里的某个值是什么。同样是系统和java提供的一些已有工具，jmap/jstack/gdb/pmap等。

可能大家觉着这个指标定的有些低，有不少信息都是一个命令就可以看到了，这里特别强调一下，我指的是从头脑中有要看的想法，到看到并理解实际信息的时间。google一下命令的用法、安装工具之类的时间也要算进去:P

刚才说到关键点是如何提高效率，熟练工是一个方法，但是降低工具的使用成本更有效一些。我们做了一些排查问题相关的工具和系统，相信很多公司也有类似的内部系统。

之前qcon上展示过监控之类的大型系统，今天展示几个日常用的小玩意。

查询具体的业务数据，比如查询某个id当前的消息计数：

分析当前机器上的jvm的线程、堆或者其它信息：

总之，关于known-unknown只强调一点：如果要做用于排查问题的工具，如果一次查询的时间超过3分钟，那实际排查的过程中很有可能就没法发挥这工具的价值。

3.3.unknown-unknown

unknown-unknown，这个指的是自己不知道还有哪些不知道的事情，也就是超出自己知识体系的事情。

我个人有个体会，高负载系统中出现的问题中，有很大一部分问题产生的原因是我原先根本不了解的，比如jvm里某个bug，或者一些内核在实现中有一些特殊的机制，之前听都没听过。

这里有个误区，超出知识体系并不意味着不能分析问题。但是在遇到一些棘手的问题，超出了以往的知识体系，这时很有可能会产生焦虑感，认为这个问题不科学、无法解决，并且有很可能会做一些没有价值的事情，比如反复检查日志、反复重启、甚至开始论证这个问题不可能发生之类。

这个时候其实就没有很具体的方法了，不过还是一些思路给大家分享一下：对于这类场景可以做减法，尽可能缩小范围，当范围可控之后，再去了解相应的原理。

这里有几个具体方式：

1. 尝试重现问题，修改变量尝试是否能复现
2. 对比正常系统和异常系统的不同，找出异同点
3. 通过已有知识剔除异常中正常的部分，缩小异常范围
4. 看书或者教程，了解原理；看源码，了解实现机制

还是举个案例，前几天分析的一个tomcat突然请求变慢的问题，日志里无异常、性能没有瓶颈、线程数正常、通过工具也没找到什么新线索，还是不知道慢在哪了。

当时我的做法是先尝试复现问题，不管是测试环境压测、tcpcopy还是保留现场等等都可以用于复现现场，qcon上讲过这里也不重复了。

问题复现之后尝试缩小范围：一次http请求的过程包括tcp三次握手、应用accept连接、接收request、应用层处理、发送response、关闭连接这个过程，于是我用tcpdump和strace直接跟踪了网络包状况和系统调用，梳理了某一次调用的时间轴，发现时间浪费在三次握手和accept之间。

之后查看这部分tomcat源代码，找到了tomcat的一个bug：bio方式下如果应用有stackoverflow，那么线程会退出，但是连接计数没有减掉，导致新请求不能被accept。

以上是关于known-known,known-unknown,unkonwn-unknown，我的一些理解，在排查的时候可能会交替的遇到这几种场景，不过只要掌握好各自特点，逐个击破就好。

4.建议

下面给出一些系统设计方面的建议，其实在上面的内容中已经体现了，在这里只是总结一下。

首先，问题排查是复杂的，不可控的，所以不要把排查和解决混在一起，尽量先解决、再排查。解决的方式基本上都是那么几板斧：重启、回滚、扩容、降级、迁移，具体方案就不展开了。

其次，系统要尽可能的对外暴露内部状态和干预手段，比如说少打了一句日志，没把变量输出出来，那么出现问题的时候很不但要用某些复杂的工具去查询变量，而且很有可能要多绕一个大圈。

再次，系统是不稳定的，所以对于高可用架构设计来说，隔离是必须的，不管是何种依赖方式，都需要考虑“实在不行了”的情况。qcon上讲过，这里也不多说了。

最后，问题的原因、传播路径和现象不是一一对应的。同一个问题，这次的表现是多打了一行WARN日志，下次可能就是一次系统雪崩。墨菲定律，如果有可能出问题，那一定会出问题。

最后附上qcon的演讲地址，如果没看过，可以跟今天说的内容对比着看一下。 http://www.infoq.com/cn/presentations/typical-problems-of-weibo-in-large-scale-high-load-system

5.Q&A

• Q1:刚查了一下，那个wtool工具是自己写的吗？ 基于哪些工具实现的？

  A1:这个是自己写的，主要是基于脚本和现有工具的整合。github上有个开源版： https://github.com/qdaxb/wtool

• Q2:在线jvm的信息排查，是在开源工具上进行的封装，还是自己写的工具？

  A2:主要都是开源的，一小部分是自己写的。

• Q3:抗峰时的分流以及日常架构上的分流设计方案（包括应用端和数据库DAO层设计思路）

  A3:这个和本次分享的主题关系不是很大，稍后单独沟通吧。

• Q4:第一个业务查询工具如何做到能够持续好用？

  A4:一是把框架和逻辑分离，增加逻辑时不用改代码，写一个脚本就可以简单的完成二是尽可能的优化工具的效率，这个是问题排查工具的核心价值。

• Q5:系统出错了，你们排除问题时，怎么保证不影响线上呢？

  A5:首先是要解决问题，通过运维的一些介入手段把服务恢复，同时尽量保留现场（比如保留一台出问题的机器只摘除不重启） 其次是在通过监控或者日志初步定位原因之后在线下复现问题，这时候排查就没有什么心理负担了。

• Q6:不同语言如php/java的应用，还有不同的层面如网络/操作系统／数据库的问题的排查，都有什么模式和异同？

  A6:我理解思路上都是类似的：找线索、推测原因、再找线索证明，区别主要是问题的原因具体用到的工具可能不一样,现象基本上都是那么几种：慢了、死了、处理出错了。

• Q7:业务系统的日志，是通过外挂工具收集，还是要侵入到业务里面写日志？如果侵入的业务里面，有没有一些日志方案推荐？

  A7:有一部分是外挂工具，还有一部分是业务里面，不过业务里面指的也是业务的框架层去集中输出这些日志，具体写业务的人不用管。 日志方案我们主要用的scribe，也有一部分用logstash，运行的都挺好。

• Q8:线上出现请求block或请求慢时，一般会保留哪些现场数据？如果线下难以重现，线上问题的时间窗口也滑过去了，是不是可能会变成无解问题？

  A8:一般来说，不重启是最重要的； 其次，java会把jstack/jmap/jstat之类都来一遍，其它类型的linux程序主要会留gcore和各种指标类的数据，top/perf/strace。

• Q9:请教老师，做监控的话一些metric的阈值，你们是怎么设置的啊，是靠人工观察经验得出，还是使用了一些自动化比如机器学习的方案

  A9:一般根据请求量和监控系统的处理能力决定，一般来说只要请求量够大，采样率设多少没什么太大区别。

• Q10:java在请求无法响应的时候，这时候jdump需要很长的时间，线上无法服务，有没有更好，更快速的方法保留现场？

  A10:我们在dump的时候这台节点已经从线上摘掉了，所以慢不是问题。 如果不能摘，可以考虑用btrace，housemd这类工具直接挂到进程上分析，不过btrace有可能导致应用假死，几率几十分之一，慎用。

• Q11:业务出问题后是多个部门一起查找问题么？有些问题既要懂业务又要懂技术细节，在微博有多少人能达到您的排查问题水平，每次出问题都需要您出马么？有没有自动诊断问题工具？

  A11:问题自动诊断我也很想要，最近也想继续改进工具。不过更多的可能还是有工具自动把一些现象把帮我汇总出来，分析感觉还是做不到自动化。

原文地址： 【图文直播全文记录】微博在大规模、高负载系统问题排查方法