來(lái)源：掘金

juejin.cn/post/6844903846192349191#heading-6

-     前言     -

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

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

1、五個(gè)層級(jí)的監(jiān)控

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

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

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

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

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

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

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

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

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

6、端用戶(hù)體驗(yàn)監(jiān)控

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

這些信息都需要進(jìn)行監(jiān)控并記錄下來(lái)，如果沒(méi)有監(jiān)控，有可能因?yàn)槟承〣UG或者性能問(wèn)題，造成用戶(hù)體驗(yàn)非常差，而我們并沒(méi)有感知。

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

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

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

1、五個(gè)監(jiān)控要點(diǎn)

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

簡(jiǎn)單來(lái)說(shuō)，可以分為以下五個(gè)點(diǎn)：

1、日志監(jiān)控

2、Metrics監(jiān)控

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

4、報(bào)警系統(tǒng)

5、健康檢查

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

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

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

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

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