Linux的业务故障排查

工欲善其事,必先利其器

Linux自身以及开源社区已经提供了很多工具,帮助我们快速定位问题。我们需要做的,就是在故障发生之前,确保机器上安装了这些工具,并进行适当的配置,使其正常运转,下面列举几个常用的问题诊断工具。

 

syslog/syslog-ng  记录系统服务进程和操作系统本身的日志,我们可以对日志输出的内容、输出到哪些文件进行配置,利用这些日志,可以查到诸如机器重启时间、命令执行记录等信息,查看/var/log/messages里记录的一些异常信息,往往是我们处理问题的第一步。

 

strace  跟踪进程运行过程中产生的系统调用,当程序、命令执行挂死或缓慢时,我们可以通过分析相关系统调用信息,缩小问题范围、查找故障原因。

 

atop  通过定时采样系统资源使用情况、进程运行状态,为我们提供了较全面的操作系统信息。

 

LKCD/kdump  是一种内核转储机制,当系统发生kernel crash时,它将寄存器中的值、内存中的堆栈信息保存到磁盘中,形成的vmcore文件提供了crash时间点所有进程的状态、内存的使用情况等信息,根据寄存器的值,我们甚至能找到内核中相应的代码进行分析。

 

除以上所列,ping、ps、lsof、dmesg等查询命令也被经常用到。

 

现在,我们面前摆放着各式各样、功能不同的工具,有了这么一个强大的工具套件,是否意味着来一个问题我们就能解决一个,来两个问题我们就能消灭一双呢?

 

非也。仅仅拥有齐备的问题诊断工具是远远不够的,更需要我们掌握怎么使用(How)以及什么时候(When)使用这些工具、熟悉Linux操作系统本身,甚至需要深入了解Linux内核源码。是否能解决、快速解决Linux故障问题,取决于问题处理人员的技能水平。

 

问题处理与个人能力提升

当故障发生时,尽早恢复业务固然重要,但对个人而言,恢复业务并不是目的,更多地是通过处理问题过程提升自己的技能。进行Linux服务器相关故障处理的时,我们需要考量以下几方面:

  1. 快速解决问题
  2. 提升自身技能
  3. 向高人求助

某年某月某日,一个系统启动过程中挂死的问题需要你处理,这时恰好你身边就有一位Linux专家,他对系统启动过程了如指掌。这时你有两种选择:

1.  问Linux专家,问题立马可以得到解决

2.  查阅相关资料,自己解决问题

 

如果你尝试依靠自己的能力解决该问题,或许你需要花费很多时间和精力,查阅很多介绍Linux操作系统启动过程的资料,但因此你也了解了各个启动阶段的功能、对应加载的服务项,甚至能学到在不同启动阶段挂死的恢复处理方法。

 

相比直接使用google搜索答案或问相应专家,独立解决问题,即使问题最终没能靠自身力量得到解决,但学习和独立思考的过程也让自身的技能得到了提升。

Linux的业务故障排查

 

但也并非所有问题都有必要作深入研究,当问题属于以下类型:

  1. 十分紧急,稍有延误就会带来重大损失
  2. 非自身发展领域相关

那我们不妨采取另一种策略,google之,或找相关领域的专家迅速地将问题解决。

 

问题处理参考方法

现在你手头有很多可用于问题诊断的工具,你也认识到可以通过独立处理问题,来提升自身技能,接下来就真正进入问题处理环节咯,具体怎么进行问题处理呢?

 

首先我们需要收集问题相关的信息:

1.问题现象

处理问题之前,首先得了解清楚问题现象。

  业务出现异常,是响应慢还是完全没有响应?

  主机僵死,能否ping通?能否进行终端切换?是crash还是hang?

 

2.发生时间

如果问题发生的时间有一定规律,这时我们可以通过排查系统的定时任务,从而找出问题根因;另外,根据时间点我们可以迅速找到相关日志,减少查找日志花费的时间。

 

3.做过哪些操作

安装了补丁包?修改了系统配置参数?了解问题出现之前做了什么操作,能为我们处理问题提供指引。

 

4.OS相关信息

利用工具可收集问题出现时间点CPU负载、内存利用、磁盘IO、网络收发包等OS信息,这些信息为我们提供了较为全面的参考。

为了全面地收集OS信息,需要执行很多命令。这时,可以将这些命令集合到一个脚本中,利用脚本进行信息收集,节省了输入命令的时间,对于无法自行登录的远程服务器,使用脚本收集更显便捷。

 

总之,信息收集越全越好。即使自己找不出问题根因,后续向他人求助时,也不会因为缺少日志信息而犯愁。

 

了解了问题现象,又有了日志信息,那我们就可以结合日志对问题进行分析了。

首先判别问题类型、缩小问题范围:

  是硬件问题,还是软件问题?

  是业务进程层面的,还是系统层面的?

  CPU、内存、网络、磁盘,哪一方面出现异常?

 

对于可复现(reproducible)的问题,我们可搭建环境进行问题复现,在实验环境中对问题处理方法进行验证,可降低对现网环境的影响;对于复杂地、不可复现的问题,我们就得做好长期作战的准备了,除了收集以上所列信息外,还需记录问题处理的过程、尝试过哪些处理方法等,这样,当有其他人参与进来一同处理该问题的时候,就能更快速地熟悉问题情况。

 

小结

本文讨论了Linux故障处理的方式方法。能否顺利解决故障,首先取决于我们的技能水平,其次需要依靠各种问题诊断工具。处理问题的过程可以与个人技能提升很好地结合起来,好的处理方式需要经验的积累,但个中也有规律可寻。

 

Linux的业务故障排查

上一篇:开发者学堂课程干货总结——Dubbo 分布式服务治理实践(五)


下一篇:spring-boot 速成(10) -【个人邮箱/企业邮箱】发送邮件