一般可分為四類：
響應時間
可用一段時間內所有呼叫的平均耗時反映請求響應時間。但只代表請求的平均快慢，有時更關心慢請求的數量。需把響應時間劃分多區間，比如0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、>500ms，>500ms區間內請求數即代表慢請求量，正常情況下該區間內請求數應該接近0；出現問題時，區間內請求數會大幅增加，可能平均耗時並不能反映變化。
還可以p90、p95、p99、p999角度來監控請求的響應時間，比如p99 = 500ms，意思是99%的請求響應時間在500ms以內，它代表了請求的服務質量，即sla。
錯誤率一段時間內呼叫失敗的次數佔呼叫總次數比率，比如對於介面的錯誤率一般用介面返回錯誤碼為503的比率來表示。
如何搭建監控系統，來完成上面這些監控功能呢？
監控系統主要包括四個環節：
有如下方式：
無論哪種，首先要考慮取樣率，即採集資料的頻率。取樣率越高，監控實時性就越高，精確度越高。但取樣對系統效能也會有影響，尤其是採集後的資料需寫到本地磁碟時，過高取樣率會導致寫入磁碟的i/o過高，影響正常服務呼叫。
所以設定合理採用率是關鍵，最好可動態控制取樣率
常用方式如下：
無論哪種，資料格式都十分重要，尤其是對頻寬敏感以及解析效能要求比較高的場景，一般資料傳輸時採用的資料格式有兩種：
文字協議，最常用的就是json字串，它的優點是可讀性好，但相比於pb物件，傳輸占用頻寬高，並且解析效能也要差一些。
聚合並儲存收集來的原始資料。
資料聚合通常有兩個維度：
聚合後資料需持久化到db，所選用db一般兩種：
把處理後的資料以dashboard方式展示給使用者。
資料展示有多種方式，比如曲線圖、餅狀圖、格仔圖。
服務監控在微服務改造過程中十分重要，沒有強大監控能力，就無法掌控各個不同服務的情況，在遇到呼叫失敗時，如果不能快速發現系統的問題，業務就成了災難。
參考
Spring Cloud 微服務實戰筆記
傳統開發所有業務邏輯都在乙個應用中,開發，測試，部署隨著需求增加會不斷為單個專案增加不同業務模組 前端展現也不侷限於html檢視模板的形式,後端向前端支援需要更多的介面模組。隨著需求增多，專案變大，單體系統部署在乙個程序內部，往往修改很小的功能，為了部署上線也會影響其他功能。後期維護成本會變得越來越...
微服務之服務監控
服務描述 註冊中心 服務框架 服務監控 服務追蹤 服務治理 目錄 監控微服務 監控物件 監控指標 監控維度 搭建監控系統 監控系統原理 監控系統四個環節 服務監控在微服務改造過程中的重要性不言而喻，沒有強大的監控能力，改造成微服務架構後，就無法掌控各個不同服務的情況，在遇到呼叫失敗時，如果不能快速發...
《Spring Cloud微服務實戰》開始預售
京東 亞馬遜已全面開啟預售！快來一起體驗spring cloud所帶來的全家桶式微服務架構解決方案！掃一掃前往京東購買 為什麼選擇spring cloud spring cloud簡介 版本說明 配置詳解 監控與管理 小結eureka詳解 原始碼分析 配置詳解 服務例項類配置 元資料 跨平台支援 原...