轉載自：https://blog.csdn.net/ths512/article/details/111998576

=======================

在效能測試中，我覺得監控是非常重要的環節。因為這是做效能分析的前提，走出這一步，才有後面的分析。

監控是效能分析承上啟下的關鍵點。

設計監控是我們效能測試工程師必須要做的事情。當然了，僅僅設計監控是不夠的，還要看懂監控資料才能分析。我們將在後面的篇幅一一拆解。

我覺得效能測試工程師也一定要自己去實現一遍監控的環節，而不是直接用其他團隊搭建的監控工具。你可以自己找個demo伺服器做一遍，這樣才能真正理解後續要關注的點在哪裡。

之前在一個專案上，我跟團隊成員說，把監控一層層部署起來。有個小姑娘提出一個疑問：“監控有什麼要部署的嗎？不是用JConsole就好了嗎？”我說每個工具都有功能的侷限性，所以要多種工具配合在一起才能有完整的資料可分析。然後我又問她這個想法從哪來的。她說之前帶她的一個測試經理說的，對Java的應用，只要用JConsole監控就好了。我不知道他們的溝通上下文，但我理解如果不是這姑娘在斷章取義，那就是這個測試經理引導錯誤了。

監控平臺還指望別人給搭好，點個連結就能出資料了，這顯然不是一個技術人員該有的樣子。

監控設計步驟

如果要讓效能測試人員設計監控邏輯，要如何做呢？

首先，你要分析系統的架構。在知道架構中使用的元件之後，再針對每個元件進行監控。

其次，監控要有層次，要有步驟。有些人喜歡一上來就把方法執行時間、SQL執行時間給列出來，直接幹到程式碼層，讓人覺得觸控到了最頂級的技能。然而在我的工作中，通常不這麼做，應該是先全域性，後定向定量分析。

最後，通過分析全域性、定向、分層的監控資料做分析，再根據分析的結果決定下一步要收集什麼資訊，然後找到完整的證據鏈。

這才是監控應該有的步驟，才能體現監控的價值。

監控技術圖譜

這張圖是我認為在一個性能測試中，該有的技術圖譜。

從這個圖中我們可以看到，除了壓力工具之外，還有很多技術細節。通常在各種場合下，我都會說，這些都是我們要學習的範圍，做效能分析的人，不一定能完全能掌握這些內容，那你所在的效能團隊就應該有這樣的能力。因為效能團隊要推進瓶頸的定位解決，所以要有和其他團隊正面溝通的能力。

下面我們就以具體的操作過程來說明設計的落地過程。

現在的流行框架（比如說Spring Cloud）中的熔斷監控、限流服務、服務健康檢查／監控、鏈路監控、服務跟蹤、聚合監控等等，都是非常好的監控手段。比如說下面這樣的架構圖：

這是比較常見的微服務技術架構。其中很多開源工具已經提供了監控的能力。在網上也能找到一些部署搭建的資料，好像不提微服務、全鏈路就不好意思見人了似的。

對技術的發展，我們要擁抱。但對思路的梳理更為重要，因為框架平臺工具都是為了實現目標而存在的。

在本篇中，我們還是迴歸根本，說一下監控設計的思路，講清楚效能測試中應該如何拆分監控的點。當你看完了之後，即使是面對不同的架構，也有監控部署的思路。

架構圖

那麼我們就來到開始的位置了。做效能監控之前，先畫一個最簡單的架構圖，看一下架構中各有什麼元件，各有什麼服務，將這些列下來，再找對應的監控手段和方式，看哪種手段和方式在效能測試過程中成本最低，效率最高。

如果把效能歸到測試的這個階段，那就必須先考慮測試的具體情況。

有些企業因為有長期的積累，監控平臺完整又穩定，那顯然是最好的。如果是短期專案類的效能測試，又涉及到多方企業的，基本上不要想有完整成熟的監控平臺這件事了。

但是不管怎麼樣，我們都需要拿到架構的全域性監控資料。針對下面的這個不大的架構，我們來考慮下如何拆分。

需要監控的內容如下：

1. 作業系統
2. Nginx
3. Tomcat
4. Redis
5. MySQL

下面我就來細化下這個簡單架構的監控設計。

監控設計

下圖可以大概說明我對監控的整體設計理念。

我來說明一下：

1. 我們要對整個架構做分層。
2. 在每一個層級上列出要監控的計數器。
3. 尋找相應的監控工具，實現對這些計數器的監控。如果一個工具做不到，在定位過程中考慮補充工具。
4. 要做到對每層都不遺漏。

從大的分類上來看，我們識別出每個監控的節點和層級，再對應到架構中，如下圖所示：

最適合的監控方式是什麼樣的呢？那就是成本最低，監控範圍最大，效率最快。而是否持久就不再是考慮的重點了，因為專案結束了，監控工具可能也被拆了。

在企業中，我們也是首先考慮快速的監控實現。但是，還要一點要考慮，就是監控的持久有效性，能一直用下去。所以，在快速實現了之後，在必要時，會做一些二次開發，定製監控。

對了，這裡再提一句，我不建議一開始就把程式碼級的監控給加進來。不光是因為它消耗資源，更重要的是，真的沒有太大的必要。像方法的執行時間這類監控，如果沒有定位到它們有問題，我們為什麼要去看呢？當我們有了證據鏈的時候，是不是更一針見血呢？

所以最重要的是，我想看到的資料，到底能不能看得到。

對於上述的每個元件，我都建議用下面這樣的監控思路。敲黑板！下圖是重點！

有人可能會想說：就這幾個字還值當畫個圖嗎？我覺得非常有必要。因為全域性到定向的思路幫我解決了很多的問題。

全域性監控設計

那麼什麼是全域性監控呢？

OS層（CentOS為例）

就拿OS來說吧，我們一般進到系統中，看的就是CPU、I/O、記憶體、網路的使用率，這是很常規的計數器。在很多人看來，這些計數器是可以反應出一個系統的全域性健康狀態的。

先不管通過這些計數器得到的結論是不是對的。我們首先要知道的是，要有這樣全域性監控的潛意識，之所以說潛意識，是因為很多人不知道為什麼看這些，但還是這樣看了。

那麼實際上做一個OS的全域性監控需要看多少個計數器呢？我們看下架構圖。

因為新版核心沒有給更細的核心架構圖，所以我用2.6.26版本的Linux核心架構圖來說明思路。

給這張圖的目的就是建議先看架構圖，再考慮要監控的大分類有多少。從上圖中，我們可以看到有這麼幾類，system、processing、memory、storage、networking等。

這裡畫出一個思維導圖，給出我的經驗計數器。

針對OS，我通常看上圖中紅色計數器的部分，這是OS檢視的第一層。有第一層就有第二層，所以才需要定向的監控。後面我們再說定向監控的思路。

DB層（MySQL為例）

我們再說DB層，以MySQL為例。和上面的理念一樣，我們也要看架構圖。

此圖來自於MySQL官方，各大技術網站均有展示。

接著我們看下全域性監控的分類，如下圖所示：

同樣，這也是MySQL全域性監控的第一層。

這個內容的整理並不具有什麼技術性。稍微瞭解一下Linux和MySQL的架構，就可以整理出來。我們依此類推，按照這個思路，就可以把其他的元件都整理出第一層監控元件。

有了全域性監控，接著就是定向監控了。這是尋找證據鏈的關鍵一節。

定向監控

有了OS層的全域性監控計數器，我們首先要學會的，就是判斷這些計數器說明了什麼問題。我在第三模組中寫監控分析工具，會詳細說明這部分。

這裡呢，我先把定向監控細化地解釋一下，把這個思路給你講得明明白白，通通透透。

OS層之定向監控細化1

當你看到CPU消耗得多，那麼你就得按照下面這張圖細化思路（從左向右看）：

列出流程圖來就是如下所示：

1.   st=>start: 開始
2.   e=>end: 結束
3.   op1=>operation: 通過si CPU找到對應的軟中斷號及中斷裝置
4.   op2=>operation: 再找到軟中斷對應的模組
5.   op3=>operation: 再到模組對應的實現原理
6.   op4=>operation: 給出解決方案
7.   st->op1->op2->op3->op4->e

OS層之定向監控細化2

當你看到OS全域性監控圖中的Network中的Total總流量比較大時，就要有這樣的分析思路（從右向左看）：

列出流程圖來就是如下所示：

1.   st=>start: 開始
2.   e=>end: 結束
3.   op1=>operation: 網路總流量
4.   op2=>operation: 分析效能場景中的業務流量
5.   op3=>operation: 分析網路頻寬
6.   op4=>operation: 分析網路佇列
7.   op5=>operation: 解決方案
8.   st->op1->op2->op3->op4->op5->e

依此類推，就可以列出更多OS層的定向監控分析的思路。

DB層之定向監控細化1

同OS層的定向監控細化思路一樣，在DB層中要想找到完整的鏈路，那麼在MySQL中也必須把邏輯想明白。

當你發現查詢和排序的報表有問題時，比如說下面這樣（資料來自於MySQL Report）：

1.   __ SELECT and Sort _____________________________________________________
2.   Scan 7.88M 2.0/s %SELECT: 38.04
3.   Range 237.84k 0.1/s 1.15
4.   Full join 5.97M 1.5/s 28.81
5.   Range check 913.25k 0.2/s 4.41
6.   Full rng join 18.47k 0.0/s 0.09
7.   Sort scan 737.86k 0.2/s
8.   Sort range 56.13k 0.0/s
9.   Sort mrg pass 282.65k 0.1/s
10.    

居然每秒就能有2次全表掃描！那該怎麼辦呢？定向細化，如下所示：

相信這樣常規的動作，你肯定能掌握得了。

那麼來看下一個。

DB層之定向監控細化2

當你看到鎖資料的時候，如下所示：

1.   __ InnoDB Lock _________________________________________________________
2.   Waits 227829 0.1/s
3.   Current 1
4.   Time acquiring
5.   Total 171855224 ms
6.   Average 754 ms
7.   Max 6143 ms
8.    

當前等待並不多，只有1。但是你看下面的平均時間為754ms，這還能不能愉快地玩耍了？

下面我也同樣列出定向監控細化的思路。

分析產生鎖的SQL，看SQL的Profiling資訊，再根據資訊找下一步原因，最終給出解決方案。

有了上面的全域性—定向監控思路，並且將每個元件的第一層的計數器一一列出。這是我們監控分析的第一步。

至於定向監控部分，我不建議一開始就列，主要原因有三個：

1. 耗費太多時間；
2. 列出來也可能半輩子也用不上；
3. 照搬列出來的定向監控邏輯，有可能誤導你對實時資料的判斷。

所以最好的定向監控就是在實際的效能執行過程中，根據實際的場景畫出來。這幫助我在工作中無往不利，理清了很多一開始根本想不到的問題。

監控工具

有了思路，工具都不是事兒。

針對上面我們畫的架構圖，我大概列出相應的監控工具及優缺點。這裡列得並不詳盡，只供借鑑思路使用。

如果要選擇的話，肯定是用Prometheus + Exporter的思路會好一點。於是我們這樣實現全域性的監控。

OS：

DB：

Nginx：

Redis：

上面圖看膩了，你能換個嗎？客官彆著急，現在就換。

Tomcat：

好了，有了這些監控工具，基本上對每個元件的全域性監控就解決了。

這時可能會有人說，你這個架構也太不新潮了。現在都玩Kubernetes、Docker、Spring Cloud、微架構啥的了。

那同樣，我們還是要列出有哪些監控的元件。

1. Node：就是OS。
2. Cluster；
3. Pod；
4. 微服務鏈路。

然後再實現相應的全域性監控。我們可以在Kubernetes+Docker下可以看到這樣的部分全域性監控資料。

DashBoard：

Cluster：

Pod：

微服務鏈路：

那麼具體的定向監控細化呢？在你的具體場景中，照樣可以通過上面的思路標識出來。

有人說，那我還有什麼什麼元件，相信你通看全篇，已經學會思路了，那就自己動手吧。

我想說的是，不管你的架構有多麼複雜，元件有多少，這樣的監控邏輯都是一定要有的。適合的工具要用，並且儘量多用，但工具還遠遠替代不了分析的思維邏輯。沒有判斷的能力，再強悍的工具也只是個花架子。

PS：如沒有註明引用，本專欄所有的截圖都是在我搭建的環境中截來的，所以不存在在其他地方看到相同圖的可能性。

總結在本篇中，我描述了監控設計的思維邏輯。對架構中的元件進行了分析之後，通過全域性—定向的思路列出要看的計數器，再通過相應的監控工具去實現，拿到要分析的資料。這就完成了要做的監控設計和具體實施。至於你是用什麼工具去實現的，這並不重要，因為拿到監控資料，可供分析證據鏈最重要