Linux性能優化實戰學習筆記：第五十三講

1、上節回顧

在前面的內容中，我爲你介紹了不少性能分析的原理、思路以及相關的工具。不過，在實際的性能分析中，一個很常見的現象是，明明發生了性能瓶頸，但當你登陸到服務器中想要排查的時
候，卻發現瓶頸已經消失了。或者說，性能問題老是時不時地發生，但卻很難找出發生規律，也很難重現。

當面對這樣的場景時，你可能會發現，咱們前面介紹的各類工具、方法都「失效「了。爲何呢？由於它們都須要在性能問題發生的時刻纔有效，而在這些過後分析的場景中，咱們就很難發
揮它們的威力了。

那該怎麼辦呢？置之不理嗎？其實以往，不少應用都是等到用戶抱怨響應慢了，或者系統崩潰了後，才發現系統或者應用程序的性能出現了問題。雖然最終也能發現問題，但顯然，這種方法是
不可取的，由於嚴重影響了用戶的體驗。

而要解決這個問題，就要搭建監控系統，把系統和應用程序的運行情況監控起來，並定義一系列的策略，在發生問題時第一時間告警通知。一個好的監控系統，不只能夠實時暴露系統的各類問
題，更能夠根據這些監控到的狀態，自動分析和定位大體的瓶頸來源，從而更精確地把問題彙報給相關團隊處理。

要作好監控，最核心的就是全面的、可量化的指標，這包括系統和應用兩個方面。

從系統來講，監控系統要涵蓋系統的總體資源使用狀況，好比咱們前面講過的 CPU、內存、磁盤和文件系統、網絡等各類系統資源。

而從應用程序來講，監控系統要涵蓋應用程序內部的運行狀態，這既包括進程的 CPU、磁盤 I/O等總體運行情況，更須要包括諸如接口調用耗時、執行過程當中的錯誤、內部對象的內存使用等應
用程序內部的運行情況。

今天，我就帶你一塊兒來看看，如何對 Linux 系統進行監控。而在下一節，我將繼續爲你講解應用程序監控的思路。

2、USE 法

在開始監控系統以前，你確定最想知道，怎麼才能用簡潔的方法，來描述系統資源的使用狀況。你固然可使用專欄中學到的各類性能工具，來分別收集各類資源的使用狀況。不過不要忘記，
每種資源的性能指標可都有不少，使用過多指標自己耗時耗力不說，也不容易爲你創建起系統總體的運行情況。

在這裏，我爲你介紹一種專門用於性能監控的 USE（Utilization Saturation and Errors）法。USE 法把系統資源的性能指標，簡化成了三個類別，即便用率、飽和度以及錯誤數。

1. 使用率，表示資源用於服務的時間或容量百分比。100% 的使用率，表示容量已經用盡或者所有時間都用於服務。
2. 飽和度，表示資源的繁忙程度，一般與等待隊列的長度相關。100% 的飽和度，表示資源沒法接受更多的請求。
3. 錯誤數表示發生錯誤的事件個數。錯誤數越多，代表系統的問題越嚴重。

這三個類別的指標，涵蓋了系統資源的常見性能瓶頸，因此常被用來快速定位系統資源的性能瓶頸。這樣，不管是對 CPU、內存、磁盤和文件系統、網絡等硬件資源，仍是對文件描述符數、連
接數、鏈接跟蹤數等軟件資源，USE 方法均可以幫你快速定位出，是哪種系統資源出現了性能瓶頸。

那麼，對於每一種系統資源，又有哪些常見的性能指標呢？回憶一下咱們講過的各類系統資源原理，並不難想到相關的性能指標。這裏，我把常見的性能指標畫了一張表格，

方便你在須要時查看。

不過，須要注意的是，USE 方法只關注能體現系統資源性能瓶頸的核心指標，但這並非說其餘指標不重要。諸如系統日誌、進程資源使用量、緩存使用量等其餘各種指標，也都須要咱們監控
起來。只不過，它們一般用做輔助性能分析，而 USE 方法的指標，則直接代表了系統的資源瓶頸。

3、監控系統

掌握 USE 方法以及須要監控的性能指標後，接下來要作的，就是創建監控系統，把這些指標保存下來；而後，根據這些監控到的狀態，自動分析和定位大體的瓶頸來源；最後，再經過告警系
統，把問題及時彙報給相關團隊處理。

能夠看出，一個完整的監控系統一般由數據採集、數據存儲、數據查詢和處理、告警以及可視化展現等多個模塊組成。因此，要從頭搭建一個監控系統，其實也是一個很大的系統工程

不過，幸運的是，如今已經有不少開源的監控工具能夠直接使用，好比最多見的 Zabbix、Nagios、Prometheus 等等。

下面，我就以 Prometheus 爲例，爲你介紹這幾個組件的基本原理。以下圖所示，就是Prometheus 的基本架構：

先看數據採集模塊。最左邊的 Prometheus targets 就是數據採集的對象，而 Retrieval 則負責採集這些數據。從圖中你也能夠看到，Prometheus 同時支持 Push 和 Pull 兩種數據採集模式。

1. Pull 模式，由服務器端的採集模塊來觸發採集。只要採集目標提供了 HTTP 接口，就能夠自由接入（這也是最經常使用的採集模式）。
2. Push 模式，則是由各個採集目標主動向 Push Gateway（用於防止數據丟失）推送指標，再由服務器端從 Gateway 中拉取過去（這是移動應用中最經常使用的採集模式）。

因爲須要監控的對象一般都是動態變化的，Prometheus 還提供了服務發現的機制，能夠自動根據預配置的規則，動態發現須要監控的對象。這在 Kubernetes 等容器平臺中很是有效。

第二個是數據存儲模塊。爲了保持監控數據的持久化，圖中的 TSDB（Time series database）模塊，負責將採集到的數據持久化到 SSD 等磁盤設備中。TSDB 是專門爲時間序列數據設計的一
種數據庫，特色是以時間爲索引、數據量大而且以追加的方式寫入。

第三個是數據查詢和處理模塊。剛纔提到的 TSDB，在存儲數據的同時，其實還提供了數據查詢和基本的數據處理功能，而這也就是 PromQL 語言。PromQL 提供了簡潔的查詢、過濾功能，
而且支持基本的數據處理方法，是告警系統和可視化展現的基礎。

第四個是告警模塊。右上角的 AlertManager 提供了告警的功能，包括基於 PromQL 語言的觸發條件、告警規則的配置管理以及告警的發送等。不過，雖然告警是必要的，但過於頻繁的告警
顯然也不可取。因此，AlertManager 還支持經過分組、抑制或者靜默等多種方式來聚合同類告警，並減小告警數量。

最後一個是可視化展現模塊。Prometheus 的 web UI 提供了簡單的可視化界面，用於執行PromQL 查詢語句，但結果的展現比較單調。不過，一旦配合 Grafana，就能夠構建很是強大的
圖形界面了。

介紹完了這些組件，想必你對每一個模塊都有了比較清晰的認識。接下來，咱們再來繼續深刻了解這些組件結合起來的總體功能。

好比，以剛纔提到的 USE 方法爲例，我使用 Prometheus，能夠收集 Linux 服務器的 CPU、內存、磁盤、網絡等各種資源的使用率、飽和度和錯誤數指標。而後，經過 Grafana 以及
PromQL 查詢語句，就能夠把它們以圖形界面的方式直觀展現出來。

 

 

4、小結

今天，我帶你一塊兒梳理了系統監控的基本思路。

系統監控的核心是資源的使用狀況，包括 CPU、內存、磁盤和文件系統、網絡等硬件資源，以及文件描述符數、鏈接數、鏈接跟蹤數等軟件資源。而這些資源，均可以經過 USE 法來創建核心性
能指標。

USE 法把系統資源的性能指標，簡化成了三個類別，即便用率、飽和度以及錯誤數。 這三者任一類別太高時，都表明相對應的系統資源有可能存在性能瓶頸。

基於 USE 法創建性能指標後，還須要經過一套完整的監控系統，把這些指標從採集、存儲、查詢、處理，再到告警和可視化展現等串聯起來。你能夠基於 Zabbix、Prometheus 等各類開源
的監控產品，構建這套監控系統。這樣，不只能夠將系統資源的瓶頸快速暴露出來，還能夠藉助監控的歷史，過後追查定位問題。

固然，除了系統監控以外，應用程序的監控也是必不可少的，我將在下一節課繼續爲你拆解。