普後設資料服務監控解密

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

引言：

在傳統的資訊系統架構模式下，各個組織或各個部門根據各自的業務需求，在不同時期不同技術環境下建設出各自的資訊系統。隨著資訊化建設的不斷推進，業務活動呈現高頻化、碎片化、場景化的特點。隨之而來的是對系統的處理能力、容量、業務持續性、需求響應速度、運維響應速度的更高要求。

如何有效的管理資料、高效的提供資料服務的其中一個關鍵就是提供對資料服務的統一監控。

目錄：

一、資料服務監控

二、資料採集

三、資料格式化

四、資料儲存

五、資料展示

一、資料服務監控

為提供統一、標準、安全、高效的資料服務，我們需要做好一點那就是統一資料執行監控，那麼統一資料服務執行監控需要做哪些事情呢？

首先獲取資料服務的執行資料，需要我們對資料進行採集。有了資料我們就可以去對資料做初步的分析，通過分析對資料進行格式化，格式化後的資料又需要去做持久化儲存，方便未來不定期的查詢。單純的數字可能並不能直觀的反應資料問題，那就需要藉助前端工具對資料做視覺化的展示。

資料服務監控通過實時服務分析引擎（SSM）提供日誌解析及監控能力，對事前預警、事中告警、事後統計分析等功能提供後臺支撐。我們先來看一種可行的部署架構中，SSM的具體部署方式。

二、資料採集

實時服務分析引擎的部署

相信大家對此是非常熟悉的這也是一種很常見的微服務部署架構，Nginx通過負載均衡對業務請求進行分流，閘道器Gateway再將請求通過Eureka等註冊中心轉發到後臺服務中。服務閘道器是成熟且健壯的業務系統中不可或缺的重要元件，它是所有服務的總入口，它是監控、認證的切入點。我們可以在閘道器處新增對資料服務的採集功能。

閘道器攔截器手動埋點

資料採集：做資料採集的前提一定是對監控需求的仔細揣摩，如果你是粗粒度的應用監控、系統監控，那麼資料服務總入口就是資料採集的切入點，如果你是細粒度的應用監控，例如應對時下流行的分散式微服務架構你希望做到對呼叫鏈路的詳細監控，那麼每個微服務的入口就是資料採集的著手處。網路上有很多對於微服務架構的監控元件，例如Skywalking、Cat、Zipkin、Pinpoint等，這裡就不一一贅述，我們今天的重點不是去研究每一次服務呼叫的具體詳情，我們只從服務總體的健康狀態出發。所以我們只需要極少的代價在資料服務總入口也就是閘道器進行資料埋點，收集資料詳情即可。

非同步落日誌

非同步落日誌的具體流程如下：

1. 閘道器監控資料持續產生，放入快取佇列（請求流轉的過程中要避免IO操作，儘可能的減少對請求本身的影響）

2. 快取佇列大小達到預先設定的大小，將快取佇列複製到臨時快取（一個臨時物件），並清空快取佇列，然後執行寫檔案操作

3. 當檔案大小達到預先設定的大小時，將當前檔案重新命名，代表檔案寫操作完成。(重新命名的原因是因為實時服務分析引擎會對產生的日誌檔案進行讀，避免對同一個檔案同時出現讀寫操作)

日誌落地相關配置

當監控資料進行初步落地以後我們就可以通過實時服務解析引擎對日誌進行提取分析，這個過程我願意稱之為資料格式化過程。

日誌關鍵資訊

三、資料格式化

提取資料的第一步是對閘道器落下來的檔案日誌進行收集然後處理。

日誌檔案讀取流程

日誌檔案目錄下可能會有多種型別的檔案，我們需要通過名稱正則匹配篩選需要的檔案。

資料格式化：從資料服務總入口收集到的原始資料做初步資料分析，從原始資料中提取關鍵資訊（譬如請求報文、響應報文、請求時間等）進行格式化，並選擇合適的方式將資料持久化到資料庫中。

統計分析任務流程

統計分析任務由多個執行緒共同完成：

1. TimeStatics執行緒任務用來分析時間段內的以不同的消費方和服務提供方為維度的呼叫統計指標，比如：在兩分鐘內A系統呼叫B系統時服務響應的成功次數、異常次數、平均響應時間、最長響應時間等資料指標。

2. Exception執行緒任務用來將資料服務異常呼叫記錄同正常呼叫區分開來，異常響應對於運維監控來說更為重要。

3. All執行緒任務會將每一筆的資料服務記錄到案

4. Top執行緒任務用來統計資料服務呼叫訪問時長TopN的呼叫詳情。

資料分析執行緒解析

四、資料儲存

資料儲存：資料落地以後需要對落地的資料進行解析分析，將對應的資料拆分成合理的指標單元進行持久化操作。

針對關係型資料庫，以mybatis為底層框架實現資料的持久化操作，同時支援將海量監控資料儲存在ES中，充分利用ES聚合檢索分類分析的能力。

物理表一覽

針對不同的呼叫請求，我們進行分類統計，以請求方、服務提供方、閘道器例項節點為維度獲取如下關鍵資訊進行彙總

1. 服務超時異常個數

2. 系統異常個數

3. 業務異常個數

4. 非法呼叫個數（未配置服務呼叫關係）

5. 非法IP呼叫個數（請求方IP不在白名單內）

6. 成功呼叫次數

7. 總呼叫時長

8. 最長呼叫時長TopN的統計記錄

關於告警

沒有告警的監控就像一潭死水，沒有靈魂。我們不能將注意力全部Focus到監控系統上，所以及時的自動告警就是監控中必須的事情。我們提供統一介面接入郵件、釘釘，藉助常用辦公系統實現對資料服務的實時告警。

告警維度主要有以下幾個：

• 響應時間告警：針對一段時間內超過指定次數、指定響應時長的告警。

• 系統狀態告警：應用系統狀態告警，當應用無法正常執行時告警。

• 業務異常告警：針對一段時間內的成功響應占比低於指定閾值進行告警。

五、資料展示

資料展示：對指標單後設資料整合分析，藉助Echarts元件，提供針對不同需求的視覺化圖

關於作者：阿良，普元開發工程師，參與普元EOS8 Studio、EOS8微服務管理平臺開發，負責關於服務監控、日誌監控等元件開發；參與太平洋保險供數平臺建設，負責服務管理註冊監控。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2649592/，如需轉載，請註明出處，否則將追究法律責任。