一、起始

在實際的性能分析中，一個很常見的現(xiàn)象是，明明發(fā)生了性能瓶頸，但當(dāng)你登錄到服務(wù)器中想要排查的時候，卻發(fā)現(xiàn)瓶頸已經(jīng)消失了。或者說，性能問題總是時不時地發(fā)生，但卻很難找出發(fā)生規(guī)律，也很難重現(xiàn)。 而要解決這個問題，就要搭建監(jiān)控系統(tǒng)，把系統(tǒng)和應(yīng)用程序的運(yùn)行狀況監(jiān)控起來，并定義一系列的策略，在發(fā)生問題時第一時間告警通知。一個好的監(jiān)控系統(tǒng)，不僅可以實時暴露系統(tǒng)的各種問題，更可以根據(jù)這些監(jiān)控到的狀態(tài)，自動分析和定位大致的瓶頸來源，從而更精確地把問題匯報給相關(guān)團(tuán)隊處理。要做好監(jiān)控，最核心的就是全面的、可量化的指標(biāo)，這包括系統(tǒng)和應(yīng)用兩個方面。 從系統(tǒng)來說，監(jiān)控系統(tǒng)要涵蓋系統(tǒng)的整體資源使用情況，比如我們前面講過的 CPU、內(nèi)存、磁盤和文件系統(tǒng)、網(wǎng)絡(luò)等各種系統(tǒng)資源。 而從應(yīng)用程序來說，監(jiān)控系統(tǒng)要涵蓋應(yīng)用程序內(nèi)部的運(yùn)行狀態(tài)，這既包括進(jìn)程的 CPU、磁盤 I/O 等整體運(yùn)行狀況，更需要包括諸如接口調(diào)用耗時、執(zhí)行過程中的錯誤、內(nèi)部對象的內(nèi)存使用等應(yīng)用程序內(nèi)部的運(yùn)行狀況。

二、系統(tǒng)監(jiān)控

1、USE 法

在開始監(jiān)控系統(tǒng)之前，你肯定最想知道，怎么才能用簡潔的方法，來描述系統(tǒng)資源的使用情況。你當(dāng)然可以使用專欄中學(xué)到的各種性能工具，來分別收集各種資源的使用情況。不過不要忘記，每種資源的性能指標(biāo)可都有很多，使用過多指標(biāo)本身耗時耗力不說，也不容易為你建立起系統(tǒng)整體的運(yùn)行狀況。 在這里，我為你介紹一種專門用于性能監(jiān)控的 USE（Utilization Saturation and Errors）法。 USE 法把系統(tǒng)資源的性能指標(biāo)，簡化成了三個類別，即使用率、飽和度以及錯誤數(shù)。

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

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

錯誤數(shù)表示發(fā)生錯誤的事件個數(shù)。錯誤數(shù)越多，表明系統(tǒng)的問題越嚴(yán)重。

這三個類別的指標(biāo)，涵蓋了系統(tǒng)資源的常見性能瓶頸，所以常被用來快速定位系統(tǒng)資源的性能瓶頸。這樣，無論是對 CPU、內(nèi)存、磁盤和文件系統(tǒng)、網(wǎng)絡(luò)等硬件資源，還是對文件描述符數(shù)、連接數(shù)、連接跟蹤數(shù)等軟件資源，USE 方法都可以幫你快速定位出，是哪一種系統(tǒng)資源出現(xiàn)了性能瓶頸。

2、性能指標(biāo)

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

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

3、監(jiān)控系統(tǒng)

掌握 USE 方法以及需要監(jiān)控的性能指標(biāo)后，接下來要做的，就是建立監(jiān)控系統(tǒng)，把這些指標(biāo)保存下來；然后，根據(jù)這些監(jiān)控到的狀態(tài)，自動分析和定位大致的瓶頸來源；最后，再通過告警系統(tǒng)，把問題及時匯報給相關(guān)團(tuán)隊處理。 可以看出，一個完整的監(jiān)控系統(tǒng)通常由數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)查詢和處理、告警以及可視化展示等多個模塊組成。所以，要從頭搭建一個監(jiān)控系統(tǒng)，其實也是一個很大的系統(tǒng)工程。 不過，幸運(yùn)的是，現(xiàn)在已經(jīng)有很多開源的監(jiān)控工具可以直接使用，比如最常見的 Zabbix、Nagios、Prometheus 等等。 下面，我就以 Prometheus 為例，為你介紹這幾個組件的基本原理。如下圖所示，就是 Prometheus 的基本架構(gòu)：

先看數(shù)據(jù)采集模塊。最左邊的 Prometheus targets 就是數(shù)據(jù)采集的對象，而 Retrieval 則負(fù)責(zé)采集這些數(shù)據(jù)。從圖中你也可以看到，Prometheus 同時支持 Push 和 Pull 兩種數(shù)據(jù)采集模式。 Pull 模式，由服務(wù)器端的采集模塊來觸發(fā)采集。只要采集目標(biāo)提供了 HTTP 接口，就可以自由接入（這也是最常用的采集模式）。 Push 模式，則是由各個采集目標(biāo)主動向 Push Gateway（用于防止數(shù)據(jù)丟失）推送指標(biāo)，再由服務(wù)器端從 Gateway 中拉取過去（這是移動應(yīng)用中最常用的采集模式）。 第二個是數(shù)據(jù)存儲模塊。為了保持監(jiān)控數(shù)據(jù)的持久化，圖中的 TSDB（Time series database）模塊，負(fù)責(zé)將采集到的數(shù)據(jù)持久化到 SSD 等磁盤設(shè)備中。TSDB 是專門為時間序列數(shù)據(jù)設(shè)計的一種數(shù)據(jù)庫，特點(diǎn)是以時間為索引、數(shù)據(jù)量大并且以追加的方式寫入。 第三個是數(shù)據(jù)查詢和處理模塊。剛才提到的 TSDB，在存儲數(shù)據(jù)的同時，其實還提供了數(shù)據(jù)查詢和基本的數(shù)據(jù)處理功能，而這也就是 PromQL 語言。PromQL 提供了簡潔的查詢、過濾功能，并且支持基本的數(shù)據(jù)處理方法，是告警系統(tǒng)和可視化展示的基礎(chǔ)。 第四個是告警模塊。右上角的 AlertManager 提供了告警的功能，包括基于 PromQL 語言的觸發(fā)條件、告警規(guī)則的配置管理以及告警的發(fā)送等。不過，雖然告警是必要的，但過于頻繁的告警顯然也不可取。所以，AlertManager 還支持通過分組、抑制或者靜默等多種方式來聚合同類告警，并減少告警數(shù)量。 最后一個是可視化展示模塊。Prometheus 的 web UI 提供了簡單的可視化界面，用于執(zhí)行 PromQL 查詢語句，但結(jié)果的展示比較單調(diào)。不過，一旦配合 Grafana，就可以構(gòu)建非常強(qiáng)大的圖形界面了。介紹完了這些組件，想必你對每個模塊都有了比較清晰的認(rèn)識。接下來，我們再來繼續(xù)深入了解這些組件結(jié)合起來的整體功能。比如，以剛才提到的 USE 方法為例，我使用 Prometheus，可以收集 Linux 服務(wù)器的 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等各類資源的使用率、飽和度和錯誤數(shù)指標(biāo)。然后，通過 Grafana 以及 PromQL 查詢語句，就可以把它們以圖形界面的方式直觀展示出來。

4、最后總結(jié)

系統(tǒng)監(jiān)控的核心是資源的使用情況，這既包括 CPU、內(nèi)存、磁盤、文件系統(tǒng)、網(wǎng)絡(luò)等硬件資源，也包括文件描述符數(shù)、連接數(shù)、連接跟蹤數(shù)等軟件資源。而要描述這些資源瓶頸，最簡單有效的方法就是 USE 法。 USE 法把系統(tǒng)資源的性能指標(biāo)，簡化為了三個類別：使用率、飽和度以及錯誤數(shù)。當(dāng)這三者之中任一類別的指標(biāo)過高時，都代表相對應(yīng)的系統(tǒng)資源可能存在性能瓶頸。 基于 USE 法建立性能指標(biāo)后，我們還需要通過一套完整的監(jiān)控系統(tǒng)，把這些指標(biāo)從采集、存儲、查詢、處理，再到告警和可視化展示等貫穿起來。這樣，不僅可以將系統(tǒng)資源的瓶頸快速暴露出來，還可以借助監(jiān)控的歷史數(shù)據(jù)，來追蹤定位性能問題的根源。

三、應(yīng)用監(jiān)控

1、應(yīng)用監(jiān)控指標(biāo)

跟系統(tǒng)監(jiān)控一樣，在構(gòu)建應(yīng)用程序的監(jiān)控系統(tǒng)之前，首先也需要確定，到底需要監(jiān)控哪些指標(biāo)。特別是要清楚，有哪些指標(biāo)可以用來快速確認(rèn)應(yīng)用程序的性能問題。 應(yīng)用程序的核心指標(biāo)，不再是資源的使用情況，而是請求數(shù)、錯誤率和響應(yīng)時間。 這些指標(biāo)不僅直接關(guān)系到用戶的使用體驗，還反映應(yīng)用整體的可用性和可靠性。有了請求數(shù)、錯誤率和響應(yīng)時間這三個黃金指標(biāo)之后，我們就可以快速知道，應(yīng)用是否發(fā)生了性能問題。但是，只有這些指標(biāo)顯然還是不夠的，因為發(fā)生性能問題后，我們還希望能夠快速定位“性能瓶頸區(qū)”。所以，在我看來，下面幾種指標(biāo)，也是監(jiān)控應(yīng)用程序時必不可少的。 第一個，是應(yīng)用進(jìn)程的資源使用情況，比如進(jìn)程占用的 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)等。使用過多的系統(tǒng)資源，導(dǎo)致應(yīng)用程序響應(yīng)緩慢或者錯誤數(shù)升高，是一個最常見的性能問題。 第二個，是應(yīng)用程序之間調(diào)用情況，比如調(diào)用頻率、錯誤數(shù)、延時等。由于應(yīng)用程序并不是孤立的，如果其依賴的其他應(yīng)用出現(xiàn)了性能問題，應(yīng)用自身性能也會受到影響。 第三個，是應(yīng)用程序內(nèi)部核心邏輯的運(yùn)行情況，比如關(guān)鍵環(huán)節(jié)的耗時以及執(zhí)行過程中的錯誤等。由于這是應(yīng)用程序內(nèi)部的狀態(tài)，從外部通常無法直接獲取到詳細(xì)的性能數(shù)據(jù)。所以，應(yīng)用程序在設(shè)計和開發(fā)時，就應(yīng)該把這些指標(biāo)提供出來，以便監(jiān)控系統(tǒng)可以了解其內(nèi)部運(yùn)行狀態(tài)。 有了應(yīng)用進(jìn)程的資源使用指標(biāo)，你就可以把系統(tǒng)資源的瓶頸跟應(yīng)用程序關(guān)聯(lián)起來，從而迅速定位因系統(tǒng)資源不足而導(dǎo)致的性能問題； 有了應(yīng)用程序之間的調(diào)用指標(biāo)，你可以迅速分析出一個請求處理的調(diào)用鏈中，到底哪個組件才是導(dǎo)致性能問題的罪魁禍?zhǔn)祝?而有了應(yīng)用程序內(nèi)部核心邏輯的運(yùn)行性能，你就可以更進(jìn)一步，直接進(jìn)入應(yīng)用程序的內(nèi)部，定位到底是哪個處理環(huán)節(jié)的函數(shù)導(dǎo)致了性能問題。 基于這些思路，我相信你就可以構(gòu)建出，描述應(yīng)用程序運(yùn)行狀態(tài)的性能指標(biāo)。再將這些指標(biāo)納入我們上一期提到的監(jiān)控系統(tǒng)（比如 Prometheus + Grafana）中，就可以跟系統(tǒng)監(jiān)控一樣，一方面通過告警系統(tǒng)，把問題及時匯報給相關(guān)團(tuán)隊處理；另一方面，通過直觀的圖形界面，動態(tài)展示應(yīng)用程序的整體性能。

2、全鏈路監(jiān)控

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

全鏈路跟蹤可以幫你迅速定位出，在一個請求處理過程中，哪個環(huán)節(jié)才是問題根源。比如，從上圖中，你就可以很容易看到，這是 Redis 超時導(dǎo)致的問題。 全鏈路跟蹤除了可以幫你快速定位跨應(yīng)用的性能問題外，還可以幫你生成線上系統(tǒng)的調(diào)用拓?fù)鋱D。這些直觀的拓?fù)鋱D，在分析復(fù)雜系統(tǒng)（比如微服務(wù)）時尤其有效。

3、日志監(jiān)控

性能指標(biāo)的監(jiān)控，可以讓你迅速定位發(fā)生瓶頸的位置，不過只有指標(biāo)的話往往還不夠。比如，同樣的一個接口，當(dāng)請求傳入的參數(shù)不同時，就可能會導(dǎo)致完全不同的性能問題。所以，除了指標(biāo)外，我們還需要對這些指標(biāo)的上下文信息進(jìn)行監(jiān)控，而日志正是這些上下文的最佳來源。 對比來看，指標(biāo)是特定時間段的數(shù)值型測量數(shù)據(jù)，通常以時間序列的方式處理，適合于實時監(jiān)控。 而日志則完全不同，日志都是某個時間點(diǎn)的字符串消息，通常需要對搜索引擎進(jìn)行索引后，才能進(jìn)行查詢和匯總分析。 對日志監(jiān)控來說，最經(jīng)典的方法，就是使用 ELK 技術(shù)棧，即使用 Elasticsearch、Logstash 和 Kibana 這三個組件的組合。 如下圖所示，就是一個經(jīng)典的 ELK 架構(gòu)圖：

Logstash 負(fù)責(zé)對從各個日志源采集日志，然后進(jìn)行預(yù)處理，最后再把初步處理過的日志，發(fā)送給 Elasticsearch 進(jìn)行索引。 Elasticsearch 負(fù)責(zé)對日志進(jìn)行索引，并提供了一個完整的全文搜索引擎，這樣就可以方便你從日志中檢索需要的數(shù)據(jù)。 Kibana 則負(fù)責(zé)對日志進(jìn)行可視化分析，包括日志搜索、處理以及絢麗的儀表板展示等。 下面這張圖，就是一個 Kibana 儀表板的示例，它直觀展示了 Apache 的訪問概況。

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

4、最后總結(jié)

應(yīng)用程序的監(jiān)控，可以分為指標(biāo)監(jiān)控和日志監(jiān)控兩大部分： 指標(biāo)監(jiān)控主要是對一定時間段內(nèi)性能指標(biāo)進(jìn)行測量，然后再通過時間序列的方式，進(jìn)行處理、存儲和告警。 日志監(jiān)控則可以提供更詳細(xì)的上下文信息，通常通過 ELK 技術(shù)棧來進(jìn)行收集、索引和圖形化展示。 在跨多個不同應(yīng)用的復(fù)雜業(yè)務(wù)場景中，你還可以構(gòu)建全鏈路跟蹤系統(tǒng)。這樣可以動態(tài)跟蹤調(diào)用鏈中各個組件的性能，生成整個流程的調(diào)用拓?fù)鋱D，從而加快定位復(fù)雜應(yīng)用的性能問題。

-End-

審核編輯 ：李倩