一、起始

在實(shí)際的性能分析中，一個(gè)很常見的現(xiàn)象是，明明發(fā)生了性能瓶頸，但當(dāng)你登錄到服務(wù)器中想要排查的時(shí)候，卻發(fā)現(xiàn)瓶頸已經(jīng)消失了?；蛘哒f，性能問題總是時(shí)不時(shí)地發(fā)生，但卻很難找出發(fā)生規(guī)律，也很難重現(xiàn)。而要解決這個(gè)問題，就要搭建監(jiān)控系統(tǒng)，把系統(tǒng)和應(yīng)用程序的運(yùn)行狀況監(jiān)控起來，并定義一系列的策略，在發(fā)生問題時(shí)第一時(shí)間告警通知。一個(gè)好的監(jiān)控系統(tǒng)，不僅可以實(shí)時(shí)暴露系統(tǒng)的各種問題，更可以根據(jù)這些監(jiān)控到的狀態(tài)，自動(dòng)分析和定位大致的瓶頸來源，從而更精確地把問題匯報(bào)給相關(guān)團(tuán)隊(duì)處理。要做好監(jiān)控，最核心的就是全面的、可量化的指標(biāo)，這包括系統(tǒng)和應(yīng)用兩個(gè)方面。從系統(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)用耗時(shí)、執(zhí)行過程中的錯(cuò)誤、內(nèi)部對(duì)象的內(nèi)存使用等應(yīng)用程序內(nèi)部的運(yùn)行狀況。

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

1、USE 法

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

• 使用率，表示資源用于服務(wù)的時(shí)間或容量百分比。100% 的使用率，表示容量已經(jīng)用盡或者全部時(shí)間都用于服務(wù)。
• 飽和度，表示資源的繁忙程度，通常與等待隊(duì)列的長(zhǎng)度相關(guān)。100% 的飽和度，表示資源無法接受更多的請(qǐng)求。
• 錯(cuò)誤數(shù)表示發(fā)生錯(cuò)誤的事件個(gè)數(shù)。錯(cuò)誤數(shù)越多，表明系統(tǒng)的問題越嚴(yán)重。

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

2、性能指標(biāo)

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

不過，需要注意的是，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)，自動(dòng)分析和定位大致的瓶頸來源；最后，再通過告警系統(tǒng)，把問題及時(shí)匯報(bào)給相關(guān)團(tuán)隊(duì)處理?？梢钥闯?，一個(gè)完整的監(jiān)控系統(tǒng)通常由數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)查詢和處理、告警以及可視化展示等多個(gè)模塊組成。所以，要從頭搭建一個(gè)監(jiān)控系統(tǒng)，其實(shí)也是一個(gè)很大的系統(tǒng)工程。不過，幸運(yùn)的是，現(xiàn)在已經(jīng)有很多開源的監(jiān)控工具可以直接使用，比如最常見的 Zabbix、Nagios、Prometheus 等等。下面，我就以 Prometheus 為例，為你介紹這幾個(gè)組件的基本原理。如下圖所示，就是 Prometheus 的基本架構(gòu)：

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

4、最后總結(jié)

系統(tǒng)監(jiān)控的核心是資源的使用情況，這既包括 CPU、內(nèi)存、磁盤、文件系統(tǒng)、網(wǎng)絡(luò)等硬件資源，也包括文件描述符數(shù)、連接數(shù)、連接跟蹤數(shù)等軟件資源。而要描述這些資源瓶頸，最簡(jiǎn)單有效的方法就是 USE 法。USE 法把系統(tǒng)資源的性能指標(biāo)，簡(jiǎn)化為了三個(gè)類別：使用率、飽和度以及錯(cuò)誤數(shù)。當(dāng)這三者之中任一類別的指標(biāo)過高時(shí)，都代表相對(duì)應(yīng)的系統(tǒng)資源可能存在性能瓶頸?；?USE 法建立性能指標(biāo)后，我們還需要通過一套完整的監(jiān)控系統(tǒng)，把這些指標(biāo)從采集、存儲(chǔ)、查詢、處理，再到告警和可視化展示等貫穿起來。這樣，不僅可以將系統(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)，不再是資源的使用情況，而是請(qǐng)求數(shù)、錯(cuò)誤率和響應(yīng)時(shí)間。這些指標(biāo)不僅直接關(guān)系到用戶的使用體驗(yàn)，還反映應(yīng)用整體的可用性和可靠性。有了請(qǐng)求數(shù)、錯(cuò)誤率和響應(yīng)時(shí)間這三個(gè)黃金指標(biāo)之后，我們就可以快速知道，應(yīng)用是否發(fā)生了性能問題。但是，只有這些指標(biāo)顯然還是不夠的，因?yàn)榘l(fā)生性能問題后，我們還希望能夠快速定位“性能瓶頸區(qū)”。所以，在我看來，下面幾種指標(biāo)，也是監(jiān)控應(yīng)用程序時(shí)必不可少的。第一個(gè)，是應(yīng)用進(jìn)程的資源使用情況，比如進(jìn)程占用的 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò)等。使用過多的系統(tǒng)資源，導(dǎo)致應(yīng)用程序響應(yīng)緩慢或者錯(cuò)誤數(shù)升高，是一個(gè)最常見的性能問題。第二個(gè)，是應(yīng)用程序之間調(diào)用情況，比如調(diào)用頻率、錯(cuò)誤數(shù)、延時(shí)等。由于應(yīng)用程序并不是孤立的，如果其依賴的其他應(yīng)用出現(xiàn)了性能問題，應(yīng)用自身性能也會(huì)受到影響。第三個(gè)，是應(yīng)用程序內(nèi)部核心邏輯的運(yùn)行情況，比如關(guān)鍵環(huán)節(jié)的耗時(shí)以及執(zhí)行過程中的錯(cuò)誤等。由于這是應(yīng)用程序內(nèi)部的狀態(tài)，從外部通常無法直接獲取到詳細(xì)的性能數(shù)據(jù)。所以，應(yīng)用程序在設(shè)計(jì)和開發(fā)時(shí)，就應(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)，你可以迅速分析出一個(gè)請(qǐng)求處理的調(diào)用鏈中，到底哪個(gè)組件才是導(dǎo)致性能問題的罪魁禍?zhǔn)?；而有了?yīng)用程序內(nèi)部核心邏輯的運(yùn)行性能，你就可以更進(jìn)一步，直接進(jìn)入應(yīng)用程序的內(nèi)部，定位到底是哪個(gè)處理環(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)，把問題及時(shí)匯報(bào)給相關(guān)團(tuán)隊(duì)處理；另一方面，通過直觀的圖形界面，動(dòng)態(tài)展示應(yīng)用程序的整體性能。

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

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

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

3、日志監(jiān)控

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

Logstash 負(fù)責(zé)對(duì)從各個(gè)日志源采集日志，然后進(jìn)行預(yù)處理，最后再把初步處理過的日志，發(fā)送給 Elasticsearch 進(jìn)行索引。Elasticsearch 負(fù)責(zé)對(duì)日志進(jìn)行索引，并提供了一個(gè)完整的全文搜索引擎，這樣就可以方便你從日志中檢索需要的數(shù)據(jù)。Kibana 則負(fù)責(zé)對(duì)日志進(jìn)行可視化分析，包括日志搜索、處理以及絢麗的儀表板展示等。下面這張圖，就是一個(gè) 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)控主要是對(duì)一定時(shí)間段內(nèi)性能指標(biāo)進(jìn)行測(cè)量，然后再通過時(shí)間序列的方式，進(jìn)行處理、存儲(chǔ)和告警。日志監(jiān)控則可以提供更詳細(xì)的上下文信息，通常通過 ELK 技術(shù)棧來進(jìn)行收集、索引和圖形化展示。在跨多個(gè)不同應(yīng)用的復(fù)雜業(yè)務(wù)場(chǎng)景中，你還可以構(gòu)建全鏈路跟蹤系統(tǒng)。這樣可以動(dòng)態(tài)跟蹤調(diào)用鏈中各個(gè)組件的性能，生成整個(gè)流程的調(diào)用拓?fù)鋱D，從而加快定位復(fù)雜應(yīng)用的性能問題。