运维分析问题方法和思路
携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第16天,点击查看活动详情
这是写给初入运维小伙伴的,大佬们勿喷。许多初入运维的小伙伴在遇到问题时,会显得很慌乱,随便拿着少许报错,就上必应、百度等,在服务器上狂操作,既浪费了时间,又没有解决问题,本篇文章,可以和大家分享一下,小弟我是如何分析问题方法和思路。
从基础监控入手
遇到问题,最好花接近一分钟查查服务器基础环境,例如: cpu
负载情况、内存情况、磁盘使用率、磁盘inode
等、确定这些没问题后,再查询其他的服务。
这里举个小栗子:
本小学生刚毕业不久,还在一家小型游戏公司做运维,具体的业务是卡牌类休闲游戏,游戏架构是及其标准的微服务,各个服务之间使用我们自建的RabbitMQ
进行通信,在某个午间遇到了问题,所有用户在登录成提示登录成功,但是卡在登录界面,进不去大厅。收到消息后,立即将跳板机权限下放到开发,然后查询了接近1个小时,终于弄清楚了,登录服在用户登录成功后,向mq
发布了消息,而大厅服务器没收到! 最后发现,自建RabbitMQ
那台机器磁盘满了导致MQ
拒绝接收新请求,但是MQ
进程还是存在的,于是乎手动清理部分日志后,问题得以恢复。
如上问题,映射出一个问题,良好的监控系统至关重要,若没有,请在发生问题后,手动确认基础环境是否有问题,有些问题明明5分钟就可以解决问题的,却闹了接近2个小时得以解决,最后还要背锅。哦,这家公司后来倒闭了。
基础监控命令
内存
free -h
使用如上命令,可以看到目前服务器内存情况,注意,在centos 7.*
中需要关注的点为available
而非free
,例如
cpu负载
uptime
如上命令,请关注load average
即可,三个值,分别是 1分钟负载 、 5分钟负载 、 15 分钟负载。
而该值,取决于cpu
线程数,例如线程 ,最理想的负载情况应该是 16 * 0.8 = 12.8
,超过该值,就应该去找下具体原因了。
而cpu
线程数可以使用cat /proc/cpuinfo | grep -c processor
来看。
磁盘使用率
查看磁盘相关信息,可以使用df -h
和df -i
进行查询,前者查看磁盘使用率,而后者查询inode
使用率。
这里再补充一个小点
在遇到磁盘满了的情况下,需要删除日志,请不要使用
rm -f
进行删除,请使用>
将文件重定向空即可。
巧用日志查询
遇到问题后,在查询基础监控还是无法入手情况下,一定要查询下系统日志,目录在/var/log/
,当你发现出问题后,监控系统查询那段时间,都没任何数据上报,记得查询一下message
,查询下,是否是因为某些进程导致系统OOM
了。
这里也举个例子:
也是刚毕业不久,开发在抱怨,测试服务器登录不上去了,于是乎,手动尝试后,发现也不行,再次期间登录云平台准备查询监控,而后在等待3分钟后,又可以登录了,在查询监控后发现有一段监控是“空白”的,而机器又没有被重启,当时第一反应是系统“宕机”了(因为再次之前,这个云账号下有机器陆续在“宕机”,每隔几分钟又好了)。于是乎联系云厂商进行分析查看,最后分析的结果是某个进程OOM
了,而后在询问开发过程中,发现,有个程序大哥某段逻辑写错了,写成了死循环,既费cpu
又耗内存,最后导致OOM
了。
查询是否有进程oom
grep -i 'out of memory' message
最后才是应用日志
其实,在我遇到的绝大多数问题,都是我们自己的程序的Bug
或者异常引起的,那么为什么要先查询基础服务和系统日志呢? 傻孩子,晒过谷子么,当看天不好的时候,都是先收自家谷子,确保自家谷子收完了,有空了再去隔壁帮忙收别家的谷子呀,我们定位问题也是类似的。
这个时候一般就要下放权限,或者提供相关日志给程序,请他们帮忙协助定位问题,这个就没有什么技巧提供了,关键是看项目架构理解程度了,顺着看日志会方便的多。
总结
是不是有发现,始终没有提及网络分析,有了网络原因,这个有点复杂,所以就不在本篇讨论范围之类。
各位可能发现了,运维在遇到问题的时候,一般而言都是从底层慢慢网上查询,而程序遇到问题后,一般都是以顶层根据报错,或者猜想,慢慢向下查询,总之,目的都是解决该问题。前者适用于已经发布数月或者数年的系统,因为逻辑基本上都跑过了,报错基本上是因为某些底层、中间件抛错引起的,而后者主要是查询一些刚发布不久或者是正在开发中的项目。报错大部分是代码引起的。
其实想写的东西很多,但是不知道如何下笔,问题的呈现也是各种各样,但是万变不离其宗,其实还有一点,让我思考很久的,与其到处救火,不如做好防范措施。该监控的监控,该写程序自动管理的,就写程序。
怎么样,好玩吧,快来动动小手指,额,今天这个这个好像动不了小手指,今天,你学废了么?