系統管理員入門：排除故障

我一般會嚴格保持此博客的技術性，將觀察、意見等內容保持在最低限度。可是，這篇和接下來的幾篇文章將介紹剛進入系統管理/SRE/系統工程師/sysops/devops-ops（不管你想稱本身是什麼）角色的常見的基礎知識。

請跟我來！

「個人網站很慢！」

我只是隨機選擇了本文的問題類型，這也能夠應用於任何與系統管理員相關的故障排除。我並非要炫耀那些能夠發現最多的信息的最聰明的「金句」。它也不是一個詳盡的、一步步指導的、並在最後一個方框中導向「利潤」一詞的「流程圖」。

我會經過一些例子展現常規的方法。

示例場景僅用於說明本文目的。它們有時會作一些不適用於全部狀況的假設，並且確定會有不少讀者在某些時候說「哦，但我以爲你會發現……」。

但那可能會讓咱們錯失重點。

十多年來，我一直在從事於支持工做，或在支持機構工做，有一件事讓我一次又一次地感到震驚，這促使我寫下了這篇文章。

有許多技術人員在遇到問題時的本能反應，就是無論三七二十一去嘗試可能的解決方案。

「個人網站很慢，因此」，

• 我將嘗試增大 MaxClients/MaxRequestWorkers/worker_connections
• 我將嘗試提高 innodb_buffer_pool_size/effective_cache_size
• 我打算嘗試啓用 mod_gzip（遺憾的是，這是真實的故事）

「我曾經看過這個問題，它是由於某種緣由形成的 —— 因此我估計仍是這個緣由，它應該能解決這個問題。」

這浪費了不少時間，並會讓你在黑暗中盲目亂撞，胡亂鼓搗。

你的 InnoDB 的緩衝池也許達到 100％ 的利用率，但這可能只是由於有人運行了一段時間的一次性大型報告致使的。若是沒有排除這種狀況，那你就是在浪費時間。

開始以前

在這裏，我應該說明一下，雖然這些建議一樣適用於許多角色，但我是從通常的支持系統管理員的角度來撰寫的。在一個成熟的內部組織中，或與規模較大的、規範管理的或「企業級」客戶合做時，你一般會對一切都進行檢測、測量、繪製、整理（甚至不是文字），併發出警報。那麼你的方法也每每會有所不一樣。讓咱們在這裏先忽略這種狀況。

若是你沒有這種東西，那就隨意了。

澄清問題

首先肯定其實是什麼問題。「慢」能夠是多種形式的。是收到第一個字節的時間嗎？從糟糕的 Javascript 加載和每頁加載要拉取 15 MB 的靜態內容，這是一個徹底不一樣類型的問題。是慢，仍是比一般慢？這是兩個很是不一樣的解決方案！

在你着手作某事以前，確保你知道實際報告和遇到的問題。找到問題的根源一般很困難，但即使找不到也必須找到問題自己。

不然，這至關於系統管理員帶着一把刀去參加槍戰。

唾手可得

首次登陸可疑服務器時，你能夠查找一些常見的嫌疑對象。事實上，你應該這樣作！每當我登陸到服務器時，我都會發出一些命令來快速檢查一些事情：咱們是否發生了頁交換（free / vmstat），磁盤是否繁忙（top / iostat / iotop），是否有丟包（netstat / proc / net / dev），是否處於鏈接數過多的狀態（netstat），有什麼東西佔用了 CPU（top），誰在這個服務器上（w / who），syslog 和 dmesg 中是否有引人注目的消息？

若是你從 RAID 控制器獲得 2000 條抱怨直寫式緩存沒有生效的消息，那麼繼續進行是沒有意義的。

這用不了半分鐘。若是什麼都沒有引發你的注意 —— 那麼繼續。

重現問題

若是某處確實存在問題，而且找不到唾手可得的信息。

那麼採起全部步驟來嘗試重現問題。當你能夠重現該問題時，你就能夠觀察它。**當你能觀察到時，你就能夠解決。**若是在第一步中還沒有顯現出或覆蓋了問題所在，詢問報告問題的人須要採起哪些確切步驟來重現問題。

對於由太陽耀斑或只能運行在 OS/2 上的客戶端引發的問題，重現並不老是可行的。但你的第一個停靠港應該是至少嘗試一下！在一開始，你所知道的是「某人認爲他們的網站很慢」。對於那些人，他們可能還在用他們的 GPRS 手機，也可能正在安裝 Windows 更新。你在這裏挖掘得再深也是浪費時間。

嘗試重現！

檢查日誌

我對於有必要包括這一點感到很難過。可是我曾經看到有人在運行 tail /var/log/... 以後幾分鐘就不看了。大多數 *NIX 工具都特別喜歡記錄日誌。任何明顯的錯誤都會在大多數應用程序日誌中顯得很是突出。檢查一下。

縮小範圍

若是沒有明顯的問題，但你能夠重現所報告的問題，那也很棒。因此，你如今知道網站是慢的。如今你已經把範圍縮小到：瀏覽器的渲染/錯誤、應用程序代碼、DNS 基礎設施、路由器、防火牆、網卡（全部的）、以太網電纜、負載均衡器、數據庫、緩存層、會話存儲、Web 服務器軟件、應用程序服務器、內存、CPU、RAID 卡、磁盤等等。

根據設置添加一些其餘可能的罪魁禍首。它們也多是 SAN，也不要忘記硬件 WAF！以及…… 你明白個人意思。

若是問題是接收到第一個字節的時間，你固然會開始對 Web 服務器去應用上已知的修復程序，就是它響應緩慢，你也以爲幾乎就是它，對吧？可是你錯了！

你要回去嘗試重現這個問題。只是這一次，你要試圖消除儘量多的潛在問題來源。

你能夠很是輕鬆地消除絕大多數可能的罪魁禍首：你能從服務器本地重現問題嗎？恭喜，你剛剛節省了本身必須嘗試修復 BGP 路由的時間。

若是不能，請嘗試使用同一網絡上的其餘計算機。若是能夠的話，至少你能夠將防火牆移到你的嫌疑人名單上，（可是要注意一下那個交換機！）

是全部的鏈接都很慢嗎？雖然服務器是 Web 服務器，但並不意味着你不該該嘗試使用其餘類型的服務進行重現問題。netcat 在這些場景中很是有用（可是你的 SSH 鏈接可能會一直有延遲，這能夠做爲線索）！ 若是這也很慢，你至少知道你極可能遇到了網絡問題，能夠忽略掉整個 Web 軟件及其全部組件的問題。用這個知識（我不收 200 美圓）再次從頂部開始，按你的方式由內到外地進行！

即便你能夠在本地復現 —— 仍然有不少「因素」留下。讓咱們排除一些變量。你能用普通文件重現它嗎？ 若是 i_am_a_1kb_file.html 很慢，你就知道它不是數據庫、緩存層或 OS 之外的任何東西和 Web 服務器自己的問題。

你能用一個須要解釋或執行的 hello_world.(py|php|js|rb..) 文件重現問題嗎？若是能夠的話，你已經大大縮小了範圍，你能夠專一於少數事情。若是 hello_world 能夠立刻工做，你仍然學到了不少東西！你知道了沒有任何明顯的資源限制、任何滿的隊列或在任何地方卡住的 IPC 調用，因此這是應用程序正在作的事情或它正在與之通訊的事情。

全部頁面都慢嗎？或者只是從第三方加載「實時分數數據」的頁面慢？

這能夠歸結爲：你仍然能夠重現這個問題所涉及的最少許的「因素」是什麼？

咱們的示例是一個緩慢的網站，但這一樣適用於幾乎全部問題。郵件投遞？你能在本地投遞嗎？能發給本身嗎？能發給<常見的服務提供者>嗎？使用小的、純文本的消息進行測試。嘗試直到遇到 2MB 擁堵時。使用 STARTTLS 和不使用 STARTTLS 呢？按你的方式由內到外地進行！

這些步驟中的每一步都只須要幾秒鐘，遠遠快於實施大多數「可能的」修復方案。

隔離觀察

到目前爲止，當你去除特定組件時沒法重現問題時，你可能已經偶然發現了問題所在。

但若是你尚未，或者你仍然不知道爲何：一旦你找到了一種方法來重現問題，你和問題之間的「東西」（某個技術術語）最少，那麼就該開始隔離和觀察了。

請記住，許多服務能夠在前臺運行和/或啓用調試。對於某些類別的問題，執行此操做一般很是有幫助。

這也是你的傳統武器庫發揮做用的地方。strace、lsof、netstat、GDB、iotop、valgrind、語言分析器（cProfile、xdebug、ruby-prof ……）那些類型的工具。

一旦你走到這一步，你就不多能擺脫剖析器或調試器了。

strace 一般是一個很是好的起點。

你可能會注意到應用程序停留在某個鏈接到端口 3306 的套接字文件描述符上的特定 read() 調用上。你會知道該怎麼作。

轉到 MySQL 並再次從頂部開始。顯而易見：「等待某某鎖」、死鎖、max_connections ……進而：是全部查詢？仍是隻寫請求？只有某些表？仍是隻有某些存儲引擎？等等……

你可能會注意到調用外部 API 資源的 connect() 須要五秒鐘才能完成，甚至超時。你會知道該怎麼作。

你可能會注意到，在同一對文件中有 1000 個調用 fstat() 和 open() 做爲循環依賴的一部分。你會知道該怎麼作。

它可能不是那些特別的東西，但我保證，你會發現一些東西。

若是你只是從這一部分學到一點，那也不錯；學習使用 strace 吧！真的學習它，閱讀整個手冊頁。甚至不要跳過歷史部分。man 每一個你還不知道它作了什麼的系統調用。98％ 的故障排除會話以 strace 而終結。

---

via: northernmost.org/blog/troubl…

做者：Erik Ljungstrom 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出