微服務架構是目前各大互聯網公司廣泛採用的軟件架構方式。在微服務架構中，系統被拆分爲多個小的、相互獨立的服務，這些服務運行在本身的進程中，能夠獨立的開發和部署。在業務快速變化時，微服務單一職責、自治的特色，使系統的邊界更加清晰，提高了系統的可維護性；同時，簡化了系統部署的複雜度，能夠針對某個微服務單獨升級和發佈；在業務增加時，也能夠方便的進行獨立擴展。數據庫
微服務架構雖然帶來了不少好處，但也帶來了新的問題。在以往的單體應用中，排查問題每每經過查看日誌定位錯誤信息和異常堆棧；可是在微服務架構中服務繁多，出現問題時的問題定位變得很是困難。另外，微服務每每經過組合已有的服務來建立新服務，一個服務的故障極可能會產生雪崩效應，致使整個系統的不可用。所以，如何監控微服務的運行情況、當出現異常時能快速給出報警，這給開發人員帶來很大挑戰。編程
1 監控系統簡介微信
1.1網絡
監控的幾種主要方式
架構
在微服務架構中，不一樣維度有不一樣的監控方式。負載均衡
（1）健康檢查。健康檢查是對應用自己健康情況的監控，檢查服務是否還正常存活。運維
（2）日誌。日誌是排查問題的主要方式，日誌能夠提供豐富的信息用於定位和解決問題。編程語言
（3）調用鏈監控。調用鏈監控能夠完整的呈現出一次請求的所有信息，包括服務調用鏈路、所耗時間等。微服務
（4）指標監控。指標是一些基於時間序列的離散數據點，經過聚合和計算後能反映出一些重要指標的趨勢。
1.2
微服務監控的技術選型
因爲微服務架構自身的特色，使得傳統的一些監控方案再也不適用。在傳統應用監控中，Zabbix是最經常使用的監控方案。Zabbix的優勢在於成熟可靠、強大的社區支持、多年積累的經驗和方案。但Zabbix的缺點也很明顯，首先是使用難度高、學習曲線陡峭；其次，Zabbix的監控維度是主機，沒法適用於微服務的雲原生環境。
通過調研，咱們最終採用了Prometheus。選擇Prometheus的主要緣由：
（1） 成熟的社區支撐。Prometheus是一個開源的監控軟件，擁有活躍的社區，可以很好地與雲原生環境搭配。
（7）高性能。Prometheus單一實例便可處理數以百計的監控指標，每秒處理數十萬的數據，在數據採集和查詢方面有着優異的性能表現。
因爲採集的數據有可能丟失，Prometheus並不適合對採集數據要求100%準確的場景。實際上，對於監控系統的場景，偶爾的數據丟失徹底能夠接受。
2 基於Prometheus的微服務監控方案
2.1
愛奇藝號業務特色
愛奇藝號是愛奇藝專一視頻內容的創做、分發和變現的平臺，承載了自媒體、網大、網劇、兒童、動漫、知識、網絡綜藝、紀錄片、文學、輕小說、漫畫等內容，是愛奇藝內容生態的重要一環。
2.2
微服務監控系統概述
· 開發了第三方服務接口的監控數據採集工具。
· 開發了qae-monitor組件，採集服務運行時容器的監控數據。
· 開發了基於文件的動態服務發現，給Prometheus提供拉取目標。
· 開發了Alert proxy服務，實現了報警內容投遞到統一報警平臺。
· 使用Prometheus聯邦集羣模式部署，並使用Grafana用於監控數據展現。
2.3
服務的全面監控
監控系統通常採用分層的方式劃分監控對象。在咱們的監控系統中，主要關注如下幾種類型的監控對象：
對於應用服務和第三方接口監控，咱們經常使用的指標包括：響應時間、請求量QPS、成功率。
2.3.1 容器環境監控
微服務應用部署在愛奇藝內部的應用雲平臺（QAE）上。在雲平臺中，一臺主機上會同時存在多個容器實例，採用主機監控的方式採集到的資源使用和性能特徵其實是主機的指標數據，而非運行的容器。Prometheus雖然支持使用cAdvisor進行容器監控，但cAdvisor須要安裝在主機上，而QAE是一個公共平臺，自行安裝部署其餘軟件並不現實。好在QAE提供了開放的API，很好的解決了這一問題。
QAE平臺自身內建了監控功能，包括容器級和應用級兩個層級，除了能夠在QAE平臺經過頁面查看，也支持經過HTTP接口暴露出監控數據，這就爲咱們進行統一的監控數據採集提供了可能。
咱們開發了一個QAE容器監控數據採集的服務，qae-monitor。qae-monitor服務經過自定義Prometheus Collector的方式，實現對QAE監控數據的收集。服務定時調用QAE平臺的HTTP接口抓取容器監控數據，並整理成Prometheus的數據格式。
2.3.2 應用服務監控
基礎監控數據主要是指應用服務實例的運行時狀態、資源使用狀況等度量指標。Micrometer默認提供了很是豐富的應用度量指標，只要接入了Micrometer就能夠直接採集到這些數據，主要包括：
（5）HTTP請求狀況，描述HTTP請求的性能指標，是很是重要的監控指標，在統計HTTP服務的QPS、響應時間和成功率時必不可少。
2.3.3 第三方接口監控
微服務架構中，能夠經過調用和組合已有服務的方式建立新服務，第三方接口會直接影響到自身服務，所以第三方服務接口的調用狀況一樣值得關注。在如何採集第三方服務接口的監控數據上，主要有兩種方案：
（2）隱式組件採集。在使用的HTTP/RPC組件中增長埋點採集的邏輯，優勢是業務代碼不需修改，缺點是HTTP/RPC組件須要擴展和升級。
咱們最終選擇了第二種方案，主要緣由是：首先咱們的技術方案比較統一，都採用HTTP協議進行服務調用，且使用的HTTP客戶端組件（fluent-hc）也是基於Okhttp3進行的二次封裝，方便統一修改。其次，Micrometer支持經過SDK的方式自定義監控指標數據的採集，也提供了衆多經常使用的組件埋點方案，Okhttp3便是其中之一，進一步簡化了第三方接口的監控數據採集難度。
經過第三方接口監控的維度，咱們能夠方便地將自身服務與所使用到的第三方服務關聯起來，以統一的視圖展現服務用到了哪些第三方服務接口、這些第三方服務接口的響應時間和成功率是多少。當服務出現異常時，對於定位問題有很大幫助；同時，一些內部的服務可能監控報警並不全面，第三方監控也能幫助他們提高服務質量。
2.4
基於文件的服務發現
靜態配置的方式最爲簡單，但在實際生產環境中並不可取。容器每時每刻均可能進行着建立和銷燬，不可能經過靜態配置方式設置監控目標。咱們最開始選擇了Consul的服務發現，它引入了集中的註冊中心，微服務啓動時向註冊中心註冊服務實例，Prometheus即可以從註冊中心查詢到服務實例做爲監控目標。不過，咱們最終並無採用Consul，主要緣由有兩點，一是微服務接入Consul須要涉及代碼改動，雖然改動不大，但大量服務的接入仍有不小的成本；二是還須要再單獨部署和維護一套Consul環境，帶來新的維護成本。
Prometheus服務發現的原理很簡單，經過第三方提供的接口，Prometheus查詢到須要監控的目標列表，而後輪訓監控目標獲取監控數據。因爲QAE是私有云平臺，Prometheus沒法直接提供支持，但基於以上原理，咱們能夠實現相似的服務發現機制。
咱們開發了基於文件的服務發現prom-sd-qae。prom-sd-qae是一個獨立程序，部署在Prometheus服務所在的機器。它定時經過QAE平臺的HTTP接口抓取容器服務列表，按Prometheus要求的格式在本地磁盤生成JSON或YAML文件，其中定義了全部的監控目標列表。Prometheus定時從文件中讀取最新的監控目標，並從中拉取監控數據。
2.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，實現更精確的通知觸達和聚焦。
監控是一個老生常談但又常談常新的話題，與業務特色、技術棧、方案選型有很大關聯，看待問題的角度不一樣最終的方案也不盡相同，到底什麼樣的方式是最合適的，這都是仁者見仁、智者見智，只有適合本身的纔是最好的。
本文是現階段微服務監控的一些實踐總結，隨着業務和技術的不斷髮展，將來還有許多方面須要不斷地探索和改進，例如報警規則優化、自動化報表、系統智能化監控等，使監控更加全面、強大和智能，進一步提高服務質量和穩定性，助力業務快速發展。
本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。