运维人员处理服务器故障的方法总结

我们团队为上一家公司承担运维、优化和扩展工作的时候,我们碰到了各种不同规模的性能很差的系统和基础设备(大型系统居多,比如CNN或者世界银行的系统)。要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档,基本上这过程都会惨痛到让我们留下深刻的记忆。

遇到服务器故障,问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手:

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面,你需要先搞明白对这台服务器有多少已知的情况,还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有:

故障的表现是什么?无响应?报错?
故障是什么时候发现的?
故障是否可重现?
有没有出现的规律(比如每小时出现一次)
最后一次对整个平台进行更新的内容是什么(代码、服务器等)?
故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?
基础架构(物理的、逻辑的)的文档是否能找到?
是否有监控平台可用? (比如Munin、Zabbix、 Nagios、 New Relic… 什么都可以)
是否有日志可以查看?. (比如Loggly、Airbrake、 Graylog…)
最后两个是最方便的信息来源,不过别抱太大希望,基本上它们都不会有。只能再继续摸索了。

二、有谁在?

代码如下:

$ w
$ last

用这两个命令看看都有谁在线,有哪些用户访问过。这不是什么关键步骤,不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。(ne cook in the kitchen is enough.)

三、之前发生了什么?

$ history查看一下之前服务器上执行过的命令。看一下总是没错的,加上前面看的谁登录过的信息,应该有点用。另外作为admin要注意,不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下,等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令,同样会令人抓狂的。

四、现在在运行的进程是啥?

代码如下:

$ pstree -a
$ ps aux

这都是查看现有进程的。 ps aux 的结果比较杂乱, pstree -a 的结果比较简单明了,可以看到正在运行的进程及相关用户。

五、监听的网络服务

代码如下:

$ netstat -ntlp
$ netstat -nulp
$ netstat -nxlp

我一般都分开运行这三个命令,不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项 (鄙人一点浅薄的看法:IP 地址看起来更方便)。

找到所有正在运行的服务,检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行,能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点,必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着,那还是做个记录,回头有空的时候清理一下,重新组织一下服务器。

六、CPU 和内存

代码如下:

$ free -m
$ uptime
$ top
$ htop

注意以下问题:

还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?
还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?
服务器最大的负载来自什么地方? 平均负载是多少?

七、硬件

代码如下:

$ lspci
$ dmidecode
$ ethtool

有很多服务器还是裸机状态,可以看一下:

找到RAID 卡 (是否带BBU备用电池?)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
网卡是否设置好? 是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?

八、IO 性能

代码如下:

$ iostat -kx 2
$ vmstat 2 10
$ mpstat 2 10
$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

检查磁盘使用量:服务器硬盘是否已满?
是否开启了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? default? 有没有文件系统被重新挂载为只读模式了?
磁盘空间是否还有剩余?
是否有大文件被删除但没有清空?
如果磁盘空间有问题,你是否还有空间来扩展一个分区?

十、内核、中断和网络

代码如下:

$ sysctl -a | grep ...
$ cat /proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy servers */
$ netstat
$ ss -s

你的中断请求是否是均衡地分配给CPU处理,还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了?
SWAP交换的设置是什么?对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了:你最好永远不要让服务器做SWAP交换,不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大,能应付你服务器的流量?
在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的?
如果要显示所有存在的连接,netstat 会比较慢, 你可以先用 ss 看一下总体情况。
你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息

代码如下:

$ 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(Linux+Apache+Mysql+Perl)应用环境里:

Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。
MySQL; 在mysql.log找错误消息,看看有没有结构损坏的表, 是否有innodb修复进程在运行,是否有disk/index/query 问题.
PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …),如果没设定,赶紧设定。
Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比. 看看配置信息里是否遗漏了什么规则,使最终用户可以直接攻击你的后端?
HA-Proxy; 后端的状况如何?健康状况检查是否成功?是前端还是后端的队列大小达到最大值了?

结论

经过这5分钟之后,你应该对如下情况比较清楚了:

在服务器上运行的都是些啥?
这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。
这个故障是否有你熟悉的一些特征?比如对数据库索引使用不当,或者太多的apache后台进程。
你甚至有可能找到真正的故障源头。就算还没有找到,搞清楚了上面这些情况之后,你现在也具备了深挖下去的条件。继续努力吧!

原文链接:First 5 Minutes Troubleshooting A Server

(0)

相关推荐

  • 运维人员处理服务器故障的方法总结

    我们团队为上一家公司承担运维.优化和扩展工作的时候,我们碰到了各种不同规模的性能很差的系统和基础设备(大型系统居多,比如CNN或者世界银行的系统).要是再赶上修复时间紧.奇葩的技术平台.缺少信息和文档,基本上这过程都会惨痛到让我们留下深刻的记忆. 遇到服务器故障,问题出现的原因很少可以一下就想到.我们基本上都会从以下步骤入手: 一.尽可能搞清楚问题的前因后果 不要一下子就扎到服务器前面,你需要先搞明白对这台服务器有多少已知的情况,还有故障的具体情况.不然你很可能就是在无的放矢. 必须搞清楚的问题

  • Linux企业运维人员常用的150个命令分享

    本文将向大家介绍Linux企业运维人员常用的150个命令,如有不足之处,还望海涵.当然更希望大家留言指出.希望对大家有所帮助! 命令 功能说明 线上查询及帮助命令(2个) man 查看命令帮助,命令的词典,更复杂的还有info,但不常用. help 查看Linux内置命令的帮助,比如cd命令. 文件和目录操作命令(18个) ls 全拼list,功能是列出目录的内容及其内容属性信息. cd 全拼change directory,功能是从当前工作目录切换到指定的工作目录. cp 全拼copy,其功能

  • 利用python为运维人员写一个监控脚本

    前言: 一直想写一个监控方面的脚本,然后想到了运维这方面的,后来就写了个脚本,下面话不多说了,来一起看看详细的介绍吧. 准备: psutil模块(基本使用方法可以参考这篇文章:http://www.jb51.net/article/65044.htm) 正文: import os import time import re import smtplib from email.mime.text import MIMEText from email.header import Header imp

  • Python+微信接口实现运维报警

    说到运维报警,我觉得都可以写个长篇历史来详细解释了报警的前世来生,比如最早报警都是用邮件,但邮件实时性不高,比如下班回家总不能人一直盯着邮箱吧,所以邮件这种报警方式不适合用来报紧急的故障,日常磁盘利用率监控什么的可以用它来报没问题,网站宕机不能访问这种故障,用它就明显不合适了,那对这种业务稳定性要求比较高的业务,后来就发展成了用短信,就是公司买个短信机,提供一个http接口,然后运维人员写脚本把收集到的异常数据写入文件,然后脚本实时检测如果这个文件不为空,就调用短信机接口把文件里的内容发送出去,

  • 运维的85条规则

    1.容量第一,优化第二--这条规则在故障发生时生效.在宕机的时候别研究什么优化,先恢复设备. 2.保留所有可以捕获的记录--以 PostgresQL 为例,包括有 WAL 文件,Slony 复制,快照技术,基于硬盘的 DB 版本(快照附带的) 3.不要因为优化引入更多问题.通常我们解决问题时做出来的东西都会转变成之后运维工作的负担.请确认为运维工作开发的那些工具已经完全交付使用.这些东西经常无法正常运行结果要返回开发组重来.更重要的,这种变更请求通常会打破团队原本安排好的工作计划. 4.保持简单

  • 微信运维交互机器人的示例代码

    前言 今年五月份参加Oracle开发者大会,在会议上看到智能AI在运维方面的应用场景;讲师现场展现了一款能够结合上下文对话的智能AI,通过聊天方式完成运维工作. 会议后对该款智能AI机器人念念不忘,由于人工智能AI学习成本较高,寻思着是否能够写一套低配版运维交互机器人; 思考 初期期望该机器人能够: 通过手机能够处理简单的故障 不智能但至少配置能够灵活变更 有了具体的目标, 再考虑具体实现方案, 主要思考几个点: 应用载体 我期望这个载体是一款常用的手机APP;现有环境中微信企业号适合干这个事情

  • 10大HBase常见运维工具整理小结

    摘要:HBase自带许多运维工具,为用户提供管理.分析.修复和调试功能.本文将列举一些常用HBase工具,开发人员和运维人员可以参考本文内容,利用这些工具对HBase进行日常管理和运维. HBase组件介绍 HBase作为当前比较热门和广泛使用的NoSQL数据库,由于本身设计架构和流程上比较复杂,对大数据经验较少的运维人员门槛较高,本文对当前HBase上已有的工具做一些介绍以及总结. 写在前面的说明: 1) 由于HBase不同版本间的差异性较大(如HBase2.x上移走了hbck工具),本文使用

  • Python运维之获取系统CPU信息的实现方法

    使用Python进行运维工作的时候有时候需要获取CPU的信息,这在psutil模块库的帮助下非常容易实现. 常见的CPU信息有以下几种: 1,用户时间以及百分比: 2,系统时间以及百分比: 3,空闲时间以及百分比: 4,CPU的硬件信息: 前3个中的时间可以采用cpu_times方法获取,百分比可以使用cpu_times_pcercent获得. 简单的示范如下: In [9]: importpsutil In [10]:psutil.cpu_times() Out[10]: scputimes(

  • linux系统Ansible自动化运维部署方法

    ansible是新出现的 自动化 运维工具 , 基于Python研发 . 整合了众多老牌运维工具的优点实现了批量操作系统配置.批量程序的部署.批量运行命令等功能,下面就看一下如何部署 在命令行,提取Ansible源代码,git clone git://github.com/ansible/ansible.git --recursive 如下图所示 进入安装目录 cd ./ansible 目录下, 执行安装source ./hacking/env-setup -q 如果系统没有安装过pip,先安装

  • 运维角度浅谈MySQL数据库优化(李振良)

    一个成熟的数据库架构并不是一开始设计就具备高可用.高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.当然,有测试工程师的团队

随机推荐