服務描述
註冊中心
服務框架
服務監控
服務追蹤
服務治理
目錄
監控微服務
監控物件
監控指標
監控維度
搭建監控系統
監控系統原理
監控系統四個環節
服務監控在微服務改造過程中的重要性不言而喻，沒有強大的監控能力，改造成微服務架構後，就無法掌控各個不同服務的情況，在遇到呼叫失敗時，如果不能快速發現系統的問題，對於業務來說就是一場災難。
既然要監控，那麼要監控哪些物件呢？根據我的實踐經驗，對於微服務系統來說，監控物件可以分為四個層次，由上到下可歸納為：
通常是指業務直接對使用者提供的功能的監控。以微博首頁 feed 為例，它向使用者提供了聚合關注的所有人的微博並按照時間順序瀏覽的功能，對首頁 feed 功能的監控就屬於使用者端的監控。
通常是指業務提供的功能所依賴的具體 rpc 介面的監控。繼續以微博首頁 feed 為例，這個功能依賴於使用者關注了哪些人的關係服務，每個人發過哪些微博的微博列表服務，以及每條微博具體內容是什麼的內容服務，對這幾個服務的呼叫情況的監控就屬於介面監控。
通常是指某個介面依賴的資源的監控。比如使用者關注了哪些人的關係服務使用的是 redis 來儲存關注列表，對 redis 的監控就屬於資源監控。
通常是指對伺服器本身的健康狀況的監控。主要包括 cpu 利用率、記憶體使用量、i/o 讀寫量、網絡卡頻寬等。對伺服器的基本監控也是必不可少的，因為伺服器本身的健康狀況也是影響服務本身的乙個重要因素，比如伺服器本身連線的網路交換機上聯頻寬被打滿，會影響所有部署在這台伺服器上的業務。
搞清楚要監控的物件之後，需要監控具體哪些指標呢？通常有以下幾個業務指標需要重點監控：
請求量監控分為兩個維度，乙個是實時請求量，乙個是統計請求量。實時請求量用 qps（queries per second）即每秒查詢次數來衡量，它反映了服務呼叫的實時變化情況。統計請求量一般用 pv（page view）即一段時間內使用者的訪問量來衡量，比如一天的 pv 代表了服務一天的請求量，通常用來統計報表。
大多數情況下，可以用一段時間內所有呼叫的平均耗時來反映請求的響應時間。但它只代表了請求的平均快慢情況，有時候我們更關心慢請求的數量。為此需要把響應時間劃分為多個區間，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上這五個區間，其中 500ms 以上這個區間內的請求數就代表了慢請求量，正常情況下，這個區間內的請求數應該接近於 0；在出現問題時，這個區間內的請求數會大幅增加，可能平均耗時並不能反映出這一變化。除此之外，還可以從 p90、p95、p99、p999 角度來監控請求的響應時間，比如 p99 = 500ms，意思是 99% 的請求響應時間在 500ms 以內，它代表了請求的服務質量，即 sla。
錯誤率的監控通常用一段時間內呼叫失敗的次數佔呼叫總次數的比率來衡量，比如對於介面的錯誤率一般用介面返回錯誤碼為 503 的比率來表示。
一般來說，要從多個維度來對業務進行監控，具體來講可以包括下面幾個維度：
從整體角度監控物件的的請求量、平均耗時以及錯誤率，全域性維度的監控一般是為了讓你對監控物件的呼叫情況有個整體了解。
一般為了業務的高可用性，服務通常部署在不止乙個機房，因為不同機房地域的不同，同乙個監控物件的各種指標可能會相差很大，所以需要深入到機房內部去了解。
即便是在同乙個機房內部，可能由於採購年份和批次的不同，位於不同機器上的同乙個監控物件的各種指標也會有很大差異。一般來說，新採購的機器通常由於成本更低，配置也更高，在同等請求量的情況下，可能表現出較大的效能差異，因此也需要從單機維度去監控同乙個物件。
同乙個監控物件，在每天的同一時刻各種指標通常也不會一樣，這種差異要麼是由業務變更導致，要麼是運營活動導致。為了了解監控物件各種指標的變化，通常需要與一天前、一周前、乙個月前，甚至三個月前做比較。
根據我的經驗，業務上一般會依據重要性程度對監控物件進行分級，最簡單的是分成核心業務和非核心業務。核心業務和非核心業務在部署上必須隔離，分開監控，這樣才能對核心業務做重點保障。
顯然，我們要對服務呼叫進行監控，首先要能收集到每一次呼叫的詳細資訊，包括呼叫的響應時間、呼叫是否成功、呼叫的發起者和接收者分別是誰，這個過程叫作資料採集。採集到資料之後，要把資料通過一定的方式傳輸給資料處理中心進行處理，這個過程叫作資料傳輸。資料傳輸過來後，資料處理中心再按照服務的維度進行聚合，計算出不同服務的請求量、響應時間以及錯誤率等資訊並儲存起來，這個過程叫作資料處理。最後再通過介面或者 dashboard 的形式對外展示服務的呼叫情況，這個過程叫作資料展示。
通常有兩種資料收集方式：
服務主動上報，這種處理方式通過在業務**或者服務框架裡加入資料收集**邏輯，在每一次服務呼叫完成後，主動上報服務的呼叫資訊。
**收集，這種處理方式通過服務呼叫後把呼叫的詳細資訊記錄到本地日誌檔案中，然後再通過**去解析本地日誌檔案，然後再上報服務的呼叫資訊。
無論哪種資料採集方式，首先要考慮的問題就是取樣率，也就是採集資料的頻率。取樣率決定了監控的實時性與精確度，一般來說，取樣率越高，監控的實時性就越高，精確度也越高。但取樣對系統本身的效能也會有一定的影響，尤其是採集後的資料需要寫到本地磁碟的時候，過高的取樣率會導致系統寫入磁碟的 i/o 過高，進而會影響到正常的服務呼叫。所以設定合理的採用率是資料採集的關鍵，最好是可以動態控制取樣率，在系統比較空閒的時候加大取樣率，追求監控的實時性與精確度；在系統負載比較高的時候減小取樣率，追求監控的可用性與系統的穩定性。
資料傳輸最常用的方式有兩種：
udp 傳輸，這種處理方式是資料處理單元提供伺服器的請求位址，資料採集後通過 udp 協議與伺服器建立連線，然後把資料傳送過去。
kafka 傳輸，這種處理方式是資料採集後傳送到指定的 topic，然後資料處理單元再訂閱對應的 topic，就可以從 kafka 訊息佇列中讀取到對應的資料。
無論採用哪種傳輸方式，資料格式都十分重要，尤其是對頻寬敏感以及解析效能要求比較高的場景，一般資料傳輸時採用的資料格式有兩種：
二進位制協議，最常用的就是 pb 物件，它的優點是高壓縮比和高效能，可以減少傳輸頻寬並且序列化和反序列化效率特別高。
文字協議，最常用的就是 json 字串，它的優點是可讀性好，但相比於 pb 物件，傳輸占用頻寬高，並且解析效能也要差一些。
資料處理是對收集來的原始資料進行聚合並儲存。資料聚合通常有兩個維度：
介面維度聚合，這個維度是把實時收到的資料按照介面名維度實時聚合在一起，這樣就可以得到每個介面的實時請求量、平均耗時等資訊。
機器維度聚合，這個維度是把實時收到的資料按照呼叫的節點維度聚合在一起，這樣就可以從單機維度去檢視每個介面的實時請求量、平均耗時等資訊。
聚合後的資料需要持久化到資料庫中儲存，所選用的資料庫一般分為兩種：
索引資料庫，比如 elasticsearch，以倒排索引的資料結構儲存，需要查詢的時候，根據索引來查詢。
時序資料庫，比如 opentsdb，以時序序列資料的方式儲存，查詢的時候按照時序如 1min、5min 等維度來查詢。
資料展示是把處理後的資料以 dashboard 的方式展示給使用者。資料展示有多種方式，比如曲線圖、餅狀圖、格仔圖展示等。
曲線圖。一般是用來監控變化趨勢的，比如展示了監控物件隨著時間推移的變化趨勢，分析某段時間內變化大小，曲線是否平穩。
餅狀圖。一般是用來監控佔比分布的，比如展示了使用不同的手機網路佔比情況，即wi-fi 、 4g 的、3g 和 2g的佔比。
格仔圖。主要做一些細粒度的監控，比如不同的機器的介面呼叫請求量和耗時情況。
如何監控微服務
首先要搞清楚三個問題 監控的物件是什麼？具體監控哪些指標？從哪些緯度進行監控？監控的物件可以分為四個層次，從上到下可以歸納為 監控指標 監控維度 監控系統原理 我們對服務呼叫進行監控，首先要能收集到每一次呼叫的詳細資訊，包括呼叫的響應時間，呼叫是否成功，呼叫的發起者和接受者分別是誰，這個過程叫做資料...
Micrometer 微服務監控
不同於單體架構的應用，微服務架構由於服務數量眾多，出故障的概率更大，這種時候不能單純依靠 人肉 運維，否則當服務數量越來越多時成本將變得不可控。乙個好的解決方案是我們需要對服務進行監控，監控服務執行的資料。當有異常情況出現時，服務能夠自動報警，方便運維工程師去處理。spring cloud 中對於服...
電商微服務實戰之服務監控
一般可分為四類 響應時間 可用一段時間內所有呼叫的平均耗時反映請求響應時間。但只代表請求的平均快慢，有時更關心慢請求的數量。需把響應時間劃分多區間，比如0 10ms 10ms 50ms 50ms 100ms 100ms 500ms 500ms，500ms區間內請求數即代表慢請求量，正常情況下該區間內...