运维分析问题方法和思路

携手创作，共同成长！这是我参与「掘金日新计划 · 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或者异常引起的，那么为什么要先查询基础服务和系统日志呢？ 傻孩子，晒过谷子么，当看天不好的时候，都是先收自家谷子，确保自家谷子收完了，有空了再去隔壁帮忙收别家的谷子呀，我们定位问题也是类似的。

这个时候一般就要下放权限，或者提供相关日志给程序，请他们帮忙协助定位问题，这个就没有什么技巧提供了，关键是看项目架构理解程度了，顺着看日志会方便的多。

总结

是不是有发现，始终没有提及网络分析，有了网络原因，这个有点复杂，所以就不在本篇讨论范围之类。

各位可能发现了，运维在遇到问题的时候，一般而言都是从底层慢慢网上查询，而程序遇到问题后，一般都是以顶层根据报错，或者猜想，慢慢向下查询，总之，目的都是解决该问题。前者适用于已经发布数月或者数年的系统，因为逻辑基本上都跑过了，报错基本上是因为某些底层、中间件抛错引起的，而后者主要是查询一些刚发布不久或者是正在开发中的项目。报错大部分是代码引起的。

其实想写的东西很多，但是不知道如何下笔，问题的呈现也是各种各样，但是万变不离其宗，其实还有一点，让我思考很久的，与其到处救火，不如做好防范措施。该监控的监控，该写程序自动管理的，就写程序。

怎么样，好玩吧，快来动动小手指，额，今天这个这个好像动不了小手指，今天，你学废了么？