點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

在實際的性能分析中，一個很常見的現象是，明明發生了性能瓶頸，但當你登錄到服務器中想要排查的時候，卻發現瓶頸已經消失了?；蛘哒f，性能問題總是時不時地發生，但卻很難找出發生規律，也很難重現。

而要解決這個問題，就要搭建監控系統，把系統和應用程序的運行狀況監控起來，并定義一系列的策略，在發生問題時第一時間告警通知。一個好的監控系統，不僅可以實時暴露系統的各種問題，更可以根據這些監控到的狀態，自動分析和定位大致的瓶頸來源，從而更精確地把問題匯報給相關團隊處理。要做好監控，最核心的就是全面的、可量化的指標，這包括系統和應用兩個方面。

從系統來說，監控系統要涵蓋系統的整體資源使用情況，比如我們前面講過的 CPU、內存、磁盤和文件系統、網絡等各種系統資源。

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

二、系統監控

1、USE 法

在開始監控系統之前，你肯定最想知道，怎么才能用簡潔的方法，來描述系統資源的使用情況。你當然可以使用專欄中學到的各種性能工具，來分別收集各種資源的使用情況。不過不要忘記，每種資源的性能指標可都有很多，使用過多指標本身耗時耗力不說，也不容易為你建立起系統整體的運行狀況。

在這里，我為你介紹一種專門用于性能監控的 USE（Utilization Saturation and Errors）法。

USE 法把系統資源的性能指標，簡化成了三個類別，即使用率、飽和度以及錯誤數。

使用率，表示資源用于服務的時間或容量百分比。100% 的使用率，表示容量已經用盡或者全部時間都用于服務。

飽和度，表示資源的繁忙程度，通常與等待隊列的長度相關。100% 的飽和度，表示資源無法接受更多的請求。

錯誤數表示發生錯誤的事件個數。錯誤數越多，表明系統的問題越嚴重。

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

2、性能指標

那么，對于每一種系統資源，又有哪些常見的性能指標呢？回憶一下我們講過的各種系統資源原理，并不難想到相關的性能指標。這里，我把常見的性能指標畫了一張表格，方便你在需要時查看。

不過，需要注意的是，USE 方法只關注能體現系統資源性能瓶頸的核心指標，但這并不是說其他指標不重要。諸如系統日志、進程資源使用量、緩存使用量等其他各類指標，也都需要我們監控起來。只不過，它們通常用作輔助性能分析，而 USE 方法的指標，則直接表明了系統的資源瓶頸。

3、監控系統

掌握 USE 方法以及需要監控的性能指標后，接下來要做的，就是建立監控系統，把這些指標保存下來；然后，根據這些監控到的狀態，自動分析和定位大致的瓶頸來源；最后，再通過告警系統，把問題及時匯報給相關團隊處理。

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

不過，幸運的是，現在已經有很多開源的監控工具可以直接使用，比如最常見的 Zabbix、Nagios、Prometheus 等等。

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

（圖片來自 prometheus.io）

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

Pull 模式，由服務器端的采集模塊來觸發采集。只要采集目標提供了 HTTP 接口，就可以自由接入（這也是最常用的采集模式）。

Push 模式，則是由各個采集目標主動向 Push Gateway（用于防止數據丟失）推送指標，再由服務器端從 Gateway 中拉取過去（這是移動應用中最常用的采集模式）。

第二個是數據存儲模塊。為了保持監控數據的持久化，圖中的 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 法建立性能指標后，我們還需要通過一套完整的監控系統，把這些指標從采集、存儲、查詢、處理，再到告警和可視化展示等貫穿起來。這樣，不僅可以將系統資源的瓶頸快速暴露出來，還可以借助監控的歷史數據，來追蹤定位性能問題的根源。

三、應用監控

1、應用監控指標

跟系統監控一樣，在構建應用程序的監控系統之前，首先也需要確定，到底需要監控哪些指標。特別是要清楚，有哪些指標可以用來快速確認應用程序的性能問題。

應用程序的核心指標，不再是資源的使用情況，而是請求數、錯誤率和響應時間。

這些指標不僅直接關系到用戶的使用體驗，還反映應用整體的可用性和可靠性。有了請求數、錯誤率和響應時間這三個黃金指標之后，我們就可以快速知道，應用是否發生了性能問題。但是，只有這些指標顯然還是不夠的，因為發生性能問題后，我們還希望能夠快速定位“性能瓶頸區”。所以，在我看來，下面幾種指標，也是監控應用程序時必不可少的。

第一個，是應用進程的資源使用情況，比如進程占用的 CPU、內存、磁盤 I/O、網絡等。使用過多的系統資源，導致應用程序響應緩慢或者錯誤數升高，是一個最常見的性能問題。

第二個，是應用程序之間調用情況，比如調用頻率、錯誤數、延時等。由于應用程序并不是孤立的，如果其依賴的其他應用出現了性能問題，應用自身性能也會受到影響。

第三個，是應用程序內部核心邏輯的運行情況，比如關鍵環節的耗時以及執行過程中的錯誤等。由于這是應用程序內部的狀態，從外部通常無法直接獲取到詳細的性能數據。所以，應用程序在設計和開發時，就應該把這些指標提供出來，以便監控系統可以了解其內部運行狀態。

有了應用進程的資源使用指標，你就可以把系統資源的瓶頸跟應用程序關聯起來，從而迅速定位因系統資源不足而導致的性能問題；

有了應用程序之間的調用指標，你可以迅速分析出一個請求處理的調用鏈中，到底哪個組件才是導致性能問題的罪魁禍首；

而有了應用程序內部核心邏輯的運行性能，你就可以更進一步，直接進入應用程序的內部，定位到底是哪個處理環節的函數導致了性能問題。

基于這些思路，我相信你就可以構建出，描述應用程序運行狀態的性能指標。再將這些指標納入我們上一期提到的監控系統（比如 Prometheus + Grafana）中，就可以跟系統監控一樣，一方面通過告警系統，把問題及時匯報給相關團隊處理；另一方面，通過直觀的圖形界面，動態展示應用程序的整體性能。

2、全鏈路監控

業務系統通常會涉及到一連串的多個服務，形成一個復雜的分布式調用鏈。為了迅速定位這類跨應用的性能瓶頸，你還可以使用 Zipkin、Jaeger、Pinpoint 等各類開源工具，來構建全鏈路跟蹤系統。比如，下圖就是一個 Jaeger 調用鏈跟蹤的示例。

（圖片來自 Jaeger 文檔）

全鏈路跟蹤可以幫你迅速定位出，在一個請求處理過程中，哪個環節才是問題根源。比如，從上圖中，你就可以很容易看到，這是 Redis 超時導致的問題。

全鏈路跟蹤除了可以幫你快速定位跨應用的性能問題外，還可以幫你生成線上系統的調用拓撲圖。這些直觀的拓撲圖，在分析復雜系統（比如微服務）時尤其有效。

3、日志監控

性能指標的監控，可以讓你迅速定位發生瓶頸的位置，不過只有指標的話往往還不夠。比如，同樣的一個接口，當請求傳入的參數不同時，就可能會導致完全不同的性能問題。所以，除了指標外，我們還需要對這些指標的上下文信息進行監控，而日志正是這些上下文的最佳來源。

對比來看，指標是特定時間段的數值型測量數據，通常以時間序列的方式處理，適合于實時監控。

而日志則完全不同，日志都是某個時間點的字符串消息，通常需要對搜索引擎進行索引后，才能進行查詢和匯總分析。

對日志監控來說，最經典的方法，就是使用 ELK 技術棧，即使用 Elasticsearch、Logstash 和 Kibana 這三個組件的組合。

如下圖所示，就是一個經典的 ELK 架構圖：

（圖片來自elastic.co）

Logstash 負責對從各個日志源采集日志，然后進行預處理，最后再把初步處理過的日志，發送給 Elasticsearch 進行索引。

Elasticsearch 負責對日志進行索引，并提供了一個完整的全文搜索引擎，這樣就可以方便你從日志中檢索需要的數據。

Kibana 則負責對日志進行可視化分析，包括日志搜索、處理以及絢麗的儀表板展示等。

下面這張圖，就是一個 Kibana 儀表板的示例，它直觀展示了 Apache 的訪問概況。

（圖片來自elastic.co）

值得注意的是，ELK 技術棧中的 Logstash 資源消耗比較大。所以，在資源緊張的環境中，我們往往使用資源消耗更低的 Fluentd，來替代 Logstash（也就是所謂的 EFK 技術棧）。

4、最后總結

應用程序的監控，可以分為指標監控和日志監控兩大部分：

指標監控主要是對一定時間段內性能指標進行測量，然后再通過時間序列的方式，進行處理、存儲和告警。

日志監控則可以提供更詳細的上下文信息，通常通過 ELK 技術棧來進行收集、索引和圖形化展示。

在跨多個不同應用的復雜業務場景中，你還可以構建全鏈路跟蹤系統。這樣可以動態跟蹤調用鏈中各個組件的性能，生成整個流程的調用拓撲圖，從而加快定位復雜應用的性能問題。

作者丨-零

來源丨網址：

www.cnblogs.com/-wenli/p/14017850.html

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談談你的看法？

• 喜馬拉雅自研網關架構演進過程

• 收藏：存儲知識全面總結

• 微博千萬級規模高性能高并發的網絡架構設計

總結

以上是生活随笔為你收集整理的系统、应用监控的缜密思路，堪称性能瓶颈的克星的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。