微服務下的監控體系

1

前言

分散式和微服務架構的落地和發展，隨著業務快速發展，伺服器越來越多，中間件、應用、微服務、資料庫等也越來越多樣化，監控是微服務控制系統的關鍵部分，你的軟體越複雜，那麼你就越難了解其性能及問題排障。

業務量達到百億、千億規模後，幾百、數千台虛擬機、中間件容器，需要監控的網路、硬體、軟體、應用和各種資料庫。

微服務的特點決定了功能模塊的部署是分散式的，大部分功能模塊都是單獨部署運行的，彼此通過匯流排交互，都是無狀態的服務。這種架構下，從前到後的業務流程會經過多台虛擬機和很多微服務進行處理、調用和傳遞，業務處理過程中會遇到很多棘手的問題：

如何基於同一套技術方案和架構來實時監控如此龐大的微服務體系？

如何主動並提前發現生產問題和生產隱患？

分散在各個伺服器上的日誌怎麼處理？

如果業務流出現了錯誤和異常，如何定位是哪個點出的問題？

如何快速定位問題？

如何跟蹤業務流的處理順序和結果？

2

微服務的挑戰

(1)、監控源的多樣化

較多的業務域，存在的大量的子系統、模塊、資料庫(mysql、redis、mongodb、neo4j)和中間件。

(2)、海量數據

海量的業務數據，結構化數據和非結構化數據(影像文件、電子合同、報文、身份證等)。

(3)、數千個服務提供方

大量的微服務，部署在不同的虛擬機上，服務的註冊、提供服務、掛起、版本更新、停止服務。

(4)、調用路徑和環節長

完成一個業務動作可能會調用數個甚至超過10以上的服務，經過網狀的服務調用路徑，經過不同的主機、甚至不同的機房。生產出現問題可以跟環境、網路或存儲都有關係。

(5)、基礎組件眾多

基於微服務架構的應用使用較多的基礎和開源組件。

(6)、部署模式多樣化

不同的應用、微服務、開源組件對部署環境的要求是不一致的。

3

服務維度監控

3.1 傳統監控

傳統IT模式都是按分層來監控，比如從基礎設施（如網路、主機、虛擬機上的CPU、內存、磁碟等）、系統（操作系統、中間件、資料庫）、應用（子系統、模塊、功能的申請量、交易量、成功率、失敗率）、前端（用戶申請頁面、動作等）。

3.2 微服務監控

微服務的監控主要以服務以中心來監控，業務發展比較順利的情況下，金融業務突破百億級規模是比較快速的。那麼支撐這些業務量下服務的數量達到數千級別是比較正常的。在雲化環境或虛擬化環境，一千多個服務被部署到不同的主機上，每個相同的服務最少部署了二個主機上，這時不同的服務之間的調用變得非常複雜。

如果基於微服務的監控體系沒有成熟之前，微服務的弊端就會凸現。此時我們會深受其害，當一個業務流程出現問題後，我們無法知道那個環節出現的問題，只能靠慢慢看日誌和後台數據，判斷問題變的非常冗長。對服務提前預警以及快速診斷成為我們最迫切需要解決的問題。

4

技術架構

4.1 監控源

微服務架構下，網路的監控指標、主機指標、存儲指標、中間件指標、虛擬機指標、應用和模塊指標、微服務指標、服務間調用指標，都需要納到我們的監控源里去。

4.2 採集和埋點

(1)、埋點

對業務流程節點和重點環節作日誌埋點，對業務量、業務指標、波動值都可以作為微服務中的埋點列印出來。

(2)、日誌監控

系統日誌監控上，可以時間、服務為維度去匹配ERROR 或是 Exception 日誌。把所有發現的異常都抓出來。

(3)、採集器

關於主機和網路的監控，主要靠採集器來定時列印日誌，然後依靠日誌分析來作抓取和後續分析。

4.3 Logstash

Logstash是一個開源的數據收集引擎，它具有備實時數據傳輸能力。它可以統一過濾來自不同源的數據，並按照我們的規範輸出到ES里。

Logstash通過管道進行運作，管道有兩個必需的元素，輸入和輸出，還有一個可選的元素，過濾器。

輸入插件從數據源獲取數據，過濾器插件根據用戶指定的數據格式修改數據，輸出插件則將數據寫入到目的地。

4.4 Elasticsearch

Elasticsearch的特點：分散式，零配置，自動發現，索引自動分片，索引副本機制，restful風格介面，多數據源，自動搜索負載等。

ES在整個架構里承擔了後台分散式存儲以及全文檢索的功能。ES在數據架構的主要概念（與關係資料庫Mysql對比）：

4.5 監控分析和預警

ELK架構里的Kibana和Elasticsearch可以無縫銜接，監控分析可以基於Kibana來作分析，不過有很多局限性。

另一個方案從ES里定時抽取數據，作分析和監控實時展示。

監控閥值：

監控閥值的設立需要有分級機制，以分通知、預警、告警三級為例：通知應用運維人員關注，比如「系統登錄數2000，登錄成功率95%，最近7天登錄數基線500，登錄成功率96%」。

預警代表監控事件需要運維人員處理，但重要性略低，比如「CPU使用率71%」。

告警則必須馬上處理的事件，比如「交易成功率為10%，平時為90%」這類監控事件己反映出交易。

預警升級：當一個預警超過一定時間限制後，未處理或一直未解決，需要上升處理。

5

小結

金融產品同質化的時代，服務不可用或問題不能快速診斷解決的時候，客戶不會在線等待，他們會用腳投票。

互聯網時代百萬黑產團隊會隨時關注和掃描我們的問題或漏洞，這個時候，解決速度和金錢在賽跑。

作為IT民工的我們知道，代碼是人寫出來的，只要是人作的事，就不可能不出問題。實時監控和預警有些時間成為我們最後一道關口和守護。

END

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！