標籤：
儘可能搞清楚問題的前因後果不要一下子就紮到伺服器前面，你需要先搞明白這台伺服器有多少已知的情況，還有故障的具體情況，不然你很有可能是在無的放矢 必須要搞清楚的問題：
- 故障的表現是什嗎？無響應？報錯？
- 故障是什麼時候發現的？
- 故障是否可以重現？
- 有沒有出現的規律（比如每小時一次）
- 最後一次對整個平台進行更新的內容是什麼（代碼、伺服器）？
- 故障影響的特定使用者群是什麼樣的（已登入的、退出的、某個地區的...）?
- 基礎架構（物理的、邏輯的）的文檔是否能找到？
- 是否有監控平台可用？
- 是否有日誌可以查看？
最後兩個是最方便的資訊來源，不過別抱太大希望，基本上它們都不會有，只能再繼續摸索 有誰在？
- $ w
- $ last
用這兩個命令查看都有誰線上，有哪些使用者訪問過。這不是什麼關鍵步驟，不過最好別在其他使用者正在幹活的時候來調試系統。有道是一山不容二虎嘛 之前發生了什嗎？
- $ history
查看一下之前伺服器上執行過的命令。看一下總是沒錯的，加上前面看的誰登入過的資訊，應該有點用。另外，作為admin要注意，不用利用自己的許可權去侵犯別人的隱私！ 到這裡先提醒一下，查看history的時候需要更新一下HISTTIMEFORMAT環境變數來顯示這些命令執行的時間。（ps：個人補充） 配置HISTTIMEFORMAT可使用如下命令：
- $ export HISTTIMEFORMAT="%F %T "
現在啟動並執行進程
- $ pstree -a
- $ps aux
這都是查看現有進程的。ps aux的結果比較雜亂（ps：個人不認同，ps aux可以用過管道+grep進行過濾，pstree可沒有這功能），pstree -a的結果比較簡單明了，可以看到正在啟動並執行進程以及相關使用者 監聽的網路服務
- $ netstat -ntlp
- $ netstat -nulp
- $ netstat -nxlp
我一般都分開運行這三個命令，不想一下子看到列出一大堆所有的服務。netstat -nalp倒也可以。 找到所有正在啟動並執行服務，檢查它們是否應該運行。查看各個監聽連接埠。 通常我們建議每台伺服器上啟動並執行服務少一點，必要時可以增加伺服器。如果你看到一台伺服器上有三四個監聽連接埠開著，那還是做個記錄，回頭有空的時候清理一下，重新組織一下伺服器 CPU和記憶體
- $ free -m
- $ uptime
- $ top
注意以下問題：
- 還有閒置記憶體嗎？伺服器是否正在記憶體和硬碟之間進行swap？
- 還有剩餘的CPU嗎？伺服器是幾核的？是否某些CPU核負載過多了？
- 伺服器最大的負載來自什麼地方？平均負載是多少？
硬體
- $ lspci
- $ dmidecode
- $ ethtool
我覺得主要是使用ethtool查看網卡是否設定好？是否正運行在半雙工狀態？速度是10MBps？有沒有TX/RX報錯？ IO效能
- dstat --top-io --top-bio
我這裡唯寫了一個我會用而且感覺最好用的dstat。用它可以看道誰進行中IO：是不是MYSQL吃掉了所有的系統資源？還是你的PHP進程？ 系統日誌和核心訊息
- $ dmesg
- $ less /var/log/auth.log
- 查看錯誤和警告資訊，比如看看是不是串連數過多導致？
- 看看是否有硬體錯誤或檔案系統錯誤？
- 分析是否能將這些錯誤時間和前面發現的疑點進行時間上的對比
定時任務
- $ ls /etc/cron* | cat
- $ for user in $(cat /etc/passwd | awk -F ":" ‘{print $1}‘); do crontab -l -u $user; done
(ps:這裡我改寫了部分linux命令使用，哈哈，雖然是轉載，但是也要有我自己的風格在裡面)
- 是否某個定時任務運行過於頻繁？
- 是否有些使用者提交了隱藏的定時任務？
- 在出現故障的時候，是否正好有某個備份額任務正在執行？
應用系統日誌這裡分析的東西可就多了，不過恐怕你作為營運人員是沒功夫仔細研究它的。關注那麼明顯的問題，比如在一個典型的LAMP應用環境裡：
- Apache&Nginx;查詢訪問和錯誤記錄檔，直接找5××錯誤，再看是否有limit_zone錯誤
- Mysql;在mysql.log找錯誤資訊，看看有沒有結構損壞的表，是否有innodb修複進程正在運行，是否有disk/index/query問題
- PHP-FPM：如果設定了php-slow日誌，直接找錯誤資訊
結論經過這5分鐘之後，你應該對如下情況比較清楚了：
- 在伺服器上啟動並執行都是些啥？
- 這個故障看起來是和IO/硬體/網路或者系統配置相關
- 這個故障是否有你熟悉的一些特徵？比如資料庫索引使用不當，或者太多的apache後台進程
Linux 排除問題的前5分鐘
