服務心跳機制主要用於確認服務的存活狀態，UAVStack的心跳資料還負責上報節點的容器及程式監控資料，支援在前端實時檢視應用容器和程式的執行狀態，並根據這些資料對容器和程式做出預警。

一、背景

在微服務架構中，服務心跳是一個簡單但非常重要的機制，用於確認微服務的存活狀態。UAVStack中的心跳是一個Http請求，MonitorAgent（以下簡稱MA）透過定時向HealthManager（以下簡稱HM）傳送一個帶有特定報文格式的Http請求完成一次心跳的傳送過程。心跳報文含有傳送時的時間戳，用於更新HM端的資料狀態。

與普通的心跳不同，UAVStack中的心跳還負責上送MA端的應用容器和程式監控資料。每次傳送心跳的時候，在MA端會有定時任務去收集MA所在的應用容器心跳的基本資訊，及應用容器上的程式資料，隨著心跳資料包一起上送。

本文將首先介紹UAVStack的基礎心跳機制，之後對應用容器、程式的資料採集做詳細說明。

二、基本架構

心跳的實現有很多種方式，心跳的發起可以由客戶端發起也可以由服務端發起，只需完成確認存活這一基本功能即可。但是在一般的實現中，我們更傾向於客戶端主動向服務端進行報告，因為當客戶端逐漸增加，單純透過服務端的輪詢會導致服務端的壓力，影響效能。

在UAVStack的實現中，我們也採用了這樣的方式，透過客戶端（MA）主動向服務端（HM）傳送心跳資訊，告知HM自身的存活情況。

一次心跳由UAV的MA和HM共同完成：

MA定時生成心跳資料，攜帶MA節點的應用容器資訊、程式資訊以及服務資訊，透過Http請求上報給HM；
HM負責將接收到的心跳資料存入Redis快取，並定時掃描心跳資料，確認節點的存活狀態。對於隨同的應用容器等監控資訊，會在Redis進行暫存，後續隨著HM的定時任務最終存入OpenTSDB進行落盤。整體的架構如下所示：

三、基礎心跳機制

心跳服務主要流程如上圖所示，其邏輯有以下幾步：

1）MA的定時心跳任務生成一個空心跳資料，將心跳資料交給MA端的容器、程式資料採集任務。

2）MA端的容器、程式資料採集任務負責產生心跳資料的時間戳、採集節點的應用容器、程式監控資料、節點的基本資訊、節點的可用服務資訊等。經過以上過程之後，心跳資料將包含以下內容：

心跳時間戳：節點傳送心跳時的時間戳，方便HM後續比對判定節點的存活狀態。
應用容器的基本資訊：包括節點ID、名稱、主機名、IP等。
應用容器的簡單監控資料：包括CPU負載、記憶體使用、硬碟使用等。
應用容器上的程式資訊：包括每個程式的pid、資源佔用等。
節點的能力資訊：包括該節點上啟用的Feature功能。
節點的服務資訊：包括該節點上可提供的服務及其訪問介面，用以實現服務發現。
可選）子節點的節點資訊：如果MA和HM部署在不同的網段，則MA無法透過直接Http的方式推送資料給HM，此時需要MA將資料上送給自己網段內的HM，再由該HM的心跳客戶端傳送給總的HM。這種情況下，上報的資料中會攜帶子節點的節點資訊。每個節點資訊均會包含上述幾種資料。

最後將心跳資料傳送給HM。

3）HM端在接收到心跳資料之後，將其存入自身的Redis快取。使用上報資料中的服務資訊更新Redis中的服務狀態，用於服務發現請求。

4）HM端在啟動心跳接收服務時，會同時啟動心跳檢查任務。這個任務會定時掃描Redis中的心跳資料，根據當前系統時間與心跳時間戳的差，判斷心跳節點的存活狀態，更新節點的狀態，並對於過期的節點做刪除處理。

四、應用容器、程式資料採集

UAV的心跳資料除了完成心跳功能之外，還要上報節點的應用容器及程式的監控資料。

將應用容器與程式資料透過Http方式上報是為了保證應用容器監控資料與應用監控資料的隔離，透過不同方式的上送可以保證在MQ服務不能使用時不影響容器與程式資料的採集。

本節將集中說明這些資料的採集細節。

4.1 應用容器資料採集

應用容器的資料分為兩部分：

其一是容器的基本資訊，即節點的ID，主機名，系統資訊和JVM資訊等；

另一部分是一些簡單的實時監控採集資料，包括CPU的負載、記憶體佔用情況和磁碟佔用情況等。這些資料在每次上報心跳資料的時候會分別從以下資料來源實時採集：

應用啟動後的System.getProperty：這部分資料主要包括作業系統的基本資訊，JVM資訊等。
Java提供的工具類：這部分主要包括網路卡資訊。
透過JMX獲取的資訊：包括CPU佔用、記憶體佔用等。
系統本身記錄的資訊：這部分包括可提供的服務資訊、啟動的Feature資訊、節點ID等。
透過執行系統命令得到的資訊：包括磁碟佔用情況。
透過直接讀取/proc目錄下的檔案獲取的資訊：包括CPU佔用、記憶體佔用等。

4.2 程式資料採集

不同於應用容器資料採集，程式的資料並不是在心跳程式中進行採集的，而是由專門的Feature負責。在Feature中將程式資料採集進一步分解成程式埠流量資料採集以及其他資料採集。這兩者均由定時任務完成，互相協作，最終由程式探測的定時任務更新心跳客戶端的程式資料。

這種使用多個採集任務分別採集的方式可以針對不同的資料進行不同頻度的採集。如對於網路埠流量的採集，就可以以更長的週期進行，以減低資料採集帶來的效能損耗。同時，不同的任務也可以使用不同的執行緒執行，提升執行的效率。

程式資料採集流程大致如下圖所示：

程式埠流量探測定時任務每隔一定時間讀取本地變數埠列表，獲取要採集的埠號。

之後對於Windows環境，採用JPcap獲取網路卡物件，並在網路卡上設定tcp過濾器來統計一段時間內的埠流量。對於Linux環境則是直接透過呼叫Python指令碼開啟socket，分析流過的資料包獲得。

獲得全部埠上的流量資料後，任務會將採集資料交給程式資料採集任務，更新其本地變數，同時設定本次採集的時間戳。

程式探測定時任務由一系列子任務構成，在任務開始的時候，會先準備好一個Map結構的資料容器，用於存放採集到的程式資訊，每個程式由pid區分，作為Map的key。

任務會先掃描所有的程式，獲取pid和程式的埠。掃描到的程式會經過一個過濾器排除不需要採集資料的程式，之後正式採集每個程式上的資料。

對於每一個程式，會透過執行系統命令採集連線數、CPU、記憶體佔用，磁碟讀寫資料以及網路埠流量資料。其中網路埠流量資料是由埠流量探測任務採集並更新的本地變數，而程式探測任務也會將掃描到的最新的埠列表更新到埠流量探測任務的本地變數。

如果應用是部署在容器上的，則還會有對應的容器資訊採集。最後程式探測任務會將採集到的程式資料更新到心跳客戶端的本地變數，隨著每次心跳資料的生成被一起採集並上報。

程式資料的採集分別來自以下資料來源：

系統命令：包括CPU、記憶體、連線數等（top等命令）
/proc目錄下各程式子目錄：包括CPU、記憶體等資訊、磁碟讀寫等資訊
執行指令碼：包括Linux環境下的埠流量資料採集
第三方工具包：包括win環境下的埠流量資料採集（JPcap）

五、HM處理

心跳資料和容器資料在透過Http上送到HM端之後，會由HM端對應的服務進行處理。

HM在啟動時會啟動自己的心跳客戶端，負責傳送本機的心跳資料和採集HM所在容器的監控資料。同時還會啟動一個心跳服務，負責接收處理所有上送的心跳和容器資料資訊。

心跳服務在收到心跳資料請求後，會根據HM的配置，判定當前的HM是不是Master節點。如果HM是Master節點，心跳服務會從Http攜帶的報文中拿出上報的資料，取得上報節點中的可用服務用於更新服務發現資訊，之後將資料存入後端的Redis快取中；如果不是Master節點，則會將資料移交至本機的心跳客戶端，由其下次傳送心跳時一起上送。

這樣的設計是考慮到大規模監控時會有跨機房的情況存在，此時各監控節點往往不在同一個網段內，透過將同一個網段內的機器上交到邊界的“閘道器”統一上交可解決這一問題。此時的HM即充當著“閘道器”這一角色。

HM在啟動的時候同時還會啟動一個定時任務，這個任務負責處理各節點的存活狀況。任務定時從Redis中讀取全部心跳資料，依次檢查上送心跳資料中的客戶端時間戳與當前系統時間戳的差值。

當時間超過一定的上送時間間隔之後，更改對應的節點存活狀態。當超過一倍上送時間間隔，意味節點可能死亡，處於dying狀態。當超過兩倍時間間隔時，意味著節點已經死亡。當超過三倍時間間隔時，心跳服務會刪除該節點的快取記錄。

隨心跳一起上報的容器和程式資料會隨著心跳資料一同被存入Redis中，後續由HM的其他定時任務讀取併傳送給預警中心進行處理，最終監控指標被格式化成特定的結構存入OpenTSDB。

同時採集的容器資料和程式資料會提供前端AppHub檢視介面，如圖所示：

點選頁面上的每一個節點，可以檢視詳細的節點資訊，包括節點的作業系統資訊、JVM資訊、提供的服務和安裝的Feture等等。這些也就是前文所說的隨心跳資料上報的那部分資訊。如圖所示：

六、總結

心跳是微服務架構基礎但重要的機制，透過定時傳送心跳資料，MA節點報告了自身的存活狀態，使得HM能夠知曉當前系統的執行狀態。

同時，UAVStack的心跳資料還同時負責上報節點的容器及程式監控資料，隨著這些資料的上報，HM可以對監控的容器和程式做出預警，也能夠在前端實時看到應用容器和程式的執行狀態。

官方網站：

開源地址：

作者：張明明

來源：宜信技術學院

UAV心跳機制與容器、程式資料採集