微博在大规模、高负载系统问题排查方法。文尾有彩蛋

2017-11-29 15:34:23 运维帮

秦迪,微博平台及大数据技术专家,2013年加入微博,负责微博视频服务、通讯服务等核心系统的设计和研发、微博平台基础工具的开发和维护,并负责微博平台的架构改进工作,在工作中擅长排查复杂系统的各类疑难杂症。爱折腾,喜欢研究从内核到前端的所有方向,近几年重点关注大规模系统的架构设计和性能优化,重度代码洁癖:以code review为己任,重度工具控:有现成工具的问题就用工具解决,没有工具能解决的问题就写个工具解决。业余时间喜欢偶尔换个语言写代码放松一下。


背景


首先来介绍一下背景,微博主要面对的是高并发、大数据量、高负载的业务压力,并且伴随着热点事件会有突发的请求峰值。作为典型的互联网后端服务之一,微博平台部署了大规模的基于Linux系统的集群,使用Java作为主要语言,使用了一些外部的框架比如Tomcat、Storm、Hbase等,也应用了一些自研的系统,比如RPC框架Motan、服务发现Config Service等。不同企业和行业采用的方案可能有区别,但从问题排查这个角度来说都是类似的。

排查方法及线索

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


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


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


例2:某服务由于内存泄漏,导致操作系统消耗swap了、处理变慢、依赖它的服务超时、处理线程堆积,最终导致它的服务不可用。在这个例子中,内存泄漏是根本原因,服务不可用是现象,其他都是传播路径。


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


例3:关于应用吃swap的问题,原因可以是堆外内存泄漏,可以是机器上启动了其他消耗内存的程序,还可以是numa配置引发的。同样,堆外内存泄漏可能导致吃swap,也可能导致OOM,还可能什么现象都没有。


所以单纯地看一些案例,了解“A会引发B”,对于今后问题排查来说会有一些帮助,但是帮助不大,在实际排查的过程中很多案例不能直接通过现象得出原因。更进一步,可以通过某个案例去了解“在出现B现象时,我可以通过某某手段去分析”,这种学习手段的办法会好一些,但是还不够。


随着新技术的使用和越来越高的访问峰值,新的问题层出不穷,如果在工作中经常引入新技术,必然会碰到无法通过现有案例解释的问题,此时更多是学习一些解决问题的思路。


现在还是回到本节的内容——排查问题。


我理解的排查就是一步步地收集线索、分析线索最终定位原因的过程,本节要讲的是如何更有效地发现和利用线索。总的来说,可以把问题排查分成以下这3个方面。


1.known-known

就是你想要知道,并且已经获取到的一些信息。比如日志业务表现、监控图上反映出来的信息。一般来说,比较容易获取的信息大概有以下这些。

—服务表现:问题的具体表现(出错、超时等)、应用日志、依赖服务的状态等。

—系统状态:操作系统指标(系统管理的各种资源的状态、系统日志等)、VM指标(主要是GC)。

—硬件指标:CPU、内存、网络、硬盘是否达到瓶颈。

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



系统的监控用的是新浪内部的监控系统,也可以用开源的工具,比如Cacti/Zabbix,这里就不展开讲了。


一般的监控系统应该可以提供上面这些信息,而对于分布式的系统来说,除了上面这些独立的监控数据外,还有一个非常重要的线索,就是已知数据的定量分析和归类,比如重现概率、时间点、问题的共同特征。这些线索非常有可能因为描述得不够清楚而被忽略,但在实际排查中却很有价值。


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


例4:以前出现过一次线上未读数偶发清不掉的问题。出现问题时没有发现明显的异常,日志也没有问题,当时我们重启了前端服务,但是没有效果。之后我们统计了一下1分钟内出现问题的请求占正常请求的比例,大约是1/8,而这个服务依赖的另一个服务正好是8个实例,于是我们进一步统计出问题的请求,果然都调用到了同一个实例,于是当时下掉了这个可能有问题的实例,服务就恢复了。在之后通过进一步分析有问题的实例,定位了原因。


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


2.known-unknown

这是指你想要知道但目前还不知道的信息,一般指不能直接看到的信息。可能你会疑惑为什么会有这个分类,它跟上面有什么区别。


例5:应用出现了慢请求问题,业务逻辑的处理时间好像没问题,假设这个时候我记起曾看到TCP文章里说socket有个接收队列,我隐约感觉问题可能出现在这里,应该看看有没有堆积,但是却不知道怎么看,这个时候要怎么办?


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


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


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


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


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


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

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

  • —3分钟了解某台机器的负载情况:最耗CPU的线程和函数(CPU)、TCP连接状态统计和buffer堆积状态(网络)、程序的内存分布,最耗内存的对象(内存)、当前是哪个程序在占用磁盘I/O、GC情况。这里主要是Linux和Java的一些辅助工具:top/perf/netstat/iftop/jmap/jstat等等。

  • —3分钟了解请求的链路情况:网络传输、系统调用、库函数调用、应用层函数调用的调用链、输入、输出、时长。这里也有Linux和Java的一些辅助工具,TCPdump/strace/ltrace/btrace/housemd等。最近我们也在完善用于集群的调用链分析工具trace,希望在足够完善之后能开源出来。

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


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


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


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


3.unkonwn-unknown

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


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


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


下面是几个具体的解决方式:

  • —尝试重现问题,修改变量后尝试是否能复现。

  • —对比正常系统和异常系统的不同,找出异同点。

  • —通过已有知识剔除异常中正常的部分,缩小异常范围。

  • —通过看书或者教程了解原理;通过看源码了解实现机制。


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


当时我的做法是先尝试复现问题,不管是测试环境压测、TCPcopy还是保留现场等都可以用于复现现场。


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


之后通过Accept关键字在Tomcat源代码中查找,分析了Accept相关的代码,找到了Tomcat的一个Bug:在bio方式下如果应用有stackoverflow,那么线程会退出,但是连接计数没有减掉,这会导致新请求不能被Accept。


特别说一下,这个Bug存在于Tomcat 7.0.42之前的版本,后面的版本修复了这个问题。


总结


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


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


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


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


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


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


如果有读者没看过我之前在Qcon的演讲地址,可以跟本节的内容对比着看一下:http://www.infoq.com/cn/presentations/typical-problems-of-weibo-in-large-scale-high-load-system

疑问与解惑

Q:在线JVM的信息排查,是在开源工具上进行的封装,还是自己写的工具?

主要都是开源的,一小部分是自己写的。


Q:日常分析问题的工具如何能做到持续好用?

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


Q:当系统出错了,在你们排除问题的同时,怎么保证不影响线上呢?

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


Q:不同语言(如PHP/Java)的应用,还有不同的层面(如网络/操作系统/数据库)问题的排查,都有什么模式和异同?

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


Q:业务系统的日志,是通过外挂工具收集,还是要侵入到业务里面写日志?如果侵入到业务里面,有没有一些日志方案可以推荐?

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


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

一般来说,不重启是最重要的。其次,Java会把jstack/jmap/jstat之类都来一遍,其他类型的Linux程序主要会留gcore和各种指标类的数据,top/perf/strace。


Q:想请教一下,做监控的话,对一些metric的阈值,你们是怎么设置的?是靠人工观察得经验得出,还是使用了一些自动化(比如机器学习)的方案?

一般根据请求量和监控系统的处理能力来决定,通常来说,简单的指标分析都是靠经验定的阈值,但针对一些复杂的、经常变化且与业务相关的阈值,我们会根据历史数据自动设置。


Q:Java在请求无法响应时,这时候jdump命令需要很长的时间,线上无法服务,有没有更好、更快速的方法可以保留现场?

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


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

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

 

本文节选自《高可用架构(第1卷)》一书


内容提要


《高可用架构(第1卷)》由数十位一线架构师的实践与经验凝结而成,选材兼顾技术性、前瞻性与专业深度。各技术焦点,均由极具代表性的领域专家或实践先行者撰文深度剖析,共同组成“高可用”的全局视野与领先高度,内容包括精华案例、分布式原理、电商架构等热门专题,及云计算、容器、运维、大数据、安全等重点方向。不仅架构师可以从中受益,其他IT、互联网技术从业者同样可以得到提升。

 

购买链接点击「阅读原文


留言点赞抢书活动参与方式


在文末留言

“对高可用架构一书的想法或想读此书的理由”

截止至2017年 12 月 2 号前

留言被点赞最多的前5名用户

可以获得《高可用架构》一书