金御网安

在排查故障前的五分钟,运维一般应该做什么?

发布时间:4年前热度: 1277 ℃评论数:

sec.png

作为运维人员我们可能有着肩负各种业务的性能优化以及排障经历,但或许你不曾记起每当发生故障的时候,前5分钟,你到底干了什么?为何说前5分钟很重要?这就犹如一个重症患者进入ICU病房后,需要分秒必争一样,否则处理不及时或不当都有可能让业务受到极大的损失。下面我们来看看运维人员应该在故障头5分钟应该做的事情......

“不要急忙上服务器去胡搞!”

一些小建议:

一定要搞清楚这个问题的表征。不能响应?报错了?

一定要弄清楚故障发生时间点。

一定要弄清楚故障是否可以重现。

一定要搞清楚故障有无规律性。例如每隔一段时间发生一次。

一定要搞清楚上次更新改了什么内容?代码?服务器环境?架构堆栈?

一定要弄明白故障影响了哪一部分用户。登录了的?注销了的?某个地区的?

一定要看有无架构相关文档可参考。

一定要看一下监控后台有无异常。例如Munin、Zabbix、Nagios等

一定要看日志集中管理后台有无相关日志。例如Loggly、Airbrake、Graylog等。

最后两个tips是最方便的信息来源,但是不要太期待:因为它们经常会没有记录到关键信息。因此我们还是要纠正排错方向往下深入排查。


看谁登录了服务器?

$ w

$ last

虽然有无其他人在服务器上也不是很要紧,但你也不想在排障的时候别人也在上面搞事情吧。就如掌勺的厨子只要一个就好。

看下之前的操作日志

$ history

查看之前登录服务器的人员的操作记录是有利于排障的。不过作为管理员也要注意不能触犯到别人的隐私。一个需要谨记的技巧:你应该设置环境变量HISTTIMEFORMAT来记录格式化日志,方便在排障的时候根据时间线索来追溯。最让人心塞莫过于一堆杂乱无章的命令操作日志,鬼才知道什么时候命令被执行了。

看下正在运行的进程


$ pstree -a

$ ps aux

ps aux命令可以给出比较详尽的进程运行信息,pstree -a命令展示进程树可以让你知道进程的调用关系。

看正在监听端口的服务

$ netstat -ntlp

$ netstat -nulp

$ netstat -nxlp

我建议分开执行上面三条命令,主要是因为我不喜欢把所有类型的端口监听结果堆在一块看。netstat -nalp 命令就会打印全部端口,不过还是有所区分类型。敲这些命令时我不使用numeric选项(鄙人浅见,IP看起来更友好)

要确认在跑的服务是否正确运行。查看不同的监听端口。你可以通过ps aux命令输出结果匹配对应端口的进程PID,这在你排查多个 Java或者Erlang进程并发运行的时候很有帮助。我们推荐在服务器上面只有少量的服务在运行,在必要的时候可以适当增减服务器数量。如果你看到30多个监听端口的时候,你脑海里就要想到哪些端口是可以被清理的或者可以重新整理的。

看下CPU和内存

$ free -m

$ uptime

$ top

$ htop

以上命令可以看出:

还有空闲的内存吗?是否发生了换入换出?

CPU还空闲吗?服务器有多少颗CPU可以用?它们中某些核心是否已经超负载了?

服务器上是什么程序导致了高负载?平均负载是多少?

看下硬件状态

$ lspci

$ dmidecode

$ ethtool

我们有很多服务器还是裸机,以上命令可以帮助你:

查看RAID卡(有无BBU电池?)、CPU、空闲内存插槽。这些可能启示你如何提高服务器性能。

你的网卡配置正确吗?你的网卡是不是半双工状态?只有10MBps?有无发送或接收的错误?

IO性能

$ iostat -kx 2

$ vmstat 2 10

$ mpstat 2 10

$ dstat --top-io --top-bio

这些命令对全面分析你的后端性能非常有帮助:


检查磁盘使用情况:是否达到了100%的磁盘空间使用率

swap分区现在被用到了吗(看si/so)?

CPU使用情况:系统在用?用户进程在用?还是被抢占了(虚拟机可能发生)?

dstat命令一直是我的最爱:可以看到谁在消耗IO。是MySQL在耗尽资源吗?还是你的PHP进程?

磁盘挂载点和文件系统

$ mount

$ cat /etc/fstab

$ vgs

$ pvs

$ lvs

$ df -h

$ lsof +D / /* beware not to kill your box */

有多少文件系统被挂载?

是否有某些服务专用的文件系统?可能是MySQL专用的。

文件系统用了什么挂载参数:noatime?默认参数?有没有被重新挂载为只读的文件系统?

还有磁盘空间剩余吗?

有没有一些大文件(已经被删除了)没有被刷新掉?

你还可以在磁盘空间不足的时候扩展分区大小吗?

内核,中断和网络使用情况

$ sysctl -a | grep ...

$ cat /proc/interrupts

$ cat /proc/net/ip_conntrack /* may take some time on busy servers */

$ netstat

$ ss -s

你的中断请求在CPU核心之间被均衡分配了吗?或者某个核心因为网络中断、raid卡中断等请求导致超载?

swappinness内核参数设置多少了?60对工作站可能比较合适,但是对于服务器就不那么合适了:你可不想你的服务器发生换入换出吧?另外你的swapping进程会在数据读写磁盘的时候导致死锁。

conntrack_max内核参数是否设置的足够高来处理你的流量?

不同状态下的TCP连接的保持时间是多长?(如TIME_WAIT等)

netstat命令可能在显示全部连接的时候有点慢,你可以用ss命令替代。

系统日志和内核消息

$ dmesg

$ less /var/log/messages

$ less /var/log/secure

$ less /var/log/auth

看是否有错误或者警告信息:看下连接数是不是过多了?

是否看到一些硬件错误,或者文件系统错误?

你能将这些事件与之前得到的信息在时间上联系起来吗?

计划任务

$ ls /etc/cron* + cat

$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

是否有一些计划任务执行太频繁了?

是否一些用户的计划任务我们没发现?

在问题发生的时候有没有备用方案?

应用日志

应用日志一般都很多,但你不可能有很多时间花在上面。你需要专注于比较明显的内容,如下面所示的LAMP环境排障案例:

Apache & Nginx:寻找访问和错误日志里面5xx错误,是否有limit_zone错误日志

MySQL:在mysql.log日志文件里找错误信息,如看有无损坏的表,有没有看到进程中有innodb修复线程在跑。通过慢日志来判断是否有磁盘/索引/查询的问题。

PHP-FPM:如果你开启了php-slow日志,分析并看有无错误日志(php、mysql、memcache等),如果没有,往下看。

Varnish:通过varnishlog和varnishstat命令,看命中/未命中比率。你是否没有在你的配置文件里配漏了一些规则导致终端用户直接回源访问?

HA-Proxy:后端状态如何了?健康检查是否成功?是前端还是后端达到了最大队列大小?

总结分析

经过以上前5分钟(也许要10分钟)的排查分析示例,你应该有个更深的理解:

是什么东西在跑?

故障与什么指标相关?(IO?硬件?网络?还是配置如代码未优化、内核未调优等)

你是否发现了什么规律:如数据库索引使用不当、太多apache子进程。

你需要找到真正导致问题的根源。不然,你就应该站在一个更好的位置上,利用你之前发现的问题点继续深入排查。

排查故障

手机扫码访问