在效能測試中，我覺得監控是非常重要的環節。因為這是做效能分析的前提，走出這一步，才有後面的分析。
監控是效能分析承上啟下的關鍵點。設計監控是我們效能測試工程師必須要做的事情。當然了，僅僅設計監控是不夠的，還要看懂監控資料才能分析。我們將在後面的篇幅一一拆解。
我覺得效能測試工程師也一定要自己去實現一遍監控的環節，而不是直接用其他團隊搭建的監控工具。你可以自己找個 demo 伺服器做一遍，這樣才能真正理解後續要關注的點在哪裡。
監控平臺還指望別人給搭好，點個連結就能出資料了，這顯然不是一個技術人員該有的樣子。
監控設計步驟
如果要讓效能測試人員設計監控邏輯，要如何做呢？首先，你要分析系統的架構。在知道架構中使用的元件之後，再針對每個元件進行監控。其次，監控要有層次，要有步驟。有些人喜歡一上來就把方法執行時間、SQL 執行時間給列出來，直接幹到程式碼層，讓人覺得觸控到了最頂級的技能。然而在我的工作中，通常不這麼做，應該是先全域性，後定向定量分析。最後，通過分析全域性、定向、分層的監控資料做分析，再根據分析的結果決定下一步要收集什麼資訊，然後找到完整的證據鏈。這才是監控應該有的步驟，才能體現監控的價值。
監控技術圖譜
這張圖是我認為在一個效能測試中，該有的技術圖譜。
從這個圖中我們可以看到，除了壓力工具之外，還有很多技術細節。
通常在各種場合下，我都會說，這些都是我們要學習的範圍，做效能分析的人，不一定能完全能掌握這些內容，那你所在的效能團隊就應該有這樣的能力。
因為效能團隊要推進瓶頸的定位解決，所以要有和其他團隊正面溝通的能力。下面我們就以具體的操作過程來說明設計的落地過程。現在的流行框架（比如說 Spring Cloud）中的熔斷監控、限流服務、服務健康檢查／監控、鏈路監控、服務跟蹤、聚合監控等等，都是非常好的監控手段。比如說下面這樣的架構圖：
這是比較常見的微服務技術架構。其中很多開源工具已經提供了監控的能力。
對技術的發展，我們要擁抱。但對思路的梳理更為重要，因為框架平臺工具都是為了實現目標而存在的。在本篇中，我們還是迴歸根本，說一下監控設計的思路，講清楚效能測試中應該如何拆分監控的點。當你看完了之後，即使是面對不同的架構，也有監控部署的思路。
架構圖
那麼我們就來到開始的位置了。做效能監控之前，先畫一個最簡單的架構圖，看一下架構中各有什麼元件，各有什麼服務，將這些列下來，再找對應的監控手段和方式，看哪種手段和方式在效能測試過程中成本最低，效率最高。
如果把效能歸到測試的這個階段，那就必須先考慮測試的具體情況。
有些企業因為有長期的積累，監控平臺完整又穩定，那顯然是最好的。如果是短期專案類的效能測試，又涉及到多方企業的，基本上不要想有完整成熟的監控平臺這件事了。
但是不管怎麼樣，我們都需要拿到架構的全域性監控資料。針對下面的這個不大的架構，我們來考慮下如何拆分。
需要監控的內容如下：
- 作業系統
- Nginx
- Tomcat
- Redis
- MySQL
下面我就來細化下這個簡單架構的監控設計。
監控設計
下圖可以大概說明我對監控的整體設計理念。
我來說明一下：
我們要對整個架構做分層。
在每一個層級上列出要監控的計數器。
尋找相應的監控工具，實現對這些計數器的監控。
如果一個工具做不到，在定位過程中考慮補充工具。
要做到對每層都不遺漏。
從大的分類上來看，我們識別出每個監控的節點和層級，再對應到架構中，如下圖所示：
最適合的監控方式是什麼樣的呢？那就是成本最低，監控範圍最大，效率最快。而是否持久就不再是考慮的重點了，因為專案結束了，監控工具可能也被拆了。
在企業中，我們也是首先考慮快速的監控實現。但是，還要一點要考慮，就是監控的持久有效性，能一直用下去。所以，在快速實現了之後，在必要時，會做一些二次開發，定製監控。
對了，這裡再提一句，我不建議一開始就把程式碼級的監控給加進來。不光是因為它消耗資源，更重要的是，真的沒有太大的必要。像方法的執行時間這類監控，如果沒有定位到它們有問題，我們為什麼要去看呢？當我們有了證據鏈的時候，是不是更一針見血呢？
所以最重要的是，我想看到的資料，到底能不能看得到。
對於上述的每個元件，我都建議用下面這樣的監控思路。敲黑板！下圖是重點！
有人可能會想說：就這幾個字還值當畫個圖嗎？我覺得非常有必要。因為全域性到定向的思路幫我解決了很多的問題。
全域性監控設計
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 層的全域性監控計數器，我們首先要學會的，就是判斷這些計數器說明了什麼問題。我在第三模組中寫監控分析工具，會詳細說明這部分。這裡呢，我先把定向監控細化地解釋一下，把這個思路給你講得明明白白，通通透透。