再談心跳檢測報表構圖(10.18)

最近一直在思考心跳檢查和實時監控報表功能，這個報表重點就是監控當前的ESB服務匯流排，已經匯流排接入的所有提供介面服務的系統當前狀態是否正常。經過分析有如下思考：

資訊總覽部分

還是需要有一個資訊總覽部分的內容，但是對於服務執行統計分析中的次數，時長，資料量，併發，異常等諸多內容沒有必要都在資訊總覽這個地方顯示。對於實時監控來說，我們最關心的還是ESB匯流排平臺的可用執行緒數和JVM記憶體情況，而這屬於網管類系統監控的內容。對於執行緒數則和系統併發數有直接關係，而對於JVM記憶體則和資料量有直接關係。

對於資訊總覽部分，初步考慮是採用百度Echart的實時動態圖展示，即該圖動態推送新產生的資料到圖表上，同時整個圖表折線和柱狀圖內容會動態進行滾動。通過這種方式可以實時觀測到最近30分鐘或1個小時的資料。初步考慮對於服務併發數，資料量和異常數三個資訊都可以通過該方式進行動態滾動重新整理展示。

按組織進行欄位展示

ESB匯流排如果接入多個組織，多個子組織的業務系統的時候，那麼就要考慮按組織進行分域展示。對於實際的App應用的效能監控來說，需要包括ESB匯流排自身的中介軟體，也需要包括各個業務系統提供的Service介面伺服器本身的監控。

對於ESB匯流排來說，應該包括了OSB服務匯流排，JMS訊息匯流排，MFT檔案傳輸，以及管控治理平臺諸多叢集的效能監控，確保匯流排本身各個元件提供能力正常。

對於每一個業務系統的監測，需要單獨設計一個面板來監測該APP Server本身的關鍵效能指標。因此還需要考慮每一個面板如何設計。在百度的Echart裡面找了下，還沒有找到合適的面板設計並迴圈佈局的圖表外掛，因此這塊還是得自己進行設計和程式碼實現。

單個面板的設計

舉例來說某個子公司有CMS系統需要接入到ESB服務匯流排，那麼就需要對CMS系統本身提供的介面服務進行實時監控。那麼這個實時監控究竟需要監控和實時展現哪些內容，考慮了下，初步包括幾個方面：

1. 總探測次數和探測異常次數：當天中的探測總次數，已經一共有多少次探測失敗的次數。

2. 技術連通性：考慮僅僅訪問成功WSDL地址就算技術連通。

3. 業務連通性：ESB匯流排模擬消費方實際去呼叫業務系統提供的業務服務(query服務），有成功返回才成功。

因此單個業務系統面板需要展示如上內容，同時對於技術連通性和業務連通性，在實現的時候考慮能夠顯示最近10次的探測結果，比如30秒探測一次，那麼也就是可以顯示先最近5分鐘實際的業務系統和介面服務效能檢測情況。而不是隻顯示當前最近因此的探測情況。

當最後一次心跳檢查出現無法連通和探測失敗的時候，需要考慮在更加醒目的位置來顯示這種警告和告警。以方面在監控的時候能夠快速的發現問題並響應解決。

元資料的配置和資料儲存

對於元資料的配置涉及到需要檢查哪些組織，每個組織需要檢查哪些系統，同時每個系統檢查的WS介面服務地址在哪裡。同時還涉及到具體的全域性變數配置，比如探測的時間間隔，總覽圖表的重新整理時間間隔，模擬服務消費呼叫的時候預設傳遞的引數，如何判斷返回正常等，這些都需要進行配置。

其次對於資料儲存，初步考慮對於實時監測正常的情況下，不對監測內容進行儲存，而只是對檢查失敗的詳細日誌記錄進行儲存。同時檢查的情況按天進行展示，對於每天實際檢查的總次數，實際的錯誤次數等資料仍然需要進行儲存。這個儲存可以定時寫入到資料庫進行持久化即可。