【人在运维 途_14】打扫干净屋子再请客
【人在运维 途_13】由LDAP服务器无法登陆来谈谈分析问题的思路
http://www.zhishiwu.com/os/201304/205318.html
有些时候木有更新人在 途之运维的系列鸟、今儿个题目稍显文艺
不过、俺觉得、这种方格不赖、可能后续的文全是这样咯
人在运维 途总会和服务器故障不期而遇、磕磕绊绊也在所难免
但是在轻视逻辑的状态下拼命找答案、只会浪费更多的时间、这是非常危险的
我记得福尔摩斯有提过:
在没有事实作为参考以前妄下猜测(论点)是个很可怕的错误
感觉不正确的人总是用事实去套自己固有的猜测(论点)
而不是按正确的方法根据得到的事实来推导结论,看它能否吻合已得到的事实
其最重要一点(没有之一哦)是、要先对故障现场了如指掌!!
接下来是一些做法、让大家更容易理解福尔摩斯话里所谓的"事实"、诸位看官请笑纳
⑴ 穿越问题的前世今生
莫一下子扎入服务器、你需要先明白对这台服务器有多少已知情况
必须理清的问题大致如下图所示:
⑵ 有谁在?
有道是、一山不容二虎、除非、、、、哈哈
目前都有谁在线?有哪些用户访问过?想知道吗?哦、、那就看这哥俩了
● w
● last
⑶ 之前发生了什么?
秋后算账也要先翻翻老底子哟、厚不厚也就这一回咯
可借助:
① 命令:history
② 变量:HISTTIMEFORMAT
这两人可是衣宽带水的烂兄烂弟呀、离了谁、谁就活得抓狂哦
⑷ 现在运行的进程是啥?
这个比较容易哈、条条大路通罗马、譬如:
● pstree -a
或者、、、
● ps aux
、、、、、
⑸ 监听的网络服务
话不多说、亮三把杀手锏唬唬大伙
● netstat -lntp
● netstat -lnup
● netstat -lnxp
至于含义嘛、房事不懂问天涯啦
⑹ CPU & 内存
在这里、偶感觉有点解方程的味道、
利用几个命令/工具、来回答几个问题
这个、这个、这、、貌似回到了遥远的初中、那时、我还年轻
比如、方程式有:
● free -m
● uptime
● top
● htop
比如、问题是:
① 还有空余内存否?是否使用了swap?
② 还有剩余CPU否?几核的?是否有某些核负载过多?
③ 服务器最大负载来自哪里?平均负载是多少?
⑺ 硬件
● lspci
● ethtool
● dmidlecode
如有很多服务器还是裸机状态、可以看一下:
① 找到 RAID 卡(是否带 BBU备用电池?)、CPU、空余的内存插槽
② 网卡是否设置好?是否正运行在半双工状态?速度是10MBps?有TX/RX报错吗?
⑻ IO 性能
● iostat -kx 2
● vmstat 2 10
● mpstat 2 10
● dstat --top-io --top-bio
这些命令对后端优化好处N多:
① 检查磁盘使用量、磁盘是否已满?
② 是否开启了swap交换模式(si/so)
③ CPU被谁占用?
④ dstat可以看到谁在进行IO:是MySQLD 还是 PHP 等
⑼ 挂载点和文件系统
● mount
● cat /etc/fstab
● vgs
● pvs
● lvs
● df -h
回答以下问题:
① 一共挂载了多少文件系统
② 有没有某个服务专用的文件系统
③ 文件系统的挂载选项什么
④ 是否有大文件被删除但空间未被释放
⑤ 是否还有空间来扩展一个分区
⑽ 内核、中断和网络
● sysctl -a | grep ...
● cat /proc/interrupts
● cat /proc/net/ip_conntrack
● netstat
● ss -s
回答以下问题:
① 显示所有存在的连接、netstat可能较慢、ss可先了解总体
② 在不同状态下(TIME_WAIT....)TCP连接时间的设置如何
③ conntrack_max是否设置的足够大、能应付你服务器的流量
④ SWAP交换设置是什么?对于工作站来说 swappiness 设为 60 就好
⑤ 中断请求是否均衡地分配给CPU处理?
⑾ 系统日志和内核消息
● dmesg
● less /var/log/messages
● less /var/log/secure
● less /var/log/auth
回答以下问题:
① 查看错误和告警信息、如是否存在过载的连接数
② 看看是否有硬件错误或文件系统错误
③ 分析这些错误事件和前面发现的疑点进行时间上的比对
⑿ 定时任务
① 是否有某个定时任务运行过于频繁?
② 是否有某些用户提交了隐藏的定时任务?
③ 在出现故障的时候、是否正好有某个备份任务在执行?
⒀ 其他应用的系统日志
这里是个硕大的、蛋碎的、抓狂的、(此处省略N个形容词)、、、、的工程
比如:Oracle的alert和trc文件
Nagios的日志
....
经过如此一番折腾、我想、对故障现场也大概有些理解了、这时、我们才可开始 troubleshoting、
行文到此进入尾声了、既然是最后、那么问题又来鸟
大伙都听过"水果蔬菜在'最后一公里' 坐地涨价"的老大难问题吧
这是网络上大行其是的最后一公里问题哦、木有听过的、感觉google
但、、、、别捉急呀、我们不谈最后、在服务器排除问题时、还看今朝哈
来来、来、排好队、1、2、3、、大家一起喊、我们的目标是"最前十分钟" !!!