來源：掘金

juejin.cn/post/6844903846192349191#heading-6

-     前言     -

“監(jiān)控”是微服務(wù)治理的一個重要環(huán)節(jié)，監(jiān)控系統(tǒng)的完善程度直接影響到我們微服務(wù)質(zhì)量的好壞，我們的微服務(wù)在線上運行時，有沒有一套完善的監(jiān)控體系能去了解到它的健康情況，這對整個系統(tǒng)的可靠性和穩(wěn)定性非常重要。

- 微服務(wù)監(jiān)控體系的層級架構(gòu) -

1、五個層級的監(jiān)控

一個比較完善的微服務(wù)監(jiān)控體系需要涉及到哪些層級？如下圖所示，大致可以劃分為五個層級的監(jiān)控：

2、最底層基礎(chǔ)設(shè)施監(jiān)控

這層一般由運維人員負(fù)責(zé)，涉及到的方面比較接近硬件體系，例如網(wǎng)絡(luò)，交換機(jī)，路由器等低層設(shè)備，這些設(shè)備的可靠性穩(wěn)定性就直接影響到上層服務(wù)應(yīng)用的穩(wěn)定性，所以需要對網(wǎng)絡(luò)的流量，丟包情況、錯包情況，連接數(shù)等等這些基礎(chǔ)設(shè)施的核心指標(biāo)進(jìn)行監(jiān)控。

3、系統(tǒng)層監(jiān)控

這層涵蓋了物理機(jī)、虛擬機(jī)、操作系統(tǒng)等，這些都是屬于系統(tǒng)級別監(jiān)控的方面，主要對幾個核心指標(biāo)進(jìn)行監(jiān)控，如cpu使用率、內(nèi)存占用率，磁盤IO和網(wǎng)絡(luò)帶寬情況。

4、應(yīng)用層監(jiān)控

這層涉及到方面和服務(wù)緊密相關(guān)，例如對url訪問的性能，訪問的調(diào)用數(shù)，訪問的延遲，還有對服務(wù)提供性能進(jìn)行監(jiān)控，服務(wù)的錯誤率等，同時對sql也需要進(jìn)行監(jiān)控，查看是否有慢sql。對于cache來說，需要監(jiān)控緩存的命中率和性能，每個服務(wù)的響應(yīng)時間和qps等等。

5、業(yè)務(wù)監(jiān)控

業(yè)務(wù)監(jiān)控具體指什么？舉個例子，比如說一個典型的交易網(wǎng)站，需要關(guān)注它的用戶登錄情況、注冊情況、下單情況、支付情況等等，這些直接影響到實際觸發(fā)的業(yè)務(wù)交易情況，這層監(jiān)控可以提供給運營和公司高管們，提供他們需要關(guān)注的數(shù)據(jù)，直接以數(shù)據(jù)支撐公司在戰(zhàn)略層面的決策和方向。

6、端用戶體驗監(jiān)控

一個應(yīng)用程序可能通過app、h5、pc端的方式交付到用戶的手上，用戶通過瀏覽器，客戶端打開連到我們的服務(wù)，那么在用戶端，用戶的體驗是怎么樣？用戶端的性能是怎么樣？以及有沒有產(chǎn)生錯誤等等……

這些信息都需要進(jìn)行監(jiān)控并記錄下來，如果沒有監(jiān)控，有可能因為某些BUG或者性能問題，造成用戶體驗非常差，而我們并沒有感知。

其中包括監(jiān)控用戶端的使用性能、返回碼，在哪些城市地區(qū)，他們的使用情況是怎么樣，還有運營商的情況，包括三大運營商不同用戶的連接情況。我們需要進(jìn)一步知道，是否有哪些渠道哪些用戶接入的時候存在著問題，我們還需要知道客戶端使用的操作系統(tǒng)瀏覽器的版本。

簡單來說，這就是我們體系化的監(jiān)控分層，每一個層級都非常重要。一般情況下，當(dāng)一個問題出現(xiàn)時，較大概率會先暴露在用戶端或業(yè)務(wù)層，比如說，我們的訂單量下降了，業(yè)務(wù)人員和開發(fā)人員會先從上到下去逐層檢查是在哪里出現(xiàn)了問題，先確定是否哪個接口調(diào)用比較慢，哪個服務(wù)調(diào)用出現(xiàn)延時，再看是否哪個機(jī)器負(fù)載過高了，然后再進(jìn)一步往下一個層去看，是否是網(wǎng)絡(luò)調(diào)用不穩(wěn)定導(dǎo)致。所以，一個好的監(jiān)控體系，在每個層級都非常重要。

- 微服務(wù)監(jiān)控的要點 -

1、五個監(jiān)控要點

上文講解的是從層級方面進(jìn)行監(jiān)控，接下來，我們來看看哪些要點可以進(jìn)行監(jiān)控：

簡單來說，可以分為以下五個點：

1、日志監(jiān)控

2、Metrics監(jiān)控

3、調(diào)用鏈監(jiān)控

4、報警系統(tǒng)

5、健康檢查

2、典型主流的監(jiān)控架構(gòu)

在微服務(wù)運行的體系下，我們一般把監(jiān)控的agent分散到各個服務(wù)身邊，agent分別是收集機(jī)器和服務(wù)的metrics，發(fā)送到后臺監(jiān)控系統(tǒng)，一般來說，我們的服務(wù)量非常大，在收集的過程中，會加入隊列。一般來說用kafka等消息隊列有個好處，兩邊可以進(jìn)行解耦，可以起到龐大的日志進(jìn)行一個緩存的地帶，并且可以做到高可用，保證消息不會丟失。

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

metrice會采用一個時間序列的數(shù)據(jù)庫，influxDB是最近比較主流時間數(shù)據(jù)庫。

微服務(wù)的agent例如springboot也提供了健康檢查的端點，可以檢查cpu使用情況、內(nèi)存使用情況、jvm使用情況，這些需要一個健康檢查機(jī)制，能夠定期對服務(wù)的健康和機(jī)器的健康進(jìn)行check，比較常見的是nagios、zabbix等，這些開源平臺能夠定期去檢查到各個微服務(wù)的檢查程序并能夠進(jìn)行告警給相關(guān)人員，在服務(wù)未崩潰之前就可以進(jìn)行提前的預(yù)先接入。