電商微服務實戰之服務監控（上）

監控對象

一般可分為四類：

• 使用者端監控

  業務直接對使用者提供的功能的監控。以知乎首頁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的形式對外展示服務的調用情況

1 資料采集

有如下方式：

• 服務主動上報

  通過在業務代碼或者服務架構裡加入資料收集代碼邏輯，在每次服務調用完成後，主動上報服務調用資訊。

代理收集

通過服務調用後把調用的詳細資訊記錄到本地日志檔案，再通過代理去解析本地日志檔案，最後再上報服務的調用資訊。

無論哪種，首先要考慮采樣率，即采集資料的頻率。采樣率越高，監控實時性就越高，精确度越高。但采樣對系統性能也會有影響，尤其是采集後的資料需寫到本地磁盤時，過高采樣率會導緻寫入磁盤的I/O過高，影響正常服務調用。

是以設定合理采用率是關鍵，最好可動态控制采樣率

系統較閑時，加大采樣率，追求監控實時性與精确度

系統負載較高時，減小采樣率，追求監控的可用性與系統的穩定性