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