大數(shù)據(jù)下的技術(shù)運(yùn)營(yíng)

大數(shù)據(jù)下的技術(shù)運(yùn)營(yíng)----監(jiān)控系統(tǒng)技術(shù)運(yùn)營(yíng)團(tuán)隊(duì)的由來(lái)在運(yùn)維更名為技術(shù)運(yùn)營(yíng)的兩年內(nèi)，我們對(duì)這個(gè)團(tuán)隊(duì)的工作目標(biāo)產(chǎn)生了新的理解，工作內(nèi)容也逐漸從傳統(tǒng)的維護(hù)往DevOps方向轉(zhuǎn)化。技術(shù)運(yùn)營(yíng)，簡(jiǎn)單地講就是利用技術(shù)手段，降低資源消耗，提高基礎(chǔ)資源的運(yùn)行效率，提高整個(gè)軟件生命周期運(yùn)行的效率。這意味著對(duì)團(tuán)隊(duì)內(nèi)的每個(gè)工程師都提出了更高的要求：一方面我們要支持目前的系統(tǒng)運(yùn)行;同時(shí)也要針對(duì)目前的業(yè)務(wù)流程去開(kāi)發(fā)自己的工具，讓整個(gè)基礎(chǔ)資源和能力工具化，把經(jīng)驗(yàn)和自己對(duì)流程的理解變成Web化的工具，提供給程序員使用。為什么必須自主研發(fā)監(jiān)控系統(tǒng)目前在TalkingData的Developer除了負(fù)責(zé)代碼的編寫(xiě)，還要負(fù)責(zé)生產(chǎn)系統(tǒng)自己程序的性能指標(biāo)提供監(jiān)控接口，以及生產(chǎn)環(huán)境程序bug的處理。Developer能夠一定程度的獲取生產(chǎn)權(quán)限，方便常規(guī)的維護(hù)和簡(jiǎn)單故障的處理。這樣一來(lái)，技術(shù)運(yùn)營(yíng)的挑戰(zhàn)就來(lái)了：權(quán)限的管理、性能指標(biāo)的監(jiān)控、日志的管理以及資源的隔離，都需要有成熟的工具去支撐。目前市面上有很多開(kāi)源的軟件可以實(shí)現(xiàn)這樣的功能，但是在不同程度上存在各種各樣的問(wèn)題。以監(jiān)控為例，開(kāi)源的監(jiān)控很多，Zabbix、Nagios、Cacti，都是不錯(cuò)的監(jiān)控軟件，但是首先它們并不能滿足大數(shù)據(jù)場(chǎng)景下的數(shù)據(jù)存儲(chǔ);其次，如果監(jiān)控項(xiàng)和主機(jī)數(shù)量過(guò)多，數(shù)據(jù)查詢時(shí)會(huì)出現(xiàn)速度慢等一系列問(wèn)題。所以技術(shù)運(yùn)營(yíng)首先選擇在監(jiān)控上做了全新的設(shè)計(jì)和開(kāi)發(fā)，新監(jiān)控命名為OWL(貓頭鷹)，意思就是在技術(shù)人員睡覺(jué)的時(shí)候提供值班服務(wù)。自研監(jiān)控系統(tǒng)的三大技術(shù)要點(diǎn)傳統(tǒng)的監(jiān)控很多還是在停留在設(shè)備、網(wǎng)絡(luò)、系統(tǒng)相關(guān)的監(jiān)控上，重視數(shù)據(jù)的采集，但是在數(shù)據(jù)算法和Role上比較傳統(tǒng)。對(duì)監(jiān)控系統(tǒng)簡(jiǎn)化抽象下，傳統(tǒng)監(jiān)控可以大致分為三個(gè)過(guò)程：數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)、響應(yīng)處理。OWL監(jiān)控在傳統(tǒng)監(jiān)控基礎(chǔ)上，增加了Algorithm模塊，支持復(fù)雜的算法規(guī)則報(bào)警，如下圖所示：1.監(jiān)控?cái)?shù)據(jù)采集DataCollection就是數(shù)據(jù)采集，這里指的數(shù)據(jù)不光是基礎(chǔ)硬件的指標(biāo)，也可以是業(yè)務(wù)指標(biāo)。下面介紹兩個(gè)實(shí)例。第一個(gè)例子是主機(jī)硬盤(pán)狀態(tài)的采集：下面的數(shù)據(jù)采集中第一列是硬盤(pán)設(shè)備標(biāo)號(hào)，第二列是硬盤(pán)的狀態(tài)，在監(jiān)控的這個(gè)層面，一切都是metric，不同的層級(jí)可以抽象到不同的metric，結(jié)合metric+timestamp+tagk1+tagv1…+tagkN+tagvN，這樣針對(duì)相同的metric去加tag，用來(lái)標(biāo)示數(shù)據(jù)，方便后期的查詢。第二個(gè)例子是Nginx的訪問(wèn)狀態(tài)的數(shù)據(jù)采集：第一列是http請(qǐng)求的狀態(tài)，第二列是計(jì)數(shù)器2.監(jiān)控?cái)?shù)據(jù)存儲(chǔ)監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)也是一個(gè)很有意思的話題，監(jiān)控?cái)?shù)據(jù)在數(shù)據(jù)結(jié)構(gòu)上是很有特色的。仔細(xì)觀察發(fā)現(xiàn)監(jiān)控?cái)?shù)據(jù)基本上都是和時(shí)間維度相關(guān)的，以metric+timestamp的組合形式的數(shù)據(jù)占了所有監(jiān)控?cái)?shù)據(jù)量的大部分，相比而言，多維度的監(jiān)控?cái)?shù)據(jù)比較少;如果出現(xiàn)了多維度的監(jiān)控?cái)?shù)據(jù)，也可以通過(guò)其他的方式繞開(kāi)處理。RDBMS由于要考慮數(shù)據(jù)的關(guān)聯(lián)，所以它在整體數(shù)據(jù)存儲(chǔ)設(shè)計(jì)上充分考慮了數(shù)據(jù)的完整性和關(guān)系型，同時(shí)在schema設(shè)計(jì)上還要遵守?cái)?shù)據(jù)庫(kù)的幾大范式。傳統(tǒng)的監(jiān)控大多數(shù)還是使用了RDBMS，但是這造成了性能上和擴(kuò)展性上的局限性。針對(duì)監(jiān)控?cái)?shù)據(jù)這樣簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，卻采用了一套復(fù)雜的存儲(chǔ)格式。隨著近些年各種各樣的垂直的。技術(shù)領(lǐng)域?qū)?shù)據(jù)的存儲(chǔ)不同要求的演變，如Graphdatabase，TimeSeriesDatabases等數(shù)據(jù)庫(kù)得到了不斷發(fā)展;監(jiān)控?cái)?shù)據(jù)在存儲(chǔ)上有了更多的選擇，InfluxDB，OpenTSDB，KairosDB都是不錯(cuò)的選擇，最后我們選擇了OpenTSDB，這主要是因?yàn)門(mén)alkingData的大數(shù)據(jù)基因，Hadoop和HBase在我們的業(yè)務(wù)系統(tǒng)中大規(guī)模使用。從現(xiàn)有的數(shù)據(jù)體量上，OpenTSDB能夠滿足現(xiàn)在的業(yè)務(wù)要求。簡(jiǎn)單的總結(jié)了一下OpenTSDB的優(yōu)點(diǎn)：使用HBase存儲(chǔ)，不存在單點(diǎn)故障。使用HBase存儲(chǔ)，存儲(chǔ)空間幾乎無(wú)限。支持永久存儲(chǔ)，可以做容量規(guī)劃。易于定制圖形能擴(kuò)展采集數(shù)據(jù)點(diǎn)到100億級(jí)。能擴(kuò)展metrics數(shù)量到K級(jí)別(比如CPU的使用情況，可以算作一個(gè)metric，即metric就是1個(gè)監(jiān)控項(xiàng))支持秒級(jí)別的數(shù)據(jù)。此外，OpenTSDB支持API查詢，可以輕松地和其他系統(tǒng)進(jìn)行數(shù)據(jù)對(duì)接，也方便其他系統(tǒng)抽取監(jiān)控相關(guān)的數(shù)據(jù)。并且，查詢方式靈活：查詢數(shù)據(jù)可以使用query接口，它既可以使用get的querystring方式，也可以使用post方式以JSON格式指定查詢條件。3.監(jiān)控的報(bào)警算法Algorithm這塊是傳統(tǒng)監(jiān)控系統(tǒng)所欠缺的，基本上都是單個(gè)指標(biāo)的大于，小于這樣的算法，但是遇到集群或者復(fù)雜的指標(biāo)，就需要自己去增加一些算法，比如多個(gè)指標(biāo)的加和，平均值，top10，歷史相似度等。這些算法的引入，可以增加報(bào)警的準(zhǔn)確度，有效的減少報(bào)警數(shù)量，讓報(bào)警變得人性化。關(guān)于報(bào)警的算法會(huì)在本系列的后續(xù)文章進(jìn)行詳細(xì)介紹。自研監(jiān)控系統(tǒng)一覽簡(jiǎn)單的介紹一下OWL的整體架構(gòu)，下面目前的架構(gòu)是第四個(gè)大版本。在研發(fā)的過(guò)程中，我們也嘗試了很多的開(kāi)源技術(shù)，如RRDtools、Graphlite，也踩了很多的技術(shù)坑，最后我們整體選擇了OpenTSDB，在這個(gè)技術(shù)棧下面演進(jìn)了兩個(gè)版本：方案特點(diǎn)一：語(yǔ)言棧統(tǒng)一為Go2015年的版本，由于技術(shù)人員的稀缺，我們采用了一部分Python一部分Golang的系統(tǒng)，在開(kāi)源推廣中帶來(lái)了很多問(wèn)題，主要是部署難度增加。2016年即將發(fā)布的版本中，metriccollection模塊、Controller模塊、Inspector模塊全部采用Golang開(kāi)發(fā)，簡(jiǎn)單摘錄一下Golang的優(yōu)點(diǎn)：部署簡(jiǎn)單。Go編譯生成的是一個(gè)靜態(tài)可執(zhí)行文件，除了glibc外沒(méi)有其他外部依賴。這讓部署變得異常方便：目標(biāo)機(jī)器上只需要一個(gè)基礎(chǔ)系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應(yīng)用所需的各種包、庫(kù)的依賴關(guān)系，大大減輕了維護(hù)的負(fù)擔(dān)。這是與Python的巨大區(qū)別。并發(fā)性好。goroutine和channel使得編寫(xiě)高并發(fā)的服務(wù)端軟件變得相當(dāng)容易，很多情況下完全不需要考慮鎖機(jī)制以及由此帶來(lái)的各種問(wèn)題。單個(gè)Go應(yīng)用也能有效的利用多個(gè)CPU核，并行執(zhí)行的性能好。良好的語(yǔ)言設(shè)計(jì)。執(zhí)行性能好。雖然不如C和Java，但通常比原生Python應(yīng)用還是高一個(gè)數(shù)量級(jí)的，適合編寫(xiě)一些瓶頸業(yè)務(wù)。內(nèi)存占用也非常節(jié)省。我們也同樣意識(shí)到這樣的問(wèn)題，所以在OWLV4.0的版本中，全部統(tǒng)一了語(yǔ)言棧，降低了大家的使用難度，和后期技術(shù)棧的維護(hù)難度。方案特點(diǎn)二：定制化自己的圖表上面的架構(gòu)圖中，大家不難發(fā)現(xiàn)，整個(gè)OWL的設(shè)計(jì)核心是CustomReport。將整個(gè)系統(tǒng)從以工具為核心，轉(zhuǎn)向以數(shù)據(jù)和用戶為核心，OWL的好處是首先使用者會(huì)自己定義感興趣的數(shù)據(jù)指標(biāo);其次在指標(biāo)上添加rule，用戶可以更專注數(shù)據(jù);隨后可以做一些簡(jiǎn)單的數(shù)據(jù)處理，一些數(shù)據(jù)加和等這樣的簡(jiǎn)單運(yùn)算;并且定制不同樣式的圖表，餅圖、柱狀圖、線圖。在整個(gè)監(jiān)控上形成一個(gè)立體的結(jié)構(gòu)，不同層面的工程師可以在同一個(gè)層面上工作。有了好的工具支持，才能讓工程師DevOps起來(lái)。OWL新版本中也將會(huì)支持Docker的支持，這塊目前采用的主要是google開(kāi)源的cAdvisor作為數(shù)據(jù)采集的，通過(guò)二次開(kāi)發(fā)將cAdvisor變成plugin集成進(jìn)入OWL。方案特點(diǎn)三：報(bào)警模塊的劃分關(guān)于報(bào)警方式，目前沒(méi)有放置在OWL中。在TalkingData，所有的報(bào)警采用Messagecenter的方式，Messagecenter有獨(dú)立的Web，支持基礎(chǔ)的信息查詢，信息的發(fā)送對(duì)外采用restfulAPI暴露給其他的系統(tǒng)，信息的傳送方式上，按照消息的優(yōu)先級(jí)程度，采用不同的下行方式，高=短信+企業(yè)微信+email;中=企業(yè)微信+email;低=email，目前正在考慮加入商業(yè)化的呼轉(zhuǎn)