一、前言
二、簡介
三、具體過程
儘可能搞清楚問題的前因後果
有誰在？
之前發生了什麼？
現在在運行的進程是啥？
監聽的網絡服務
CPU和內存使用情況
查看硬件
I/O 性能
掛載點和文件系統
內核、中斷和網絡
系統日誌和內核消息
任務計劃
查看具體應用的系統日誌
四、總結
注，測試環境：操作系統 CentOS 6.4 x86_64。
一、前言
原文鏈接：http://devo.ps/blog/2013/03/06/troubleshooting-5minutes-on-a-yet-unknown-box.html。
第一版翻譯者：@老碼農的自留地
注，此文章在原文章的基礎上加入一些內容（修改與測試）。
二、簡介
Back when our team was dealing with operations, optimization and scalability at our previous company, we had our fair share of troubleshooting poorly performing applications and infrastructures of various sizes, often large (think CNN or the World Bank). Tight deadlines, “exotic” technical stacks and lack of information usually made for memorable experiences.
我們團隊爲上一家公司承擔運維、優化和擴展工作的時候，我們碰到了各種不同規模的性能很差的系統和基礎設備（大型系統居多，比如CNN或者世界銀行的系統）。要是再趕上修復時間緊、奇葩的技術平臺、缺少信息和文檔，基本上這過程都會慘痛到讓我們留下深刻的記憶。
三、具體過程
遇到服務器故障，問題出現的原因很少可以一下就能找到。我們基本上都會從以下步驟入手：
1.儘可能搞清楚問題的前因後果
不要一下子就扎到服務器前面，你需要先搞明白對這臺服務器有多少已知的情況，還有故障的具體情況。不然你很難搞清楚問題出在什麼地方，
必須搞清楚的問題有：
故障的表現是什麼？無響應？報錯？
故障是什麼時候發現的？
故障是否可重現？
有沒有出現的規律（比如每小時出現一次）
最後一次對整個平臺進行更新的內容是什麼（代碼、服務器等）？
故障影響的特定用戶羣是什麼樣的(已登錄的, 退出的, 某個地域的…)？
基礎架構（物理的、邏輯的）的文檔是否能找到?
是否有監控平臺可用？（比如Munin、Zabbix、 Nagios、 New Relic… 什麼都可以）
是否有日誌可以查看？ （比如Loggly、Airbrake、 Graylog…）
最後兩個是最方便的信息來源，不過別抱太大希望，基本上它們都不會有，只能再繼續摸索了。下面我們繼續……
2.有誰在？
[root@node1 ~]# w [root@node1 ~]# last
用這兩個命令看看都有誰在線，有哪些用戶訪問過。這不是什麼關鍵步驟，不過最好別在其他用戶正幹活的時候來調試系統。嘿嘿！
3.之前發生了什麼？
[root@node1 ~]# history
查看一下之前服務器上執行過的命令。看一下總是沒錯的，加上前面看的誰登錄過的信息，應該有點用。另外作爲admin要注意，不要利用自己的權限去侵犯別人的隱私哦。到這裏先提醒一下，等會你可能會需要更新 HISTTIMEFORMAT 環境變量來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令，同樣會令人抓狂的。命令如下，
[root@node1 ~]# export HISTTIMEFORMAT='%F %T '
這樣再次用history命令查看就會顯示命令執行的時間。
4.現在在運行的進程是啥？
[root@node1 ~]# pstree –a [root@node1 ~]# ps aux
這都是查看現有進程的。 ps aux 的結果比較雜亂， pstree -a 的結果比較簡單明瞭，可以看到正在運行的進程及相關用戶。其實這兩個工具一般好用，htop這個工具比較好用，前提是你的機器上已安裝好htop工具。有興趣的朋友可以去用一下，哈哈！
5.監聽的網絡服務
[root@node1 ~]# netstat -ntlp （查看tcp端口） [root@node1 ~]# netstat -nulp（查看udp端口） [root@node1 ~]# netstat -nxlp （查看unix）
我一般都分開運行這三個命令，不想一下子，列出一大堆所有的服務。netstat -nalp倒也可以。不過我絕不會用 numeric 選項 （鄙人一點淺薄的看法：IP 地址看起來更方便）。找到所有正在運行的服務，檢查它們是否應該運行。查看各個監聽端口，在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。如果服務器上有好幾個Java或者Erlang什麼的進程在同時運行，能夠按PID分別找到每個進程就很重要了。通常我們建議每臺服務器上運行的服務少一點，必要時可以增加服務器。如果你看到一臺服務器上有三四十個監聽端口開着，那還是做個記錄，回頭有空的時候清理一下，重新組織一下服務器。
6.CPU和內存使用情況
[root@node1 ~]# free -m [root@node1 ~]# uptime [root@node1 ~]# top [root@node1 ~]# htop
注意以下問題:
還有空餘的內存嗎？服務器是否正在內存和硬盤之間進行swap？
還有剩餘的CPU嗎？服務器是幾核的？是否有某些CPU核負載過多了？
服務器最大的負載來自什麼地方? 平均負載是多少？
7.查看硬件
[root@node1 ~]# dmidecode | more [root@node1 ~]# ethtool eth0
RAID卡、CPU、空餘的內存插槽。根據這些情況可以大致瞭解硬件問題的來源和性能改進的辦法。
網卡是否設置好? 是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?
8.I/O 性能
[root@node1 ~]# iostat -kx 2 [root@node1 ~]# vmstat 2 10 [root@node1 ~]# mpstat 2 10 [root@node1 ~]# dstat --top-io --top-bio
這些命令對於調試後端性能非常有用，
檢查磁盤使用量：服務器硬盤是否已滿？
是否開啓了swap交換模式 (si/so)？
CPU被誰佔用：系統進程？用戶進程？虛擬機？
dstat 是我的最愛，用它可以看到誰在進行 IO： 是不是MySQL吃掉了所有的系統資源？還是你的PHP進程？
9.掛載點和文件系統
[root@node1 ~]# mount [root@node1 ~]# cat /etc/fstab [root@node1 ~]# vgs [root@node1 ~]# pvs [root@node1 ~]# lvs [root@node1 ~]# df –h [root@node1 ~]# lsof +D /
通過上面的命令我們可以得到以下信息，
一共掛載了多少文件系統?
有沒有某個服務專用的文件系統? (比如MySQL?)
文件系統的掛載選項是什麼： noatime? default? 有沒有文件系統被重新掛載爲只讀模式了？
磁盤空間是否還有剩餘?
是否有大文件被刪除但沒有清空?
如果磁盤空間有問題，你是否還有空間來擴展一個分區？
10.內核、中斷和網絡
[root@node1 ~]# sysctl -a | grep * [root@node1 ~]# cat /proc/interrupts [root@node1 ~]# cat /proc/net/ip_conntrack [root@node1 ~]# netstat -an [root@node1 ~]# ss –s
你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因爲大量的網絡中斷請求或者RAID請求而過載了？
SWAP交換的設置是什麼？對於工作站來說swappinness 設爲 60 就很好, 不過對於服務器就太糟了：你最好永遠不要讓服務器做SWAP交換，不然對磁盤的讀寫會鎖死SWAP進程。
conntrack_max 是否設的足夠大，能應付你服務器的流量?
在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的？
如果要顯示所有存在的連接，netstat 會比較慢， 你可以先用 ss 看一下總體情況。
你還可以看一下Linux TCP tuning瞭解網絡性能調優的一些要點。
11.系統日誌和內核消息
[root@node1 ~]# dmesg [root@node1 ~]# less /var/log/messages [root@node1 ~]# less /var/log/secure [root@node1 ~]# less /var/log/auth
通過上面的命令我們會得到以下信息，
查看錯誤和警告消息，比如看看是不是很多關於連接數過多導致？
看看是否有硬件錯誤或文件系統錯誤？
分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。
12.任務計劃
[root@node1 ~]# for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
是否有某個定時任務運行過於頻繁？
是否有些用戶提交了隱藏的定時任務？
在出現故障的時候，是否正好有某個備份任務在執行？
13.查看具體應用的系統日誌
這裏邊可分析的東西就多了，不過恐怕你作爲運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+PHP）應用環境裏:
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後臺進程。
你甚至有可能找到真正的故障源頭。就算還沒有找到，搞清楚了上面這些情況之後，你現在也具備了深挖下去的條件。繼續努力吧！
最後，希望大家有所收穫吧^_^……