微服務架構雖然帶來了很多好處，但也帶來了新的問題。在以往的單體應用中，排查問題往往通過查看日誌定位錯誤信息和異常堆棧；但是在微服務架構中服務繁多，出現問題時的問題定位變得非常困難。另外，微服務往往通過組合已有的服務來創建新服務，一個服務的故障很可能會產生雪崩效應，導致整個系統的不可用。因此，如何監控微服務的運行狀況、當出現異常時能快速給出報警，這給開發人員帶來很大挑戰。
本文將介紹我們基於Prometheus搭建微服務監控系統的一些實踐經驗，及愛奇藝號在微服務監控方面的一些探索和實踐，從愛奇藝號的業務特點出發，結合現有的開發運維技術棧確定監控的對象和指標，並有針對性地自研了一些關鍵組件和服務，實現服務的全面監控和統一報警。
一、監控系統簡介
1、監控的幾種主要方式
監控的幾種主要方式
在微服務架構中，不同維度有不同的監控方式。
1）健康檢查。健康檢查是對應用本身健康狀況的監控，檢查服務是否還正常存活。
2）日誌。日誌是排查問題的主要方式，日誌可以提供豐富的信息用於定位和解決問題。
3）調用鏈監控。調用鏈監控可以完整的呈現出一次請求的全部信息，包括服務調用鏈路、所耗時間等。
4）指標監控。指標是一些基於時間序列的離散數據點，通過聚合和計算後能反映出一些重要指標的趨勢。
在上述4中監控方式中，健康檢查是雲平臺等基礎設施提供的能力，日誌則一般有單獨的日誌中心進行日誌的採集、存儲、計算和查詢，調用鏈監控一般也有獨立的解決方案進行服務調用的埋點、採集、計算和查詢，本文主要討論第4種監控方式。
2、微服務監控的技術選型
監控的幾種主要方式
由於微服務架構自身的特點，使得傳統的一些監控方案不再適用。在傳統應用監控中，Zabbix是最常用的監控方案。Zabbix的優點在於成熟可靠、強大的社區支持、多年積累的經驗和方案。但Zabbix的缺點也很明顯，首先是使用難度高、學習曲線陡峭；其次，Zabbix的監控維度是主機，無法適用於微服務的雲原生環境。
經過調研，我們最終採用了Prometheus。選擇Prometheus的主要原因：
1） 成熟的社區支撐。Prometheus是一個開源的監控軟件，擁有活躍的社區，能夠很好地與雲原生環境搭配。
2） 易於部署和運維。Prometheus核心只有一個二進制文件，沒有其他的第三方依賴，部署運維均十分方便。
3）採用Pull模型，通過HTTP的Pull方式從各個監控目標拉取監控數據。Push模型一般通過Agent方式去採集信息並推送到收集器中，每個服務的Agent都需要配置監控數據項與監控服務端的信息，在大量服務時會加大運維難度；另外，採用Push模型，在流量高峯期間監控服務端會同時接收到大量請求和數據，會給監控服務端造成很大壓力，嚴重時甚至服務不可用。
4）強大的數據模型。Prometheus採集到的監控數據均以指標的形式存在於內置的時序數據庫中，除了基本的指標名稱外，還支持自定義的標籤。通過標籤可以定義出豐富的維度，方便進行監控數據的聚合和計算。
5）強大的查詢語言PromQL。通過PromQL可以實現對監控數據的查詢、聚合、可視化、告警。
6）完善的生態。常見的操作系統、數據庫、中間件、類庫、編程語言，Prometheus都提供了接入方案，並且提供了Java/Golang/Ruby/Python等語言的客戶端SDK，能夠快速實現自定義的監控邏輯。
7）高性能。Prometheus單一實例即可處理數以百計的監控指標，每秒處理數十萬的數據，在數據採集和查詢方面有着優異的性能表現。
由於採集的數據有可能丟失，Prometheus並不適合對採集數據要求100%準確的場景。實際上，對於監控系統的場景，偶爾的數據丟失完全可以接受。
二、基於Prometheus的微服務監控方案
1、愛奇藝號業務特點
愛奇藝號是愛奇藝專注視頻內容的創作、分發和變現的平臺，承載了自媒體、網大、網劇、兒童、動漫、知識、網絡綜藝、紀錄片、文學、輕小說、漫畫等內容，是愛奇藝內容生態的重要一環。
愛奇藝號整體採用微服務架構，內部依據功能、領域等角度劃分爲不同的微服務，外部流量先經DNS、QLB、前置機、網關等層完成統一鑑權、負載均衡、限流等操作後路由到系統內部不同的微服務實例。系統內部微服務除專有的MySQL、Redis、MQ等資源外，共享服務註冊/發現、配置中心等服務治理能力。
系統整體架構，如下圖所示：
愛奇藝號服務於內容創作者，服務質量直接決定了創作者的使用體驗，影響內容創作的熱情，進而影響內容生態的健康，因此對服務質量有很高要求。同時，愛奇藝號作爲前臺業務，依賴公司許多的內部服務和中臺服務，服務的穩定性直接影響了自身服務的質量。
基於愛奇藝號的業務特點，在搭建微服務監控系統時，重點關注自身服務接口和第三方服務接口的監控。
2、 微服務監控系統概述
我們基於Prometheus搭建了適合自身業務特點的微服務監控系統。Prometheus已提供非常豐富的組件，同時我們也開發了部分組件，滿足我們的監控需求。
微服務監控系統的整體結構，如下圖所示：
-
使用Spring Boot Actuator和Micrometer採集服務的監控數據，並暴露給Prometheus拉取；
-
開發了第三方服務接口的監控數據採集工具；
-
開發了qae-monitor組件，採集服務運行時容器的監控數據；
-
開發了基於文件的動態服務發現，給Prometheus提供拉取目標；
-
開發了Alert proxy服務，實現了報警內容投遞到統一報警平臺；
-
使用Prometheus聯邦集羣模式部署，並使用Grafana用於監控數據展示。
3、服務的全面監控
監控系統一般採用分層的方式劃分監控對象。在我們的監控系統中，主要關注以下幾種類型的監控對象：
-
容器環境監控，主要指服務所處運行環境的一些監控數據；
-
應用服務監控，主要指服務本身的基礎數據指標，提現服務自身的運行狀況；
-
第三方接口監控，主要指調用其他外部服務接口的情況。
對於應用服務和第三方接口監控，我們常用的指標包括：響應時間、請求量QPS、成功率。
1）容器環境監控
微服務應用部署在愛奇藝內部的應用雲平臺（QAE）上。在雲平臺中，一臺主機上會同時存在多個容器實例，採用主機監控的方式採集到的資源使用和性能特徵實際上是主機的指標數據，而非運行的容器。
Prometheus雖然支持使用cAdvisor進行容器監控，但cAdvisor需要安裝在主機上，而QAE是一個公共平臺，自行安裝部署其他軟件並不現實。好在QAE提供了開放的API，很好的解決了這一問題。
QAE平臺自身內建了監控功能，包括容器級和應用級兩個層級，除了可以在QAE平臺通過頁面查看，也支持通過HTTP接口暴露出監控數據，這就爲我們進行統一的監控數據採集提供了可能。
我們開發了一個QAE容器監控數據採集的服務，qae-monitor。qae-monitor服務通過自定義Prometheus Collector的方式，實現對QAE監控數據的收集。服務定時調用QAE平臺的HTTP接口抓取容器監控數據，並整理成Prometheus的數據格式。
qae-monitor本身也通過Micrometer向外暴露監控數據採集端點，Prometheus通過該端點抓取採集到的監控數據。
2）應用服務監控
基礎監控數據主要是指應用服務實例的運行時狀態、資源使用情況等度量指標。Micrometer默認提供了非常豐富的應用度量指標，只要接入了Micrometer就可以直接採集到這些數據，主要包括：
-
系統信息，包括運行時間、CPU使用率、系統負載等；
-
內存使用情況，包括堆內存使用情況和非堆內存使用情況；
-
線程使用情況，包括線程數、守護線程數、線程峯值等；
-
類加載信息；
-
GC信息，包括GC次數、GC消耗時間等；
-
HTTP請求情況，描述HTTP請求的性能指標，是非常重要的監控指標，在統計HTTP服務的QPS、響應時間和成功率時必不可少。
3）第三方接口監控
微服務架構中，可以通過調用和組合已有服務的方式創建新服務，第三方接口會直接影響到自身服務，因此第三方服務接口的調用情況同樣值得關注。在如何採集第三方服務接口的監控數據上，主要有兩種方案：
① 顯式主動採集
在發生第三方接口調用的地方，主動進行監控數據的採集。或者直接硬編碼，或者用註解、切面的形式，優點是方案簡單，缺點是會對已有的業務代碼造成侵入。
② 隱式組件採集
在使用的HTTP/RPC組件中增加埋點採集的邏輯，優點是業務代碼不需修改，缺點是HTTP/RPC組件需要擴展和升級。
我們最終選擇了第二種方案，主要原因是：
-
首先我們的技術方案比較統一，都採用HTTP協議進行服務調用，且使用的HTTP客戶端組件（fluent-hc）也是基於Okhttp3進行的二次封裝，方便統一修改；
-
其次，Micrometer支持通過SDK的方式自定義監控指標數據的採集，也提供了衆多常用的組件埋點方案，Okhttp3即是其中之一，進一步簡化了第三方接口的監控數據採集難度。
具體而言，Micrometer提供了OkHttpMetricsEventListener組件，用於收集Okhttp的監控數據。我們只需要在構建Okhttp實例的時候傳入OkHttpMetricsEventListener實例即可；也可以傳入一個EventListener.Factory實例，在工廠的創建方法中返回OkHttpMetricsEventListener實例。Okhttp在3.11.0的版本中才正式加入了EventListener功能，使用時需要注意Okhttp的版本。
通過第三方接口監控的維度，我們可以方便地將自身服務與所使用到的第三方服務關聯起來，以統一的視圖展示服務用到了哪些第三方服務接口、這些第三方服務接口的響應時間和成功率是多少。當服務出現異常時，對於定位問題有很大幫助；同時，一些內部的服務可能監控報警並不全面，第三方監控也能幫助他們提升服務質量。
4、基於文件的服務發現
Prometheus採用的Pull模型需要知道哪些是被監控的目標對象。在Prometheus中配置監控目標分爲靜態和動態兩種，常用的包括靜態文件配置、文件服務發現、Consul服務發現等。此外，Prometheus還支持DNS、微軟Azure、亞馬遜EC2、谷歌GCE、Kubernetes等多種服務發現方式。
靜態配置的方式最爲簡單，但在實際生產環境中並不可取。容器每時每刻都可能進行着創建和銷燬，不可能通過靜態配置方式設置監控目標。我們最開始選擇了Consul的服務發現，它引入了集中的註冊中心，微服務啓動時向註冊中心註冊服務實例，Prometheus便可以從註冊中心查詢到服務實例作爲監控目標。
不過，我們最終並沒有採用Consul，主要原因有兩點：
-
一是微服務接入Consul需要涉及代碼改動，雖然改動不大，但大量服務的接入仍有不小的成本；
-
二是還需要再單獨部署和維護一套Consul環境，帶來新的維護成本。
Prometheus服務發現的原理很簡單，通過第三方提供的接口，Prometheus查詢到需要監控的目標列表，然後輪訓監控目標獲取監控數據。由於QAE是私有云平臺，Prometheus無法直接提供支持，但基於以上原理，我們可以實現類似的服務發現機制。
我們開發了基於文件的服務發現prom-sd-qae。prom-sd-qae是一個獨立程序，部署在Prometheus服務所在的機器。它定時通過QAE平臺的HTTP接口抓取容器服務列表，按Prometheus要求的格式在本地磁盤生成JSON或YAML文件，其中定義了所有的監控目標列表。Prometheus定時從文件中讀取最新的監控目標，並從中拉取監控數據。
這一方案在兩次刷新監控目標之間，可能會發生監控目標的銷燬和創建，此時存在短暫的過期監控目標；不過，該方案兼顧了服務發現的動態性與簡便性，依然不失爲一種簡單有效的選擇。
5、統一報警
Prometheus允許基於PromQL定義報警的觸發條件，Prometheus週期性的對PromQL進行計算，當滿足條件時就會向Alertmanager發送報警信息。
在配置報警規則時，我們將每個服務的報警規則定義在一個group下，每個group定義了多條報警規則，包括：響應時間報警、接口成功率報警、QPS報警、第三方接口報警等。這樣的好處是以服務爲維度將報警規則聚合在一起，查看和配置時更方便；另外，同一個報警規則下不同服務的報警閾值可能不同，這樣也可以獨立配置。
下圖是一個報警規則示例：
Alertmanager在接收到報警後，可以對報警進行分組、抑制、靜默等額外處理，然後路由到不同的接收器。Alertmanager支持多種報警通知方式，除常用的郵件通知外，還支持釘釘、企業微信等方式，也支持通過webhook自定義通知方式。
愛奇藝的統一報警平臺實現了報警話題、報警內容、報警渠道、報警訂閱的統一處理，我們充分利用了統一報警平臺，開發了Alert-proxy報警代理服務。Alertmanager通過webhook方式將報警發送到Alert-proxy，Alert-proxy再投遞到統一報警平臺，最終發送到最終熱聊、郵件、短信等接收端。Alert-proxy會將報警投遞到統一報警平臺一個默認的報警話題Topic，也支持投遞到其他的Topic上。可以爲不同服務、不同報警級別單獨設置Topic，實現更精確的通知觸達和聚焦。
報警涵蓋了服務HTTP接口、第三方HTTP接口，也包括了JVM和容器的狀態，目前已基本滿足需求。
寫在最後
監控是一個老生常談但又常談常新的話題，與業務特點、技術棧、方案選型有很大關聯，看待問題的角度不同最終的方案也不盡相同，到底什麼樣的方式是最合適的，這都是仁者見仁、智者見智，只有適合自己的纔是最好的。
本文是現階段微服務監控的一些實踐總結，隨着業務和技術的不斷髮展，未來還有許多方面需要不斷地探索和改進，例如報警規則優化、自動化報表、系統智能化監控等，使監控更加全面、強大和智能，進一步提升服務質量和穩定性，助力業務快速發展。
作者丨愛奇藝號技術團隊 來源丨愛奇藝技術產品團隊（ID：iQIYI-TP） dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： [email protected]