建站
咨詢
售后
建站咨詢
新聞中心
微服務(wù)架構(gòu)是目前各大互聯(lián)網(wǎng)公司普遍采用的軟件架構(gòu)方式。在微服務(wù)架構(gòu)中，系統(tǒng)被拆分為多個小的、相互獨立的服務(wù)，這些服務(wù)運行在自己的進(jìn)程中，可以獨立的開發(fā)和部署。在業(yè)務(wù)快速變化時，微服務(wù)單一職責(zé)、自治的特點，使系統(tǒng)的邊界更加清晰，提升了系統(tǒng)的可維護(hù)性；同時，簡化了系統(tǒng)部署的復(fù)雜度，可以針對某個微服務(wù)單獨升級和發(fā)布；在業(yè)務(wù)增長時，也可以方便的進(jìn)行獨立擴(kuò)展。
微服務(wù)架構(gòu)雖然帶來了很多好處，但也帶來了新的問題。在以往的單體應(yīng)用中，排查問題往往通過查看日志定位錯誤信息和異常堆棧；但是在微服務(wù)架構(gòu)中服務(wù)繁多，出現(xiàn)問題時的問題定位變得非常困難。另外，微服務(wù)往往通過組合已有的服務(wù)來創(chuàng)建新服務(wù)，一個服務(wù)的故障很可能會產(chǎn)生雪崩效應(yīng)，導(dǎo)致整個系統(tǒng)的不可用。因此，如何監(jiān)控微服務(wù)的運行狀況、當(dāng)出現(xiàn)異常時能快速給出報警，這給開發(fā)人員帶來很大挑戰(zhàn)。
本文將介紹我們基于Prometheus搭建微服務(wù)監(jiān)控系統(tǒng)的一些實踐經(jīng)驗，及愛奇藝號在微服務(wù)監(jiān)控方面的一些探索和實踐，從愛奇藝號的業(yè)務(wù)特點出發(fā)，結(jié)合現(xiàn)有的開發(fā)運維技術(shù)棧確定監(jiān)控的對象和指標(biāo)，并有針對性地自研了一些關(guān)鍵組件和服務(wù)，實現(xiàn)服務(wù)的全面監(jiān)控和統(tǒng)一報警。
一、監(jiān)控系統(tǒng)簡介
1、監(jiān)控的幾種主要方式
監(jiān)控的幾種主要方式
在微服務(wù)架構(gòu)中，不同維度有不同的監(jiān)控方式。
1）健康檢查。健康檢查是對應(yīng)用本身健康狀況的監(jiān)控，檢查服務(wù)是否還正常存活。
2）日志。日志是排查問題的主要方式，日志可以提供豐富的信息用于定位和解決問題。
3）調(diào)用鏈監(jiān)控。調(diào)用鏈監(jiān)控可以完整的呈現(xiàn)出一次請求的全部信息，包括服務(wù)調(diào)用鏈路、所耗時間等。
4）指標(biāo)監(jiān)控。指標(biāo)是一些基于時間序列的離散數(shù)據(jù)點，通過聚合和計算后能反映出一些重要指標(biāo)的趨勢。
在上述4中監(jiān)控方式中，健康檢查是云平臺等基礎(chǔ)設(shè)施提供的能力，日志則一般有單獨的日志中心進(jìn)行日志的采集、存儲、計算和查詢，調(diào)用鏈監(jiān)控一般也有獨立的解決方案進(jìn)行服務(wù)調(diào)用的埋點、采集、計算和查詢，本文主要討論第4種監(jiān)控方式。
2、微服務(wù)監(jiān)控的技術(shù)選型
監(jiān)控的幾種主要方式
由于微服務(wù)架構(gòu)自身的特點，使得傳統(tǒng)的一些監(jiān)控方案不再適用。在傳統(tǒng)應(yīng)用監(jiān)控中，Zabbix是最常用的監(jiān)控方案。Zabbix的優(yōu)點在于成熟可靠、強大的社區(qū)支持、多年積累的經(jīng)驗和方案。但Zabbix的缺點也很明顯，首先是使用難度高、學(xué)習(xí)曲線陡峭；其次，Zabbix的監(jiān)控維度是主機，無法適用于微服務(wù)的云原生環(huán)境。
經(jīng)過調(diào)研，我們最終采用了Prometheus。選擇Prometheus的主要原因：
1） 成熟的社區(qū)支撐。Prometheus是一個開源的監(jiān)控軟件，擁有活躍的社區(qū)，能夠很好地與云原生環(huán)境搭配。
2） 易于部署和運維。Prometheus核心只有一個二進(jìn)制文件，沒有其他的第三方依賴，部署運維均十分方便。
3）采用Pull模型，通過HTTP的Pull方式從各個監(jiān)控目標(biāo)拉取監(jiān)控數(shù)據(jù)。Push模型一般通過Agent方式去采集信息并推送到收集器中，每個服務(wù)的Agent都需要配置監(jiān)控數(shù)據(jù)項與監(jiān)控服務(wù)端的信息，在大量服務(wù)時會加大運維難度；另外，采用Push模型，在流量高峰期間監(jiān)控服務(wù)端會同時接收到大量請求和數(shù)據(jù)，會給監(jiān)控服務(wù)端造成很大壓力，嚴(yán)重時甚至服務(wù)不可用。
4）強大的數(shù)據(jù)模型。Prometheus采集到的監(jiān)控數(shù)據(jù)均以指標(biāo)的形式存在于內(nèi)置的時序數(shù)據(jù)庫中，除了基本的指標(biāo)名稱外，還支持自定義的標(biāo)簽。通過標(biāo)簽可以定義出豐富的維度，方便進(jìn)行監(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)控指標(biāo)，每秒處理數(shù)十萬的數(shù)據(jù)，在數(shù)據(jù)采集和查詢方面有著優(yōu)異的性能表現(xiàn)。
由于采集的數(shù)據(jù)有可能丟失，Prometheus并不適合對采集數(shù)據(jù)要求100%準(zhǔn)確的場景。實際上，對于監(jiān)控系統(tǒng)的場景，偶爾的數(shù)據(jù)丟失完全可以接受。
二、基于Prometheus的微服務(wù)監(jiān)控方案
1、愛奇藝號業(yè)務(wù)特點
愛奇藝號是愛奇藝專注視頻內(nèi)容的創(chuàng)作、分發(fā)和變現(xiàn)的平臺，承載了自媒體、網(wǎng)大、網(wǎng)劇、兒童、動漫、知識、網(wǎng)絡(luò)綜藝、紀(jì)錄片、文學(xué)、輕小說、漫畫等內(nèi)容，是愛奇藝內(nèi)容生態(tài)的重要一環(huán)。
愛奇藝號整體采用微服務(wù)架構(gòu)，內(nèi)部依據(jù)功能、領(lǐng)域等角度劃分為不同的微服務(wù)，外部流量先經(jīng)DNS、QLB、前置機、網(wǎng)關(guān)等層完成統(tǒng)一鑒權(quán)、負(fù)載均衡、限流等操作后路由到系統(tǒng)內(nèi)部不同的微服務(wù)實例。系統(tǒng)內(nèi)部微服務(wù)除專有的MySQL、Redis、MQ等資源外，共享服務(wù)注冊/發(fā)現(xiàn)、配置中心等服務(wù)治理能力。
系統(tǒng)整體架構(gòu)，如下圖所示：
愛奇藝號服務(wù)于內(nèi)容創(chuàng)作者，服務(wù)質(zhì)量直接決定了創(chuàng)作者的使用體驗，影響內(nèi)容創(chuàng)作的熱情，進(jìn)而影響內(nèi)容生態(tài)的健康，因此對服務(wù)質(zhì)量有很高要求。同時，愛奇藝號作為前臺業(yè)務(wù)，依賴公司許多的內(nèi)部服務(wù)和中臺服務(wù)，服務(wù)的穩(wěn)定性直接影響了自身服務(wù)的質(zhì)量。
基于愛奇藝號的業(yè)務(wù)特點，在搭建微服務(wù)監(jiān)控系統(tǒng)時，重點關(guān)注自身服務(wù)接口和第三方服務(wù)接口的監(jiān)控。
2、 微服務(wù)監(jiān)控系統(tǒng)概述
我們基于Prometheus搭建了適合自身業(yè)務(wù)特點的微服務(wù)監(jiān)控系統(tǒng)。Prometheus已提供非常豐富的組件，同時我們也開發(fā)了部分組件，滿足我們的監(jiān)控需求。
微服務(wù)監(jiān)控系統(tǒng)的整體結(jié)構(gòu)，如下圖所示：
- 使用Spring Boot Actuator和Micrometer采集服務(wù)的監(jiān)控數(shù)據(jù)，并暴露給Prometheus拉取；
- 開發(fā)了第三方服務(wù)接口的監(jiān)控數(shù)據(jù)采集工具；
- 開發(fā)了qae-monitor組件，采集服務(wù)運行時容器的監(jiān)控數(shù)據(jù)；
- 開發(fā)了基于文件的動態(tài)服務(wù)發(fā)現(xiàn)，給Prometheus提供拉取目標(biāo)；
- 開發(fā)了Alert proxy服務(wù)，實現(xiàn)了報警內(nèi)容投遞到統(tǒng)一報警平臺；
- 使用Prometheus聯(lián)邦集群模式部署，并使用Grafana用于監(jiān)控數(shù)據(jù)展示。
3、服務(wù)的全面監(jiān)控
監(jiān)控系統(tǒng)一般采用分層的方式劃分監(jiān)控對象。在我們的監(jiān)控系統(tǒng)中，主要關(guān)注以下幾種類型的監(jiān)控對象：
- 容器環(huán)境監(jiān)控，主要指服務(wù)所處運行環(huán)境的一些監(jiān)控數(shù)據(jù)；
- 應(yīng)用服務(wù)監(jiān)控，主要指服務(wù)本身的基礎(chǔ)數(shù)據(jù)指標(biāo)，提現(xiàn)服務(wù)自身的運行狀況；
- 第三方接口監(jiān)控，主要指調(diào)用其他外部服務(wù)接口的情況。
對于應(yīng)用服務(wù)和第三方接口監(jiān)控，我們常用的指標(biāo)包括：響應(yīng)時間、請求量QPS、成功率。
1）容器環(huán)境監(jiān)控
微服務(wù)應(yīng)用部署在愛奇藝內(nèi)部的應(yīng)用云平臺（QAE）上。在云平臺中，一臺主機上會同時存在多個容器實例，采用主機監(jiān)控的方式采集到的資源使用和性能特征實際上是主機的指標(biāo)數(shù)據(jù)，而非運行的容器。
Prometheus雖然支持使用cAdvisor進(jìn)行容器監(jiān)控，但cAdvisor需要安裝在主機上，而QAE是一個公共平臺，自行安裝部署其他軟件并不現(xiàn)實。好在QAE提供了開放的API，很好的解決了這一問題。
QAE平臺自身內(nèi)建了監(jiān)控功能，包括容器級和應(yīng)用級兩個層級，除了可以在QAE平臺通過頁面查看，也支持通過HTTP接口暴露出監(jiān)控數(shù)據(jù)，這就為我們進(jìn)行統(tǒng)一的監(jiān)控數(shù)據(jù)采集提供了可能。
我們開發(fā)了一個QAE容器監(jiān)控數(shù)據(jù)采集的服務(wù)，qae-monitor。qae-monitor服務(wù)通過自定義Prometheus Collector的方式，實現(xiàn)對QAE監(jiān)控數(shù)據(jù)的收集。服務(wù)定時調(diào)用QAE平臺的HTTP接口抓取容器監(jiān)控數(shù)據(jù)，并整理成Prometheus的數(shù)據(jù)格式。
qae-monitor本身也通過Micrometer向外暴露監(jiān)控數(shù)據(jù)采集端點，Prometheus通過該端點抓取采集到的監(jiān)控數(shù)據(jù)。
2）應(yīng)用服務(wù)監(jiān)控
基礎(chǔ)監(jiān)控數(shù)據(jù)主要是指應(yīng)用服務(wù)實例的運行時狀態(tài)、資源使用情況等度量指標(biāo)。Micrometer默認(rèn)提供了非常豐富的應(yīng)用度量指標(biāo)，只要接入了Micrometer就可以直接采集到這些數(shù)據(jù)，主要包括：
- 系統(tǒng)信息，包括運行時間、CPU使用率、系統(tǒng)負(fù)載等；
- 內(nèi)存使用情況，包括堆內(nèi)存使用情況和非堆內(nèi)存使用情況；
- 線程使用情況，包括線程數(shù)、守護(hù)線程數(shù)、線程峰值等；
- 類加載信息；
- GC信息，包括GC次數(shù)、GC消耗時間等；
- HTTP請求情況，描述HTTP請求的性能指標(biāo)，是非常重要的監(jiān)控指標(biāo)，在統(tǒng)計HTTP服務(wù)的QPS、響應(yīng)時間和成功率時必不可少。
3）第三方接口監(jiān)控
微服務(wù)架構(gòu)中，可以通過調(diào)用和組合已有服務(wù)的方式創(chuàng)建新服務(wù)，第三方接口會直接影響到自身服務(wù)，因此第三方服務(wù)接口的調(diào)用情況同樣值得關(guān)注。在如何采集第三方服務(wù)接口的監(jiān)控數(shù)據(jù)上，主要有兩種方案：
① 顯式主動采集
在發(fā)生第三方接口調(diào)用的地方，主動進(jìn)行監(jiān)控數(shù)據(jù)的采集?；蛘咧苯佑簿幋a，或者用注解、切面的形式，優(yōu)點是方案簡單，缺點是會對已有的業(yè)務(wù)代碼造成侵入。
② 隱式組件采集
在使用的HTTP/RPC組件中增加埋點采集的邏輯，優(yōu)點是業(yè)務(wù)代碼不需修改，缺點是HTTP/RPC組件需要擴(kuò)展和升級。
我們最終選擇了第二種方案，主要原因是：
- 首先我們的技術(shù)方案比較統(tǒng)一，都采用HTTP協(xié)議進(jìn)行服務(wù)調(diào)用，且使用的HTTP客戶端組件（fluent-hc）也是基于Okhttp3進(jìn)行的二次封裝，方便統(tǒng)一修改；
- 其次，Micrometer支持通過SDK的方式自定義監(jiān)控指標(biāo)數(shù)據(jù)的采集，也提供了眾多常用的組件埋點方案，Okhttp3即是其中之一，進(jìn)一步簡化了第三方接口的監(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)控的維度，我們可以方便地將自身服務(wù)與所使用到的第三方服務(wù)關(guān)聯(lián)起來，以統(tǒng)一的視圖展示服務(wù)用到了哪些第三方服務(wù)接口、這些第三方服務(wù)接口的響應(yīng)時間和成功率是多少。當(dāng)服務(wù)出現(xiàn)異常時，對于定位問題有很大幫助；同時，一些內(nèi)部的服務(wù)可能監(jiān)控報警并不全面，第三方監(jiān)控也能幫助他們提升服務(wù)質(zhì)量。
4、基于文件的服務(wù)發(fā)現(xiàn)
Prometheus采用的Pull模型需要知道哪些是被監(jiān)控的目標(biāo)對象。在Prometheus中配置監(jiān)控目標(biāo)分為靜態(tài)和動態(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)配置的方式最為簡單，但在實際生產(chǎn)環(huán)境中并不可取。容器每時每刻都可能進(jìn)行著創(chuàng)建和銷毀，不可能通過靜態(tài)配置方式設(shè)置監(jiān)控目標(biāo)。我們最開始選擇了Consul的服務(wù)發(fā)現(xiàn)，它引入了集中的注冊中心，微服務(wù)啟動時向注冊中心注冊服務(wù)實例，Prometheus便可以從注冊中心查詢到服務(wù)實例作為監(jiān)控目標(biāo)。
不過，我們最終并沒有采用Consul，主要原因有兩點：
- 一是微服務(wù)接入Consul需要涉及代碼改動，雖然改動不大，但大量服務(wù)的接入仍有不小的成本；
- 二是還需要再單獨部署和維護(hù)一套Consul環(huán)境，帶來新的維護(hù)成本。
Prometheus服務(wù)發(fā)現(xiàn)的原理很簡單，通過第三方提供的接口，Prometheus查詢到需要監(jiān)控的目標(biāo)列表，然后輪訓(xùn)監(jiān)控目標(biāo)獲取監(jiān)控數(shù)據(jù)。由于QAE是私有云平臺，Prometheus無法直接提供支持，但基于以上原理，我們可以實現(xiàn)類似的服務(wù)發(fā)現(xiàn)機制。
我們開發(fā)了基于文件的服務(wù)發(fā)現(xiàn)prom-sd-qae。prom-sd-qae是一個獨立程序，部署在Prometheus服務(wù)所在的機器。它定時通過QAE平臺的HTTP接口抓取容器服務(wù)列表，按Prometheus要求的格式在本地磁盤生成JSON或YAML文件，其中定義了所有的監(jiān)控目標(biāo)列表。Prometheus定時從文件中讀取最新的監(jiān)控目標(biāo)，并從中拉取監(jiān)控數(shù)據(jù)。
這一方案在兩次刷新監(jiān)控目標(biāo)之間，可能會發(fā)生監(jiān)控目標(biāo)的銷毀和創(chuàng)建，此時存在短暫的過期監(jiān)控目標(biāo)；不過，該方案兼顧了服務(wù)發(fā)現(xiàn)的動態(tài)性與簡便性，依然不失為一種簡單有效的選擇。
5、統(tǒng)一報警
Prometheus允許基于PromQL定義報警的觸發(fā)條件，Prometheus周期性的對PromQL進(jìn)行計算，當(dāng)滿足條件時就會向Alertmanager發(fā)送報警信息。
在配置報警規(guī)則時，我們將每個服務(wù)的報警規(guī)則定義在一個group下，每個group定義了多條報警規(guī)則，包括：響應(yīng)時間報警、接口成功率報警、QPS報警、第三方接口報警等。這樣的好處是以服務(wù)為維度將報警規(guī)則聚合在一起，查看和配置時更方便；另外，同一個報警規(guī)則下不同服務(wù)的報警閾值可能不同，這樣也可以獨立配置。
下圖是一個報警規(guī)則示例：
Alertmanager在接收到報警后，可以對報警進(jìn)行分組、抑制、靜默等額外處理，然后路由到不同的接收器。Alertmanager支持多種報警通知方式，除常用的郵件通知外，還支持釘釘、企業(yè)微信等方式，也支持通過webhook自定義通知方式。
愛奇藝的統(tǒng)一報警平臺實現(xiàn)了報警話題、報警內(nèi)容、報警渠道、報警訂閱的統(tǒng)一處理，我們充分利用了統(tǒng)一報警平臺，開發(fā)了Alert-proxy報警代理服務(wù)。Alertmanager通過webhook方式將報警發(fā)送到Alert-proxy，Alert-proxy再投遞到統(tǒng)一報警平臺，最終發(fā)送到最終熱聊、郵件、短信等接收端。Alert-proxy會將報警投遞到統(tǒng)一報警平臺一個默認(rèn)的報警話題Topic，也支持投遞到其他的Topic上?？梢詾椴煌?wù)、不同報警級別單獨設(shè)置Topic，實現(xiàn)更精確的通知觸達(dá)和聚焦。
報警涵蓋了服務(wù)HTTP接口、第三方HTTP接口，也包括了JVM和容器的狀態(tài)，目前已基本滿足需求。
寫在最后
監(jiān)控是一個老生常談但又常談常新的話題，與業(yè)務(wù)特點、技術(shù)棧、方案選型有很大關(guān)聯(lián)，看待問題的角度不同最終的方案也不盡相同，到底什么樣的方式是最合適的，這都是仁者見仁、智者見智，只有適合自己的才是最好的。
本文是現(xiàn)階段微服務(wù)監(jiān)控的一些實踐總結(jié)，隨著業(yè)務(wù)和技術(shù)的不斷發(fā)展，未來還有許多方面需要不斷地探索和改進(jìn)，例如報警規(guī)則優(yōu)化、自動化報表、系統(tǒng)智能化監(jiān)控等，使監(jiān)控更加全面、強大和智能，進(jìn)一步提升服務(wù)質(zhì)量和穩(wěn)定性，助力業(yè)務(wù)快速發(fā)展。
文章題目：基于Prometheus來做微服務(wù)監(jiān)控，有多吃香？
當(dāng)前鏈接：http://www.5511xx.com/article/dheegii.html
