為什么必須自主研發(fā)監(jiān)控系統(tǒng)
目前在TalkingData的Developer除了負責代碼的編寫，還要負責生產(chǎn)系統(tǒng)自己程序的性能指標提供監(jiān)控接口，以及生產(chǎn)環(huán)境程序bug的處理。Developer能夠一定程度的獲取生產(chǎn)權(quán)限，方便常規(guī)的維護和簡單故障的處理。這樣一來，技術(shù)運營的挑戰(zhàn)就來了： 權(quán)限的管理、性能指標的監(jiān)控、日志的管理以及資源的隔離，都需要有成熟的工具去支撐。 目前市面上有很多開源的軟件可以實現(xiàn)這樣的功能，但是在不同程度上存在各種各樣的問題。以監(jiān)控為例，開源的監(jiān)控很多，Zabbix、Nagios、Cacti，都是不錯的監(jiān)控軟件，但是首先它們并不能滿足大數(shù)據(jù)場景下的數(shù)據(jù)存儲;其次，如果監(jiān)控項和主機數(shù)量過多，數(shù)據(jù)查詢時會出現(xiàn)速度慢等一系列問題。所以技術(shù)運營首先選擇在監(jiān)控上做了全新的設計和開發(fā)，新監(jiān)控命名為OWL(貓頭鷹)，意思就是在技術(shù)人員睡覺的時候提供值班服務。
自研監(jiān)控系統(tǒng)的三大技術(shù)要點
傳統(tǒng)的監(jiān)控很多還是在停留在設備、網(wǎng)絡、系統(tǒng)相關(guān)的監(jiān)控上，重視數(shù)據(jù)的采集，但是在數(shù)據(jù)算法和Role上比較傳統(tǒng)。對監(jiān)控系統(tǒng)簡化抽象下， 傳統(tǒng)監(jiān)控可以大致分為三個過程：數(shù)據(jù)采集、數(shù)據(jù)存儲、響應處理。 OWL 監(jiān)控在傳統(tǒng)監(jiān)控基礎上，增加了 Algorithm 模塊，支持復雜的算法規(guī)則報警 ，如下圖所示：
1. 監(jiān)控數(shù)據(jù)采集
Data Collection 就是數(shù)據(jù)采集，這里指的數(shù)據(jù)不光是基礎硬件的指標，也可以是業(yè)務指標。下面介紹兩個實例。
第一個例子是 主機硬盤狀態(tài)的采集 ：
下面的數(shù)據(jù)采集中第一列是硬盤設備標號，第二列是硬盤的狀態(tài)，在監(jiān)控的這個層面，一切都是metric，不同的層級可以抽象到不同的metric，結(jié)合 metric + timestamp + tagk1 + tagv1… + tagkN + tagvN，這樣針對相同的metric去加tag，用來標示數(shù)據(jù)，方便后期的查詢。
{
"0_1_12": 0,
"0_1_13": 0,
"0_1_10": 0,
"0_1_11": 0,
"0_1_4": 0,
"0_1_5": 0,
"0_1_6": 0,
"0_1_7": 0,
"0_1_0": 0,
"0_1_1": 0,
"0_1_2": 0,
"0_1_3": 0,
"0_1_8": 0,
"0_1_9": 0
}
第二個例子是 Nginx 的訪問狀態(tài)的數(shù)據(jù)采集 ：
第一列是http請求的狀態(tài)，第二列是計數(shù)器
{
"200": 29312,
"404": 0,
"499": 60,
"412": 0,
"400": 114,
"502": 0,
"408": 179
}
2. 監(jiān)控數(shù)據(jù)存儲
監(jiān)控數(shù)據(jù)的存儲也是一個很有意思的話題，監(jiān)控數(shù)據(jù)在數(shù)據(jù)結(jié)構(gòu)上是很有特色的。仔細觀察發(fā)現(xiàn)監(jiān)控數(shù)據(jù)基本上都是和時間維度相關(guān)的，以metric + timestamp 的組合形式的數(shù)據(jù)占了所有監(jiān)控數(shù)據(jù)量的大部分，相比而言，多維度的監(jiān)控數(shù)據(jù)比較少;如果出現(xiàn)了多維度的監(jiān)控數(shù)據(jù)，也可以通過其他的方式繞開處理。 RDBMS由于要考慮數(shù)據(jù)的關(guān)聯(lián)，所以它在整體數(shù)據(jù)存儲設計上充分考慮了數(shù)據(jù)的完整性和關(guān)系型，同時在 schema設計上還要遵守數(shù)據(jù)庫的幾大范式。傳統(tǒng)的監(jiān)控大多數(shù)還是使用了RDBMS，但是這造成了性能上和擴展性上的局限性。針對監(jiān)控數(shù)據(jù)這樣簡單的數(shù)據(jù)結(jié)構(gòu)，卻采用了一套復雜的存儲格式。隨著近些年各種各樣的垂直的
技術(shù)領(lǐng)域?qū)?shù)據(jù)的存儲不同要求的演變，如Graph database，Time Series Databases等數(shù)據(jù)庫得到了不斷發(fā)展;監(jiān)控數(shù)據(jù)在存儲上有了更多的選擇，InfluxDB，OpenTSDB，KairosDB都是不錯的選擇，最后我們選擇了OpenTSDB，這主要是因為TalkingData的大數(shù)據(jù)基因，Hadoop和HBase在我們的業(yè)務系統(tǒng)中大規(guī)模使用。從現(xiàn)有的數(shù)據(jù)體量上，OpenTSDB能夠滿足現(xiàn)在的業(yè)務要求。簡單的總結(jié)了一下OpenTSDB的優(yōu)點：
使用HBase存儲，不存在單點故障。
使用HBase存儲，存儲空間幾乎無限。支持永久存儲，可以做容量規(guī)劃。
易于定制圖形
能擴展采集數(shù)據(jù)點到100億級。
能擴展metrics數(shù)量到K級別(比如CPU的使用情況，可以算作一個metric，即metric就是1個監(jiān)控項)