微服務(wù)架構(gòu)是目前各大互聯(lián)網(wǎng)公司普遍采用的軟件架構(gòu)方式。在微服務(wù)架構(gòu)中，系統(tǒng)被拆分為多個(gè)小的、相互獨(dú)立的服務(wù)，這些服務(wù)運(yùn)行在自己的進(jìn)程中，可以獨(dú)立的開(kāi)發(fā)和部署。在業(yè)務(wù)快速變化時(shí)，微服務(wù)單一職責(zé)、自治的特點(diǎn)，使系統(tǒng)的邊界更加清晰，提升了系統(tǒng)的可維護(hù)性；同時(shí)，簡(jiǎn)化了系統(tǒng)部署的復(fù)雜度，可以針對(duì)某個(gè)微服務(wù)單獨(dú)升級(jí)和發(fā)布；在業(yè)務(wù)增長(zhǎng)時(shí)，也可以方便的進(jìn)行獨(dú)立擴(kuò)展。

微服務(wù)架構(gòu)雖然帶來(lái)了很多好處，但也帶來(lái)了新的問(wèn)題。在以往的單體應(yīng)用中，排查問(wèn)題往往通過(guò)查看日志定位錯(cuò)誤信息和異常堆棧；但是在微服務(wù)架構(gòu)中服務(wù)繁多，出現(xiàn)問(wèn)題時(shí)的問(wèn)題定位變得非常困難。另外，微服務(wù)往往通過(guò)組合已有的服務(wù)來(lái)創(chuàng)建新服務(wù)，一個(gè)服務(wù)的故障很可能會(huì)產(chǎn)生雪崩效應(yīng)，導(dǎo)致整個(gè)系統(tǒng)的不可用。因此，如何監(jiān)控微服務(wù)的運(yùn)行狀況、當(dāng)出現(xiàn)異常時(shí)能快速給出報(bào)警，這給開(kāi)發(fā)人員帶來(lái)很大挑戰(zhàn)。

本文將介紹我們基于Prometheus搭建微服務(wù)監(jiān)控系統(tǒng)的一些實(shí)踐經(jīng)驗(yàn)，及愛(ài)奇藝號(hào)在微服務(wù)監(jiān)控方面的一些探索和實(shí)踐，從愛(ài)奇藝號(hào)的業(yè)務(wù)特點(diǎn)出發(fā)，結(jié)合現(xiàn)有的開(kāi)發(fā)運(yùn)維技術(shù)棧確定監(jiān)控的對(duì)象和指標(biāo)，并有針對(duì)性地自研了一些關(guān)鍵組件和服務(wù)，實(shí)現(xiàn)服務(wù)的全面監(jiān)控和統(tǒng)一報(bào)警。

一、監(jiān)控系統(tǒng)簡(jiǎn)介

1、監(jiān)控的幾種主要方式

監(jiān)控的幾種主要方式

在微服務(wù)架構(gòu)中，不同維度有不同的監(jiān)控方式。

1）健康檢查。健康檢查是對(duì)應(yīng)用本身健康狀況的監(jiān)控，檢查服務(wù)是否還正常存活。

2）日志。日志是排查問(wèn)題的主要方式，日志可以提供豐富的信息用于定位和解決問(wèn)題。

3）調(diào)用鏈監(jiān)控。調(diào)用鏈監(jiān)控可以完整的呈現(xiàn)出一次請(qǐng)求的全部信息，包括服務(wù)調(diào)用鏈路、所耗時(shí)間等。

4）指標(biāo)監(jiān)控。指標(biāo)是一些基于時(shí)間序列的離散數(shù)據(jù)點(diǎn)，通過(guò)聚合和計(jì)算后能反映出一些重要指標(biāo)的趨勢(shì)。

在上述4中監(jiān)控方式中，健康檢查是云平臺(tái)等基礎(chǔ)設(shè)施提供的能力，日志則一般有單獨(dú)的日志中心進(jìn)行日志的采集、存儲(chǔ)、計(jì)算和查詢，調(diào)用鏈監(jiān)控一般也有獨(dú)立的解決方案進(jìn)行服務(wù)調(diào)用的埋點(diǎn)、采集、計(jì)算和查詢，本文主要討論第4種監(jiān)控方式。

2、微服務(wù)監(jiān)控的技術(shù)選型

監(jiān)控的幾種主要方式

由于微服務(wù)架構(gòu)自身的特點(diǎn)，使得傳統(tǒng)的一些監(jiān)控方案不再適用。在傳統(tǒng)應(yīng)用監(jiān)控中，Zabbix是最常用的監(jiān)控方案。Zabbix的優(yōu)點(diǎn)在于成熟可靠、強(qiáng)大的社區(qū)支持、多年積累的經(jīng)驗(yàn)和方案。但Zabbix的缺點(diǎn)也很明顯，首先是使用難度高、學(xué)習(xí)曲線陡峭；其次，Zabbix的監(jiān)控維度是主機(jī)，無(wú)法適用于微服務(wù)的云原生環(huán)境。

經(jīng)過(guò)調(diào)研，我們最終采用了Prometheus。選擇Prometheus的主要原因：

1） 成熟的社區(qū)支撐。Prometheus是一個(gè)開(kāi)源的監(jiān)控軟件，擁有活躍的社區(qū)，能夠很好地與云原生環(huán)境搭配。

2） 易于部署和運(yùn)維。Prometheus核心只有一個(gè)二進(jìn)制文件，沒(méi)有其他的第三方依賴，部署運(yùn)維均十分方便。

3）采用Pull模型，通過(guò)HTTP的Pull方式從各個(gè)監(jiān)控目標(biāo)拉取監(jiān)控?cái)?shù)據(jù)。Push模型一般通過(guò)Agent方式去采集信息并推送到收集器中，每個(gè)服務(wù)的Agent都需要配置監(jiān)控?cái)?shù)據(jù)項(xiàng)與監(jiān)控服務(wù)端的信息，在大量服務(wù)時(shí)會(huì)加大運(yùn)維難度；另外，采用Push模型，在流量高峰期間監(jiān)控服務(wù)端會(huì)同時(shí)接收到大量請(qǐng)求和數(shù)據(jù)，會(huì)給監(jiān)控服務(wù)端造成很大壓力，嚴(yán)重時(shí)甚至服務(wù)不可用。

4）強(qiáng)大的數(shù)據(jù)模型。Prometheus采集到的監(jiān)控?cái)?shù)據(jù)均以指標(biāo)的形式存在于內(nèi)置的時(shí)序數(shù)據(jù)庫(kù)中，除了基本的指標(biāo)名稱外，還支持自定義的標(biāo)簽。通過(guò)標(biāo)簽可以定義出豐富的維度，方便進(jìn)行監(jiān)控?cái)?shù)據(jù)的聚合和計(jì)算。

5）強(qiáng)大的查詢語(yǔ)言PromQL。通過(guò)PromQL可以實(shí)現(xiàn)對(duì)監(jiān)控?cái)?shù)據(jù)的查詢、聚合、可視化、告警。

6）完善的生態(tài)。常見(jiàn)的操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件、類庫(kù)、編程語(yǔ)言，Prometheus都提供了接入方案，并且提供了Java/Golang/Ruby/Python等語(yǔ)言的客戶端SDK，能夠快速實(shí)現(xiàn)自定義的監(jiān)控邏輯。

7）高性能。Prometheus單一實(shí)例即可處理數(shù)以百計(jì)的監(jiān)控指標(biāo)，每秒處理數(shù)十萬(wàn)的數(shù)據(jù)，在數(shù)據(jù)采集和查詢方面有著優(yōu)異的性能表現(xiàn)。

由于采集的數(shù)據(jù)有可能丟失，Prometheus并不適合對(duì)采集數(shù)據(jù)要求100%準(zhǔn)確的場(chǎng)景。實(shí)際上，對(duì)于監(jiān)控系統(tǒng)的場(chǎng)景，偶爾的數(shù)據(jù)丟失完全可以接受。

二、基于Prometheus的微服務(wù)監(jiān)控方案

1、愛(ài)奇藝號(hào)業(yè)務(wù)特點(diǎn)

愛(ài)奇藝號(hào)是愛(ài)奇藝專注視頻內(nèi)容的創(chuàng)作、分發(fā)和變現(xiàn)的平臺(tái)，承載了自媒體、網(wǎng)大、網(wǎng)劇、兒童、動(dòng)漫、知識(shí)、網(wǎng)絡(luò)綜藝、紀(jì)錄片、文學(xué)、輕小說(shuō)、漫畫(huà)等內(nèi)容，是愛(ài)奇藝內(nèi)容生態(tài)的重要一環(huán)。

愛(ài)奇藝號(hào)整體采用微服務(wù)架構(gòu)，內(nèi)部依據(jù)功能、領(lǐng)域等角度劃分為不同的微服務(wù)，外部流量先經(jīng)DNS、QLB、前置機(jī)、網(wǎng)關(guān)等層完成統(tǒng)一鑒權(quán)、負(fù)載均衡、限流等操作后路由到系統(tǒng)內(nèi)部不同的微服務(wù)實(shí)例。系統(tǒng)內(nèi)部微服務(wù)除專有的MySQL、Redis、MQ等資源外，共享服務(wù)注冊(cè)/發(fā)現(xiàn)、配置中心等服務(wù)治理能力。

系統(tǒng)整體架構(gòu)，如下圖所示：

愛(ài)奇藝號(hào)服務(wù)于內(nèi)容創(chuàng)作者，服務(wù)質(zhì)量直接決定了創(chuàng)作者的使用體驗(yàn)，影響內(nèi)容創(chuàng)作的熱情，進(jìn)而影響內(nèi)容生態(tài)的健康，因此對(duì)服務(wù)質(zhì)量有很高要求。同時(shí)，愛(ài)奇藝號(hào)作為前臺(tái)業(yè)務(wù)，依賴公司許多的內(nèi)部服務(wù)和中臺(tái)服務(wù)，服務(wù)的穩(wěn)定性直接影響了自身服務(wù)的質(zhì)量。

基于愛(ài)奇藝號(hào)的業(yè)務(wù)特點(diǎn)，在搭建微服務(wù)監(jiān)控系統(tǒng)時(shí)，重點(diǎn)關(guān)注自身服務(wù)接口和第三方服務(wù)接口的監(jiān)控。

2、 微服務(wù)監(jiān)控系統(tǒng)概述

我們基于Prometheus搭建了適合自身業(yè)務(wù)特點(diǎn)的微服務(wù)監(jiān)控系統(tǒng)。Prometheus已提供非常豐富的組件，同時(shí)我們也開(kāi)發(fā)了部分組件，滿足我們的監(jiān)控需求。

微服務(wù)監(jiān)控系統(tǒng)的整體結(jié)構(gòu)，如下圖所示：

•  使用Spring Boot Actuator和Micrometer采集服務(wù)的監(jiān)控?cái)?shù)據(jù)，并暴露給Prometheus拉取；
•  開(kāi)發(fā)了第三方服務(wù)接口的監(jiān)控?cái)?shù)據(jù)采集工具；
•  開(kāi)發(fā)了qae-monitor組件，采集服務(wù)運(yùn)行時(shí)容器的監(jiān)控?cái)?shù)據(jù)；
•  開(kāi)發(fā)了基于文件的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)，給Prometheus提供拉取目標(biāo)；
•  開(kāi)發(fā)了Alert proxy服務(wù)，實(shí)現(xiàn)了報(bào)警內(nèi)容投遞到統(tǒng)一報(bào)警平臺(tái)；
•  使用Prometheus聯(lián)邦集群模式部署，并使用Grafana用于監(jiān)控?cái)?shù)據(jù)展示。

3、服務(wù)的全面監(jiān)控

監(jiān)控系統(tǒng)一般采用分層的方式劃分監(jiān)控對(duì)象。在我們的監(jiān)控系統(tǒng)中，主要關(guān)注以下幾種類型的監(jiān)控對(duì)象：

•  容器環(huán)境監(jiān)控，主要指服務(wù)所處運(yùn)行環(huán)境的一些監(jiān)控?cái)?shù)據(jù)；
•  應(yīng)用服務(wù)監(jiān)控，主要指服務(wù)本身的基礎(chǔ)數(shù)據(jù)指標(biāo)，提現(xiàn)服務(wù)自身的運(yùn)行狀況；
•  第三方接口監(jiān)控，主要指調(diào)用其他外部服務(wù)接口的情況。

對(duì)于應(yīng)用服務(wù)和第三方接口監(jiān)控，我們常用的指標(biāo)包括：響應(yīng)時(shí)間、請(qǐng)求量QPS、成功率。

1）容器環(huán)境監(jiān)控

微服務(wù)應(yīng)用部署在愛(ài)奇藝內(nèi)部的應(yīng)用云平臺(tái)（QAE）上。在云平臺(tái)中，一臺(tái)主機(jī)上會(huì)同時(shí)存在多個(gè)容器實(shí)例，采用主機(jī)監(jiān)控的方式采集到的資源使用和性能特征實(shí)際上是主機(jī)的指標(biāo)數(shù)據(jù)，而非運(yùn)行的容器。

Prometheus雖然支持使用cAdvisor進(jìn)行容器監(jiān)控，但cAdvisor需要安裝在主機(jī)上，而QAE是一個(gè)公共平臺(tái)，自行安裝部署其他軟件并不現(xiàn)實(shí)。好在QAE提供了開(kāi)放的API，很好的解決了這一問(wèn)題。

QAE平臺(tái)自身內(nèi)建了監(jiān)控功能，包括容器級(jí)和應(yīng)用級(jí)兩個(gè)層級(jí)，除了可以在QAE平臺(tái)通過(guò)頁(yè)面查看，也支持通過(guò)HTTP接口暴露出監(jiān)控?cái)?shù)據(jù)，這就為我們進(jìn)行統(tǒng)一的監(jiān)控?cái)?shù)據(jù)采集提供了可能。

我們開(kāi)發(fā)了一個(gè)QAE容器監(jiān)控?cái)?shù)據(jù)采集的服務(wù)，qae-monitor。qae-monitor服務(wù)通過(guò)自定義Prometheus Collector的方式，實(shí)現(xiàn)對(duì)QAE監(jiān)控?cái)?shù)據(jù)的收集。服務(wù)定時(shí)調(diào)用QAE平臺(tái)的HTTP接口抓取容器監(jiān)控?cái)?shù)據(jù)，并整理成Prometheus的數(shù)據(jù)格式。

qae-monitor本身也通過(guò)Micrometer向外暴露監(jiān)控?cái)?shù)據(jù)采集端點(diǎn)，Prometheus通過(guò)該端點(diǎn)抓取采集到的監(jiān)控?cái)?shù)據(jù)。

2）應(yīng)用服務(wù)監(jiān)控

基礎(chǔ)監(jiān)控?cái)?shù)據(jù)主要是指應(yīng)用服務(wù)實(shí)例的運(yùn)行時(shí)狀態(tài)、資源使用情況等度量指標(biāo)。Micrometer默認(rèn)提供了非常豐富的應(yīng)用度量指標(biāo)，只要接入了Micrometer就可以直接采集到這些數(shù)據(jù)，主要包括：

•  系統(tǒng)信息，包括運(yùn)行時(shí)間、CPU使用率、系統(tǒng)負(fù)載等；
•  內(nèi)存使用情況，包括堆內(nèi)存使用情況和非堆內(nèi)存使用情況；
•  線程使用情況，包括線程數(shù)、守護(hù)線程數(shù)、線程峰值等；
•  類加載信息；
•  GC信息，包括GC次數(shù)、GC消耗時(shí)間等；
•  HTTP請(qǐng)求情況，描述HTTP請(qǐng)求的性能指標(biāo)，是非常重要的監(jiān)控指標(biāo)，在統(tǒng)計(jì)HTTP服務(wù)的QPS、響應(yīng)時(shí)間和成功率時(shí)必不可少。

3）第三方接口監(jiān)控

微服務(wù)架構(gòu)中，可以通過(guò)調(diào)用和組合已有服務(wù)的方式創(chuàng)建新服務(wù)，第三方接口會(huì)直接影響到自身服務(wù)，因此第三方服務(wù)接口的調(diào)用情況同樣值得關(guān)注。在如何采集第三方服務(wù)接口的監(jiān)控?cái)?shù)據(jù)上，主要有兩種方案：

① 顯式主動(dòng)采集

在發(fā)生第三方接口調(diào)用的地方，主動(dòng)進(jìn)行監(jiān)控?cái)?shù)據(jù)的采集?；蛘咧苯佑簿幋a，或者用注解、切面的形式，優(yōu)點(diǎn)是方案簡(jiǎn)單，缺點(diǎn)是會(huì)對(duì)已有的業(yè)務(wù)代碼造成侵入。

② 隱式組件采集

在使用的HTTP/RPC組件中增加埋點(diǎn)采集的邏輯，優(yōu)點(diǎn)是業(yè)務(wù)代碼不需修改，缺點(diǎn)是HTTP/RPC組件需要擴(kuò)展和升級(jí)。

我們最終選擇了第二種方案，主要原因是：

•  首先我們的技術(shù)方案比較統(tǒng)一，都采用HTTP協(xié)議進(jìn)行服務(wù)調(diào)用，且使用的HTTP客戶端組件（fluent-hc）也是基于Okhttp3進(jìn)行的二次封裝，方便統(tǒng)一修改；
•  其次，Micrometer支持通過(guò)SDK的方式自定義監(jiān)控指標(biāo)數(shù)據(jù)的采集，也提供了眾多常用的組件埋點(diǎn)方案，Okhttp3即是其中之一，進(jìn)一步簡(jiǎn)化了第三方接口的監(jiān)控?cái)?shù)據(jù)采集難度。

具體而言，Micrometer提供了OkHttpMetricsEventListener組件，用于收集Okhttp的監(jiān)控?cái)?shù)據(jù)。我們只需要在構(gòu)建Okhttp實(shí)例的時(shí)候傳入OkHttpMetricsEventListener實(shí)例即可；也可以傳入一個(gè)EventListener.Factory實(shí)例，在工廠的創(chuàng)建方法中返回OkHttpMetricsEventListener實(shí)例。Okhttp在3.11.0的版本中才正式加入了EventListener功能，使用時(shí)需要注意Okhttp的版本。

通過(guò)第三方接口監(jiān)控的維度，我們可以方便地將自身服務(wù)與所使用到的第三方服務(wù)關(guān)聯(lián)起來(lái)，以統(tǒng)一的視圖展示服務(wù)用到了哪些第三方服務(wù)接口、這些第三方服務(wù)接口的響應(yīng)時(shí)間和成功率是多少。當(dāng)服務(wù)出現(xiàn)異常時(shí)，對(duì)于定位問(wèn)題有很大幫助；同時(shí)，一些內(nèi)部的服務(wù)可能監(jiān)控報(bào)警并不全面，第三方監(jiān)控也能幫助他們提升服務(wù)質(zhì)量。

4、基于文件的服務(wù)發(fā)現(xiàn)

Prometheus采用的Pull模型需要知道哪些是被監(jiān)控的目標(biāo)對(duì)象。在Prometheus中配置監(jiān)控目標(biāo)分為靜態(tài)和動(dòng)態(tài)兩種，常用的包括靜態(tài)文件配置、文件服務(wù)發(fā)現(xiàn)、Consul服務(wù)發(fā)現(xiàn)等。此外，Prometheus還支持DNS、微軟Azure、亞馬遜EC2、谷歌GCE、Kubernetes等多種服務(wù)發(fā)現(xiàn)方式。

靜態(tài)配置的方式最為簡(jiǎn)單，但在實(shí)際生產(chǎn)環(huán)境中并不可取。容器每時(shí)每刻都可能進(jìn)行著創(chuàng)建和銷毀，不可能通過(guò)靜態(tài)配置方式設(shè)置監(jiān)控目標(biāo)。我們最開(kāi)始選擇了Consul的服務(wù)發(fā)現(xiàn)，它引入了集中的注冊(cè)中心，微服務(wù)啟動(dòng)時(shí)向注冊(cè)中心注冊(cè)服務(wù)實(shí)例，Prometheus便可以從注冊(cè)中心查詢到服務(wù)實(shí)例作為監(jiān)控目標(biāo)。

不過(guò)，我們最終并沒(méi)有采用Consul，主要原因有兩點(diǎn)：

•  一是微服務(wù)接入Consul需要涉及代碼改動(dòng)，雖然改動(dòng)不大，但大量服務(wù)的接入仍有不小的成本；
•  二是還需要再單獨(dú)部署和維護(hù)一套Consul環(huán)境，帶來(lái)新的維護(hù)成本。

Prometheus服務(wù)發(fā)現(xiàn)的原理很簡(jiǎn)單，通過(guò)第三方提供的接口，Prometheus查詢到需要監(jiān)控的目標(biāo)列表，然后輪訓(xùn)監(jiān)控目標(biāo)獲取監(jiān)控?cái)?shù)據(jù)。由于QAE是私有云平臺(tái)，Prometheus無(wú)法直接提供支持，但基于以上原理，我們可以實(shí)現(xiàn)類似的服務(wù)發(fā)現(xiàn)機(jī)制。

我們開(kāi)發(fā)了基于文件的服務(wù)發(fā)現(xiàn)prom-sd-qae。prom-sd-qae是一個(gè)獨(dú)立程序，部署在Prometheus服務(wù)所在的機(jī)器。它定時(shí)通過(guò)QAE平臺(tái)的HTTP接口抓取容器服務(wù)列表，按Prometheus要求的格式在本地磁盤(pán)生成JSON或YAML文件，其中定義了所有的監(jiān)控目標(biāo)列表。Prometheus定時(shí)從文件中讀取最新的監(jiān)控目標(biāo)，并從中拉取監(jiān)控?cái)?shù)據(jù)。

這一方案在兩次刷新監(jiān)控目標(biāo)之間，可能會(huì)發(fā)生監(jiān)控目標(biāo)的銷毀和創(chuàng)建，此時(shí)存在短暫的過(guò)期監(jiān)控目標(biāo)；不過(guò)，該方案兼顧了服務(wù)發(fā)現(xiàn)的動(dòng)態(tài)性與簡(jiǎn)便性，依然不失為一種簡(jiǎn)單有效的選擇。

5、統(tǒng)一報(bào)警

Prometheus允許基于PromQL定義報(bào)警的觸發(fā)條件，Prometheus周期性的對(duì)PromQL進(jìn)行計(jì)算，當(dāng)滿足條件時(shí)就會(huì)向Alertmanager發(fā)送報(bào)警信息。

在配置報(bào)警規(guī)則時(shí)，我們將每個(gè)服務(wù)的報(bào)警規(guī)則定義在一個(gè)group下，每個(gè)group定義了多條報(bào)警規(guī)則，包括：響應(yīng)時(shí)間報(bào)警、接口成功率報(bào)警、QPS報(bào)警、第三方接口報(bào)警等。這樣的好處是以服務(wù)為維度將報(bào)警規(guī)則聚合在一起，查看和配置時(shí)更方便；另外，同一個(gè)報(bào)警規(guī)則下不同服務(wù)的報(bào)警閾值可能不同，這樣也可以獨(dú)立配置。

下圖是一個(gè)報(bào)警規(guī)則示例：

Alertmanager在接收到報(bào)警后，可以對(duì)報(bào)警進(jìn)行分組、抑制、靜默等額外處理，然后路由到不同的接收器。Alertmanager支持多種報(bào)警通知方式，除常用的郵件通知外，還支持釘釘、企業(yè)微信等方式，也支持通過(guò)webhook自定義通知方式。

愛(ài)奇藝的統(tǒng)一報(bào)警平臺(tái)實(shí)現(xiàn)了報(bào)警話題、報(bào)警內(nèi)容、報(bào)警渠道、報(bào)警訂閱的統(tǒng)一處理，我們充分利用了統(tǒng)一報(bào)警平臺(tái)，開(kāi)發(fā)了Alert-proxy報(bào)警代理服務(wù)。Alertmanager通過(guò)webhook方式將報(bào)警發(fā)送到Alert-proxy，Alert-proxy再投遞到統(tǒng)一報(bào)警平臺(tái)，最終發(fā)送到最終熱聊、郵件、短信等接收端。Alert-proxy會(huì)將報(bào)警投遞到統(tǒng)一報(bào)警平臺(tái)一個(gè)默認(rèn)的報(bào)警話題Topic，也支持投遞到其他的Topic上?？梢詾椴煌?wù)、不同報(bào)警級(jí)別單獨(dú)設(shè)置Topic，實(shí)現(xiàn)更精確的通知觸達(dá)和聚焦。

報(bào)警涵蓋了服務(wù)HTTP接口、第三方HTTP接口，也包括了JVM和容器的狀態(tài)，目前已基本滿足需求。

寫(xiě)在最后

監(jiān)控是一個(gè)老生常談但又常談常新的話題，與業(yè)務(wù)特點(diǎn)、技術(shù)棧、方案選型有很大關(guān)聯(lián)，看待問(wèn)題的角度不同最終的方案也不盡相同，到底什么樣的方式是最合適的，這都是仁者見(jiàn)仁、智者見(jiàn)智，只有適合自己的才是最好的。

本文是現(xiàn)階段微服務(wù)監(jiān)控的一些實(shí)踐總結(jié)，隨著業(yè)務(wù)和技術(shù)的不斷發(fā)展，未來(lái)還有許多方面需要不斷地探索和改進(jìn)，例如報(bào)警規(guī)則優(yōu)化、自動(dòng)化報(bào)表、系統(tǒng)智能化監(jiān)控等，使監(jiān)控更加全面、強(qiáng)大和智能，進(jìn)一步提升服務(wù)質(zhì)量和穩(wěn)定性，助力業(yè)務(wù)快速發(fā)展。