「微服務系列 11」微服務系統監控分層

監控是微服務治理的一個重要環節，監控系統的完善程度直接影響到咱們微服務質量的好壞，咱們的微服務在線上運行的時候有沒有一套完善的監控體系能去了解到它的健康狀況，對整個系統的可靠性和穩定性是很是重要。

一個比較完善的微服務監控體系須要涉及到哪些層次，以下圖，大體能夠劃分爲五個層次的監控

最底層基礎設施監控

通常是由運維人員進行負責，涉及到的方面比較接近硬件體系，例如網絡，交換機，路由器等低層設備，這些設備的可靠性穩定性就直接影響到上層服務應用的穩定性，因此須要對網絡的流量，丟包狀況，錯包狀況，鏈接數等等這些基礎設施的核心指標進行監控。

系統層監控

涵蓋了物理機，虛擬機，操做系統這些都是屬於系統級別監控的方面，對幾個核心指標監控，如cpu使用率，內存佔用率，磁盤IO和網絡帶寬狀況

應用層監控

涉及到方面就跟服務緊密相關，例如對url訪問的性能，訪問的調用數，訪問的延遲，還有對服務提供性能進行監控，服務的錯誤率，對sql也須要進行監控，查看是否有慢sql，對與cache來講，須要監控緩存的命中率和性能，每一個服務的響應時間和qps等等

業務監控

比方說一個典型的交易網站，須要關注它的用戶登陸狀況，註冊狀況，下單狀況，支付狀況，這些直接影響到實際觸發的業務交易狀況，這個監控能夠提供給運營和公司高管他們需須要關注的數據，直接可能對公司戰略產生影響。

端用戶體驗監控

一個應用程序可能經過app，h5，pc端的方式交付到用戶的手上，用戶經過瀏覽器，客戶端打開練到到咱們的服務，那麼在用戶端用戶的體驗是怎麼樣，用戶端的性能是怎麼樣，有沒有產生錯誤，這些信息也是須要進行監控並記錄下來，若是沒有監控，有可能用戶的由於某些緣由出錯或者性能問題形成體驗很是的差，而咱們並無感知，這裏麪包括了，監控用戶端的使用性能，返回碼，在哪些城市地區他們的使用狀況是怎麼樣，還有運營商的狀況，包括電信，聯通用戶的鏈接狀況。咱們須要進一步去知道是否有哪些渠道哪些用戶接入的時候存在着問題，包括咱們還須要知道客戶端使用的操做系統瀏覽器的版本。

簡單來講，這個就是咱們成體系化的監控分層，每個層次都很是的重要，通常狀況下，一個問題發現的狀況下，比較大機率會先暴露在用戶端或業務層，好比來講，咱們的訂單量降低了，業務人員和開發人員會先從上到下去逐層檢查是在哪個層出現了問題，先肯定是否哪一個接口調用比較慢，哪一個服務調用出現延時，再看是否哪一個機器負載太高了，而後再進一步往下一個層去看，是不是網絡調用不穩定致使。因此一個好的監控體系，在每個層次都很是的重要。

剛說的是從層級方面去進行監控，下面繼續來看下，哪一些要點能夠進行監控

五個點：

1. 日誌監控
2. Metrics監控
3. 調用鏈監控
4. 報警系統
5. 健康檢查

典型主流的監控架構

在微服務運行的體系下，咱們通常把監控的agent分散到各個服務身邊，agent分別是收集機器和服務的metrics，發送到後臺監控系統，通常來講，咱們的服務量很是大，在收集的過程當中，會加入隊列，通常來講用kafka，用消息隊列有個好處就是兩邊能夠進行解耦，還好就是能夠起到龐大的日誌進行一個緩存的地帶，並在mq能夠作到高可用，保證消息不會丟失。

日誌收集目前比較流行的是ELK的一套解決方案，（Elasticsearch，Logstash，Kibana），Elasticsearch 分佈式搜索引擎，Logstash 是一個日誌收集的agent，Kibana 是一個查詢的日誌界面。

metrice會採用一個時間序列的數據庫，influxDB是最近比較主流時間數據庫。

微服務的agent例如springboot也提供了健康檢查的端點，能夠檢查cpu使用狀況，內存使用狀況，jvm使用狀況，這些須要一個健康檢查機制，可以按期對服務的健康和機器的健康進行check，比較常見的是nagios,zabbix等，這些開源平臺可以按期去檢查到各個微服務的檢查程序並可以進行告警給相關人員，在服務未奔潰以前就能夠進行提早的預先接入。

博客地址：「微服務系列 11」微服務系統監控分層