设为首页 加入收藏

TOP

如何排查服务可用性问题(一)
2017-11-28 09:13:48 】 浏览:374
Tags:如何 排查 服务 可用 问题

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的演讲里也提到了一些。无论是系统提供的,还是第三方的,还是自己开发的都可以辅助我们发现更多的线索。

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

  • 30秒获取整体服务情况:请求量、响应时间分布、错误码分布。这里主要是用业务的监控系统。
  • 3分钟了解某台机器的负载情况:最耗cpu的线程和函数(cpu)、tcp连接
首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇ArrayList 底层数组扩容原理 下一篇hbase 的架构及设计

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目