宜信開源|UAV心跳機制與容器、進程數據採集

服務心跳機制主要用於確認服務的存活狀態，UAVStack的心跳數據還負責上報節點的容器及進程監控數據，支持在前端實時查看應用容器和進程的運行狀態，並根據這些數據對容器和進程作出預警。

1、背景

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

與普通的心跳不一樣，UAVStack中的心跳還負責上送MA端的應用容器和進程監控數據。每次發送心跳的時候，在MA端會有定時任務去收集MA所在的應用容器心跳的基本信息，及應用容器上的進程數據，隨着心跳數據包一塊兒上送。

本文將首先介紹UAVStack的基礎心跳機制，以後對應用容器、進程的數據採集作詳細說明。

2、基本架構

心跳的實現有不少種方式，心跳的發起能夠由客戶端發起也能夠由服務端發起，只需完成確認存活這一基本功能便可。可是在通常的實現中，咱們更傾向於客戶端主動向服務端進行報告，由於當客戶端逐漸增長，單純經過服務端的輪詢會致使服務端的壓力，影響性能。

在UAVStack的實現中，咱們也採用了這樣的方式，經過客戶端（MA）主動向服務端（HM）發送心跳信息，告知HM自身的存活狀況。

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

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

3、基礎心跳機制

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

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中的心跳數據，根據當前系統時間與心跳時間戳的差，判斷心跳節點的存活狀態，更新節點的狀態，並對於過時的節點作刪除處理。

4、應用容器、進程數據採集

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）

5、HM處理

心跳數據和容器數據在經過Http上送到HM端以後，會由HM端對應的服務進行處理。

HM在啓動時會啓動本身的心跳客戶端，負責發送本機的心跳數據和採集HM所在容器的監控數據。同時還會啓動一個心跳服務，負責接收處理全部上送的心跳和容器數據信息。

心跳服務在收到心跳數據請求後，會根據HM的配置，斷定當前的HM是否是Master節點。若是HM是Master節點，心跳服務會從Http攜帶的報文中拿出上報的數據，取得上報節點中的可用服務用於更新服務發現信息，以後將數據存入後端的Redis緩存中；若是不是Master節點，則會將數據移交至本機的心跳客戶端，由其下次發送心跳時一塊兒上送。

這樣的設計是考慮到大規模監控時會有跨機房的狀況存在，此時各監控節點每每不在同一個網段內，經過將同一個網段內的機器上交到邊界的「網關」統一上交可解決這一問題。此時的HM即充當着「網關」這一角色。

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

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

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

同時採集的容器數據和進程數據會提供前端AppHub查看界面，如圖所示：

點擊頁面上的每個節點，能夠查看詳細的節點信息，包括節點的操做系統信息、JVM信息、提供的服務和安裝的Feture等等。這些也就是前文所說的隨心跳數據上報的那部分信息。如圖所示：

6、總結

心跳是微服務架構基礎但重要的機制，經過定時發送心跳數據，MA節點報告了自身的存活狀態，使得HM可以知曉當前系統的運行狀態。

同時，UAVStack的心跳數據還同時負責上報節點的容器及進程監控數據，隨着這些數據的上報，HM能夠對監控的容器和進程作出預警，也可以在前端實時看到應用容器和進程的運行狀態。

官方網站：https://uavorg.github.io/main/

開源地址：https://github.com/uavorg

做者：張明明

來源：宜信技術學院