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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2） 易于部署和運維。Prometheus核心只有一個二進制文件，沒有其他的第三方依賴，部署運維均十分方便。

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

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

5）強大的查詢語言PromQL。通過PromQL可以實現(xiàn)對監(jiān)控數(shù)據(jù)的查詢、聚合、可視化、告警。

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

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

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

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

1、愛奇藝號業(yè)務特點

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

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

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

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

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

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

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

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

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

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

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

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

對于應用服務和第三方接口監(jiān)控，我們常用的指標包括：響應時間、請求量QPS、成功率。

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

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

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

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

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

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

2）應用服務監(jiān)控

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

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

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

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

① 顯式主動采集

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

② 隱式組件采集

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

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

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

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

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

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

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

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

不過，我們最終并沒有采用Consul，主要原因有兩點：

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

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

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

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

5、統(tǒng)一報警

Prometheus允許基于PromQL定義報警的觸發(fā)條件，Prometheus周期性的對PromQL進行計算，當滿足條件時就會向Alertmanager發(fā)送報警信息。

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

下圖是一個報警規(guī)則示例：

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

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

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

寫在最后

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

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