WOT2016互聯網運維與開發者峰會上,來自極光推送首位大數據工程師許俊做了以 “大數據架構下對于業務監控的幾點思考”為主題的演講。本文章是把本次分享干貨亮點的整理成文字形式,呈獻廣大的用戶。
許俊是極光的第一位嚴格意義上的大數據工程師,目前是大數據平臺的負責人,見證了極光大數據平臺從0到1,迅速發展到現在規模的歷程。他給開發者帶來的是大數據架構下對于業務監控的幾點思考。通過類比地球地質演進的過程,來描述大數據架構下的業務監控架構的演進歷史。
圖1 大數據迅速發展到現在規模的歷程
寒武紀——搭建Hadoop集群/Zabbix對機器基本指標監控
幾億年前的地球處于寒武紀,北半球大部分被海水淹沒,地球上的生物比較匱乏,主要是一些類似藍藻、紅藻這樣的低等生物。這時極光有了第一個Hadoop集群,集群規模非常小,業務、數據也比較少。這樣對應到監控上的壓力也很小,所以只用業界比較流行的Zabbix做一些基本的機器層面的監控。
圖2 Zabbix 對機器基本指標監控
但業務、數據不多,不代表沒有問題,有時候會等到第二天,甚至是第三天,業務部門反饋出來,才知集群出現問題。如上圖是傳統的監控圖,比較被動。這剛剛開始,并沒有投入太多的精力做這個事情。
侏羅紀——開始重視監控/定時檢查CDH監控
侏羅紀時期,有造山運動和劇烈的火山活動。爬行動物非常發達,出現了巨大的恐龍、空中飛龍和始祖鳥,植物中蘇鐵、銀杏最繁盛。這是極光的集群規模隨著業務的增長逐漸擴大,開始重視監控問題。
圖3 CDH監控
許俊表示,當時極光選用的是Cloudera的CDH, 如上圖,是CDH監控上的部分截圖,監控是非常詳細和細致,能滿足當時大部分需求。因此在這個基礎上做了一些定制,對接到監控系統和報警系統,達到知曉集群狀況的目的。
白堊紀——引入Kafka等組件/基于Zabbix監控做定制
白堊紀時期,造山運動非常劇烈,我國許多山脈都在這時形成。動物中恐龍最盛,魚類和鳥類很發達,哺乳動物開始出現。植物中顯花植物很繁盛,也出現了熱帶植物和闊葉樹。此時,極光集群規模繼續擴大,業務的復雜度繼續提升,故對監控的要求越來越高,并且因業務需要引進很多新組建,類似Kafka等。
圖4 基于 Zabbix 定制的業務監控
針對需求,監控也應隨之進步。CDH滿不能滿足需求的情況下,因有Zabbix傳統監控,就在已有的系統前提下做一些定制和開發。如上圖,在Zabbix框架前提下做的一些定制化開發,可以看到監控的是其中一個zabbix節點內存使用的情況,也同樣對接到告警系統,這樣能夠覆蓋到之前覆蓋不到的業務層級。這個過程持續了比較長的時間,但在用的過程中發現兩個問題:其一,Zabbix更關注CPU、Memory、Network 等機器指標,對業務指標支持不好。其二,只能做簡單的記錄和展示,無法靈活地發現問題。
許俊表示,在這個時期極光又遇到新的困難,想看看繼續沿著之前的思路想,已有的方案能不能解決。目前監控方案有CDH方案、根據Zabbix做定制方案。CDH方案,雖然Hadoop整個是開元的,但CDH版本的監控這一套是相對比較封閉,并且定制化比較高,所以如果在這個基礎上做比較困難。Zabbix也遇到兩個問題,好像這條路走不下去了。這時開始反思是不是應該換個方向,換個思路解決這個問題。
新生代——需要一套通用功能豐富的監控系統
新生代時期,地殼有強烈的造山運動,早期的爬行動物絕跡,哺乳動物繁盛,生物達到高度發展階段。此時對于監控指標的壓力越來越大,簡單的指標監控已經不能滿足要求,出現了越來越多的類似 “平均值”、“最大值”、“求和” 等更靈活多樣的需求,這就需要一套更通用和功能豐富的監控系統。
圖5 大數據平臺的架構
大數據平臺架構。如上圖是大數據平臺的實際架構中的一部分,下面深色域是整個集群核心,在CDH的監控下已經得到比較好的監控。上面Flume是作為數據收集的核心的組建,Kalka是作為現在數據的重點中心。這兩個組建目前是沒辦法覆蓋到監控里面去,所以在做一個通用的監控系統時,必須照顧到Kalke、Flume,及類似的開元組建。
圖6 基于時間序列的監控
選擇Graphite作為核心監控組建。許俊表示,經過調研發現基于時間序列的監控能夠滿足需求,它可以把監控指標值存儲以外,每個指標都會帶上一個時間戳,這樣就可以基于時間戳做非常多變換。選擇Graphite的原因有三:其一,可提供一站式解決方案,完成數據收集、存儲和展示比較核心的功能。其二,提供了非常豐富的數據的操作,基本能涵蓋我們絕大部分的需求。其三,Graphite整個框架是基于Python生態圈開發,第三方依賴少。
圖7 Graphite的架構
Graphite架構。有三個部分組成:Graphite wab,數據圖片的渲染及對用戶的交互。Carbon,是來實現接聽端口,接收指標數據的功能。Whisper,是一個時間序列的數據庫,是參考了ID類型數據庫做的。
圖8 Graphite下的魔法 — Functions
Graphite下的魔法 — Functions。如上圖可以看到下拉列表里面有非常多豐富的Functions,在使用過程中會發現,基本上平時業務里面能用到的指標這里面都能覆蓋到。
圖9 設計師的頁面 — Grafana
Grafana。 如上圖,為了避免對用戶友好信譽的影響,引入Grafana組件。它是一個純前端的組建,不做任何數據收集、數據存儲及數據計算,只是一個純UI來和用戶完成交互,其后端依然是Graphite。在后臺配置Graphite Metric,就是按照Graphite的格式,一級一級的把目錄定下來,后面Graphite提供一些豐富方法,可以在后面通過簡單的點擊就能完成。也會在上面時時的把一些數據指標給展示出來。
圖10 強大的collector&aggregator — StatsD
StatsD。如上圖,可以看到StatsD提供了非常多的Metric的類型,可以對接到業務,并且它提供各種語言的Collector,在監控場景下性能可以達到要求。Aaggregator能對數據監控指標做非常非常多聚合的操作。
圖11 監控的監控 — Cabot
Cabot。Cabot組件作為監控的告警系統。如上右圖,可以看得到Metric就是我們前面提到Graphite那個Metric的路徑,它會實時把圖片秀出來,下面有幾種格式的返回。Cabot除了Graphite以外,它還支持Jenkins、HTTP、ICMP等作為監控來源。同時它提供其他格式如,郵件、短信和電話等。但是很遺憾它這些方案都是基于一些開元組件和第三方的組件來做,沒辦法對接到自己的告警系統,因為一般都會自己輪一套告警系統。但是好在Cabot又基于python做的,所以做一些定制非常簡單即可。
圖12 監控系統架構
監控系統架構。上圖是監控系統的整個架構,最右邊是各個業務,我們通過StatsD的Collector,把各種Metric收集到StatsD,做一些負載均衡及聚合操作。然后把Metric剖析給Graphite服務器,Graphite服務器頁面比較丑,所以給它加了一個漂亮帽子Grafana。整個系統只能收集數據,不能發現問題,所以給它做加一個告警組件Cabot,這樣一來整個業務系統的監控架構就完整了。
圖13 大數據時代監控系統未來存在的挑戰
大數據時代監控系統未來面臨哪些挑戰呢?從整個演進的過程來看,架構是隨著業務不斷的發展而發展的,許俊主要講解了以下三個重點:
第一:要整合大數據各個組件的通用監控告警系統。整個大數據平臺的架構,肯定是從簡單到復雜,隨著業務的發展,舊的組件不能滿足需求,然后引入新的組件,會有越來越多的組件加入到架構中。監控系統也需要覆蓋到這些組件。怎么樣做一套通用監控系統,而不用每個都去定制,每個都去寫復雜的代碼,這是面需要花時間關注的問題。
第二:整個監控系統和內部告警系統給對接,但是還有很多各種各樣的系統。其中非常有特點調度系統,要怎么像對接監控系統一樣,把調度系統對接起來,完成資源更好的利用,是后面需要研究的課題。
第三:有監控,有告警,能非常及時的發現問題。但發現問題沒用,還要解決問題。現在都是采用人工去做的方式,那怎么樣通過程序的方式,在監控系統里面自動觸發恢復的操作,讓問題響應時間從人工干涉的幾分鐘,甚至幾個小時,變成程序自動恢復的幾秒,甚至幾毫秒?甚至更進一步,更方便好用及強大的監控系統,其實能發現很多之前傳統的告警或人工沒辦法發現問題,可以在問題發生之前就發出預警。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:大數據架構下對于業務監控的幾點思考
本文網址:http://www.guhuozai8.cn/html/consultation/10839719385.html