一.前言

       每個系統都需要監控,而每個監控需求都有不同,我這邊的的方案是結合了當前部門及公司的特性去思考設計的,至於為什麼說是方案,而不是一個元件,因為個性化監控,要解決的問題其實不是一個元件就可以完全解決的,它需要多個元件合力完成.但為了但一篇文章足夠簡單,同時也能給讀者帶來一定的思考及學習價值,所以這裡焦點在方案上,但作者其實已經實現的本篇中的想法,會持續的補充文件,涉及到具體的點,都會在本文中提供地址連結.

二.面臨的問題

業務問題:

      當然所有的方案肯定是要基於實際需求,如果沒有實際需求,就是玩技術,而不是解決具體問題,見下:

本人在專案中有碰到以下問題點

1.上游系統會不定時的產生異常資料,需要馬上或一定時間內發現

2.當前系統使用的部署架構也算比較複雜,檢視問題,需要去多個監控系統分析與監控

3.單個專案的業務產生的有效資料量保持在6T左右(隨著公司業務變化,還會持續增長),業務資料分析統計種類多,量大,特別涉及到實時資料檢視對人工的耗時及系統的壓力都會比較大

4.使用專案的使用者群,普通使用者,產品,開發,運維,都希望有不同角度看待或分析問題

現有技術複用問題:

技術的複用非常重要,不能每次都是去顛覆,利用現有的技術積累就可以控制成本,所以要理解現有的技術資源是必須掌握的

1.公司級(涉及到公司的元件不會在這裡說出名字,只會標出方向)

       資料庫監控系統,線上物理監控系統,雲監控系統,面向非業務的異常,響應等等的監控系統,這些系統都是在業務層之外的,它們是解決是所有系統都需要用到的,可以幫助我們更好的分析和定位問題,我們可以用它們來做內聚好的監控大盤

2.部門級(這些技術都會為個性化監控帶來助力的)

資料層的分庫分表的封裝    資料層的封裝可以解決對於海量資料的查詢(API的簡單及解決沒有索引也可以查詢的方案是有效的幫助指標的獲取)

自定義查詢物件,   有了面對物件查詢,可以在規則引擎中儘可能的控制入參及安全(暴露SQL是比較危險的,同時將規則從非結構化轉成結構化,需要一個查詢物件做殼)

流式框架計算的阻塞元件( 可以在非同步中的同步中安全並充分利用分散式硬體環境,快速統計所需要的資源)

三.根據現有的問題及資源去設計

做技術設計,一定要在某一個粗的維度看問題,我稱之為產品的角度來看,可以抽象成 

1.指標:  配置成具體的元素(資料庫查詢的值,HTTP或外部API所獲取的值)

2.觸發規則:   只想在海量的資料中關注需要的東西,但需要能夠可配置

3.個性化顯示:   不同角色都有自己不同想要看的

4.報警:      快速響應,郵件,簡訊,又或監控大盤上資料字型顏色變換等等

有了以上的粗維度,我們在整體上就有了一些全域性感,然後再以技術的角度,可以抽象成

1.儲存(不管是什麼資料,一切都要存放在指定地方及標準化它,才是可以解析的)

選型 鍵值型 NOSQL(redis)  理由 :本公司最成熟的NOSQL,同時它的資料型別比較豐富

存放具體指標 -> hash (redis 資料型別)

存放具體指標對應的歷史記錄,內容存KEY-> list(redis 資料型別)

2.規則(藉助靈活的規則配置,非結構化的規則引擎是具備了所有規則的天然抽象元件,可以直接拿到使用)

選型 規則引擎drools  理由:免費的同時又與JAVA結合的好的,除了drools,好像沒有啥了

自定義的資料庫查詢(DB的查詢配置 這裡還涉及到對查詢物件的封裝,及透明的解決如何查詢大表)

自定義的HTTP或其它遠端API的定製(基於HTTP或基於特定遠端協議的request請求配置)

觸發規則

報警規則

3.模板(前端展現及郵件或簡訊等等報警,都需要可定製,模板引擎就是一個現成的抽象元件,也能直接拿來使用)

選型 模板引擎freemarker  理由:結合現有前端已經使用了的spring boot 並且支援freemaker,同時有官方中文文件

可以定製業務監控大盤(此類,使用者,產品,領導都比較關心)

可以定製每日監控或每小時監控(此類 運維和開發比較關心)

可以定製報警的內容(此類 大部分角色都比較關心)

簡訊模板

郵件模板

四.根據3個技術維度結合的去解決監控問題方法

那麼基於以上的三大維度去實現,就可以結合現有的技術並持續迭代解決現有的問題

方式1:

A同學配置了一個某維度失敗的數量,通過標準化好的存放在redis上,然後規則引擎將資料解析並返回特定標準物件,供一個專門處理每日統計的任務通過模板引擎去定製顯示達到每日監控資料維度

方式2:

B同學寫了一個數據質量程式,根據標準化好的API必須會存放在redis上面,然後資料質量展現程式會從redis取出來,通過規則引擎的計算(配置有合規性,一致性的),不滿足的再通過模板引擎去展現問題資料

方式3:

C同學通過配置現有的監控系統的一個 HTTP請求,通過規則引擎抽象的物件獲取需要的前置資料,從而得到請求的返回資料,再通過標準化好的API存放在redis上,在頁面上的模板引擎對應的頁面,形成個性化監控的大盤頁

前面前言也說了,本人已經實現,所以附上一些的實際效果圖供讀者更好的理解

規則定義分為規則組與具體規則:

具體規則定義

模板定義

統計郵件

五.相關地址(持續更新)

此文件偏向於方案類,但作者出於出品一定得接地氣基礎上,會在此貼出以上所有技術點的部落格地址

規則引擎drools封裝
模板引擎freemarker封裝:已實現,待補充文件

監控維度儲存的標準化API封裝:已實現,待補充文件

vipshop_ebs/朱傑

2018-02-14