2011年、2012年我在PPTV剛開始工作的時(shí)候，第一個(gè)開始涉及的工作就是監(jiān)控系統(tǒng)。當(dāng)時(shí)和我的老板陳文春（現(xiàn)在應(yīng)該是新浪的總經(jīng)理吧，好厲害）一起在Nagios和Zabbix中選型，當(dāng)時(shí)覺得Nagios有各種各樣的插件，功能很強(qiáng)大，但相應(yīng)地配置麻煩，比如畫圖需要cacti配合。而Zabbix看上去是一個(gè)一步到位能解決所有問題的工具，雖然界面有點(diǎn)丑，但能滿足我們的需求：畫圖、報(bào)警收集數(shù)據(jù)等。近年來的發(fā)展趨勢(shì)，Zabbix比Nagios更加流行，我看了下Google Trends，Nagios的熱度在緩慢下降，而Zabbix的熱度在上升：

在Zabbix所監(jiān)控的服務(wù)器越來越多情況下，對(duì)Zabbix的性能要求也越來越高。因?yàn)閳F(tuán)隊(duì)中大家對(duì)Oracle有更多的了解，我們Zabbix后端使用的數(shù)據(jù)庫也是Oracle，這個(gè)應(yīng)該是比較少見的，因?yàn)槲伊私庀聛砟壳翱隙ㄊ荕ySQL更加流行（其實(shí)PPTV后來也換成了MySQL）。

在當(dāng)時(shí)Zabbix功能還不是非常強(qiáng)大，有很多需求沒法滿足。這種情況下我們圍繞Zabbix做了很多的工作：

• 開發(fā)了添加監(jiān)控時(shí)使用的工具Spider，原理很簡單：根據(jù)不同的規(guī)則，在將一臺(tái)服務(wù)器添加到Zabbix監(jiān)控時(shí)，會(huì)根據(jù)服務(wù)器上運(yùn)行的進(jìn)程，或者h(yuǎn)ostname（PPTV的hostname中有服務(wù)器所屬業(yè)務(wù)的信息）來添加對(duì)應(yīng)的監(jiān)控；

• 重新開發(fā)了Zabbix的Screen功能，支持更加方便組合需要的監(jiān)控?cái)?shù)據(jù)，因?yàn)閆abbix自帶的Screen功能配置比較麻煩；

• 當(dāng)出現(xiàn)報(bào)警的時(shí)候，Zabbix只負(fù)責(zé)將報(bào)警的信息推送出來，由我們自己開發(fā)的工具，根據(jù)Zabbix的信息，重新組合報(bào)警信息，將這一報(bào)警事件展現(xiàn)到報(bào)警平臺(tái)中，并且將更加詳細(xì)的報(bào)警郵件發(fā)送到CMDB中對(duì)應(yīng)的負(fù)責(zé)人那。這樣可以做到每一個(gè)報(bào)警事件的認(rèn)領(lǐng)，追蹤和解決。對(duì)于一些報(bào)警，郵件中能有初步的分析，工程師收到郵件就能大概知道問題發(fā)生的地方；

• 從代碼入手，解決了Zabbix在Oracle中執(zhí)行SQL的一些性能問題；

• 使用Nagios監(jiān)控Zabbix Master和Proxy的Update Percent，這個(gè)指的意義是過去一段時(shí)間內(nèi)，有百分之多少的數(shù)據(jù)更新了。這個(gè)數(shù)據(jù)能很好地反應(yīng)Master和Proxy的健康程度。

總結(jié)一下，我們?cè)谶@幾方面做了開發(fā)：

• 更全面的收集監(jiān)控?cái)?shù)據(jù)；

• 更好的展現(xiàn)監(jiān)控?cái)?shù)據(jù)；

• 梳理了報(bào)警的流程和操作；

• 優(yōu)化后端數(shù)據(jù)存儲(chǔ)的性能問題（主要是寫的性能）；

• 提高Zabbix的可用性。

現(xiàn)狀

在離開PPTV加入唯品會(huì)后，我基本沒有很深入地去做Zabbix工作，除了做了一個(gè)Zabbix Lastvalue的patch。簡單介紹下這個(gè)Patch，Zabbix對(duì)于每一個(gè)監(jiān)控項(xiàng)，會(huì)在一張表中保存這個(gè)監(jiān)控項(xiàng)最近一次的取值，有了這個(gè)指標(biāo)，可以方便做一些二次開發(fā)。而在Zabbix 2.2（印象中是這個(gè)版本），這一列取消了，而我做的Lastvalue的patch，就是讓Zabbix在將監(jiān)控?cái)?shù)據(jù)寫入數(shù)據(jù)庫的同時(shí)，再寫一份到一張新的表，而這張表，就是原來Lastvalue的功能，這里要特別感謝唯品會(huì)的聶超和侯瑞，解決了C的內(nèi)存泄露問題。

一直到現(xiàn)在，五年間，有很多身邊的同事，或者網(wǎng)絡(luò)上的朋友在做監(jiān)控系統(tǒng)的開發(fā)，而我也在關(guān)注監(jiān)控系統(tǒng)的發(fā)展。我發(fā)現(xiàn)，對(duì)于監(jiān)控系統(tǒng)，大家可能有一些錯(cuò)誤的認(rèn)識(shí)，有的同學(xué)自己寫了一個(gè)收集系統(tǒng)數(shù)據(jù)的工具，然后數(shù)據(jù)往后端發(fā)送，再做一些數(shù)據(jù)可視化的工作，這也是“監(jiān)控系統(tǒng)”。對(duì)于這些造輪子的行為，這里不做具體的評(píng)價(jià)，因?yàn)樗鼈兇_實(shí)能解決一些問題，但總的來說，和Zabbix（或者其他監(jiān)控系統(tǒng)）的區(qū)別是不大的，自己重新開發(fā)一套沒有什么必要。而且，Zabbix是這么多年時(shí)間、這么多優(yōu)秀工程師一起努力的結(jié)果，不是這么容易就能開發(fā)一套比Zabbix做的更好的產(chǎn)品。我甚至見過，所有思想全部抄襲Zabbix，比如Dashboard的設(shè)計(jì)：報(bào)警的級(jí)別、觸發(fā)器表達(dá)式的格式，和Zabbix幾乎一致，老板甚至還覺得不錯(cuò)。

Zabbix或者類似的開源產(chǎn)品存在著很多問題，我列舉一下：

1. 使用TSDB或者NoSQL來解決監(jiān)控?cái)?shù)據(jù)的存儲(chǔ)問題；

2. 將大數(shù)據(jù)的解決方案引入監(jiān)控系統(tǒng)，增強(qiáng)監(jiān)控系統(tǒng)的可擴(kuò)展性，比如Storm，Spark，Kafka等；

3. 使用機(jī)器學(xué)習(xí)來改進(jìn)報(bào)警準(zhǔn)確性的問題，比如觸發(fā)報(bào)警的條件，報(bào)警事件的聚合等；

4. 將前端界面開發(fā)得更漂亮一點(diǎn)。

可以看到，上面4點(diǎn)，最簡單的就是第4點(diǎn)了，所以有很多工程師在這個(gè)上面做文章，我個(gè)人認(rèn)為，目前監(jiān)控系統(tǒng)的最大問題是第1點(diǎn)——數(shù)據(jù)的存儲(chǔ)問題。監(jiān)控?cái)?shù)據(jù)的量會(huì)非常大，假設(shè)我們有10k臺(tái)服務(wù)器，每個(gè)機(jī)器有50個(gè)監(jiān)控點(diǎn)，那最壞的情況，需要每秒處理500k個(gè)請(qǐng)求。如果不做任何優(yōu)化，500k每秒的寫入壓力，就算對(duì)于大數(shù)據(jù)的實(shí)時(shí)計(jì)算，也是很大的壓力。另一方面，監(jiān)控?cái)?shù)據(jù)的讀取也很有特點(diǎn)，經(jīng)常會(huì)讀取很長一段時(shí)間的數(shù)據(jù)，比如我想查看一個(gè)監(jiān)控?cái)?shù)據(jù)在過去一個(gè)月的數(shù)據(jù)，那映射到數(shù)據(jù)存儲(chǔ)層，會(huì)需要掃描非常多的數(shù)據(jù)?？赡軓暮蠖朔祷氐臄?shù)據(jù)量會(huì)非常大。

由于數(shù)據(jù)庫的性能不佳，可能會(huì)造成部署多套監(jiān)控系統(tǒng)的情況，這樣在讀取數(shù)據(jù)、做聚合分析時(shí)有很大的難度。當(dāng)然，也可以在多個(gè)數(shù)據(jù)庫的上層開發(fā)一個(gè)統(tǒng)一的API，這就有點(diǎn)像TDDL了，難度很大。

對(duì)于第2點(diǎn)和第3點(diǎn)，如果我們能解決第1點(diǎn)，并且我們已經(jīng)習(xí)慣了目前監(jiān)控系統(tǒng)處理監(jiān)控?cái)?shù)據(jù)的架構(gòu)以及報(bào)警方式，我覺得這兩點(diǎn)給我們帶來的痛點(diǎn)還在可接受范圍內(nèi)。而對(duì)于第4點(diǎn)，雖然說數(shù)據(jù)可視化是數(shù)據(jù)處理整個(gè)流程中非常重要的一環(huán)，但它的重要性遠(yuǎn)不及上面幾點(diǎn)。

怎么造輪子

用開源產(chǎn)品做二次開發(fā)？還是自己造輪子？我覺得需要根據(jù)具體的需求，但可以確定的是，當(dāng)你決定自己造輪子時(shí)，80%的情況下，開源產(chǎn)品是能滿足你的需求的。記得有句話是講NoSQL的，大意是：當(dāng)你想要NoSQL的時(shí)候，80%的情況下MySQL就能解決你的問題。

我覺得只有在我們已經(jīng)非常了解一個(gè)開源產(chǎn)品并且用透了（半年以上）的情況下，如果確實(shí)不滿足我們的需求，那么可以對(duì)其他類似產(chǎn)品，和其他公司的解決方案進(jìn)行調(diào)研，看看大家的解決方案，因?yàn)楹苡锌赡芪覀儾⒉皇堑谝粋€(gè)想造輪子的人（如果你是第一個(gè)想造輪子的則需要更加謹(jǐn)慎，想想為什么其他人都不造輪子呢？）。

如果已經(jīng)決定造輪子了（再次提醒各位，80%的情況下你是不必造輪子的），那要搞清楚造輪子的方向，不要只把原有產(chǎn)品的一個(gè)小部分非關(guān)鍵組件自己開發(fā)了就是造輪子，然后就沾沾自喜，認(rèn)為自己把輪子造完了。

回到這篇文章想和大家聊的監(jiān)控系統(tǒng)，我在前文說過，監(jiān)控系統(tǒng)目前的問題，有幾個(gè)：

• 監(jiān)控?cái)?shù)據(jù)這種時(shí)間序列數(shù)據(jù)的存儲(chǔ)；

• 報(bào)警的優(yōu)化，包括報(bào)警準(zhǔn)確性和報(bào)警的關(guān)聯(lián)；

• 監(jiān)控系統(tǒng)的可擴(kuò)展性，要支持監(jiān)控點(diǎn)增多后的水平擴(kuò)展。

下面我們分別從這三個(gè)部分來做些簡單的介紹。

時(shí)間序列數(shù)據(jù)

傳統(tǒng)的監(jiān)控系統(tǒng)會(huì)將監(jiān)控?cái)?shù)據(jù)存儲(chǔ)到傳統(tǒng)的RDBMS，比如最常見的MySQL。我們先等會(huì)說這個(gè)做法是否合適，先看看時(shí)間序列數(shù)據(jù)是怎樣的。時(shí)間序列數(shù)據(jù)（Time Series Data）是一系列以時(shí)間序列為順序的數(shù)據(jù)。比如監(jiān)控系統(tǒng)中，一段時(shí)間內(nèi)某一臺(tái)服務(wù)器的CPU Load的值，是一個(gè)時(shí)間序列數(shù)據(jù)。這個(gè)時(shí)間序列數(shù)據(jù)中，包含幾個(gè)隱含的條件：“某一臺(tái)”，“CPU Load”，“值”，還有就是時(shí)間。所以可以這么說，“某一臺(tái)”服務(wù)器的“CPU Load”這個(gè)數(shù)據(jù)在某一個(gè)時(shí)間的“值”是XX。我們更加抽象一點(diǎn)：

TIMESTAMP, METRICS, TAGS={K1: V1, K2,: V2,…}, FIELDS={F1: V1, F2: V2,…}

時(shí)間序列數(shù)據(jù)有個(gè)特點(diǎn)，TAGS和FIELDS里面有多少個(gè)Key-Value是不能確定的。也就是說數(shù)據(jù)的Schema是不確定的，那么我們用MySQL去存儲(chǔ)時(shí)間序列數(shù)據(jù)是否合適呢？我們都知道MySQL任何一張表都需要事先去定義表結(jié)構(gòu)。

我們得出一個(gè)結(jié)論，傳統(tǒng)的RDBMS不是存儲(chǔ)時(shí)間序列數(shù)據(jù)的，我們需要專門的時(shí)間序列數(shù)據(jù)庫——Time Series DataBase，即TSDB。

目前比較流行的有基于HBase的OpenTSDB。HBase的存儲(chǔ)方式是列式的，這個(gè)特性對(duì)時(shí)間序列數(shù)據(jù)的讀取很有好處，因?yàn)橄嗤琈etrics一段時(shí)間內(nèi)的數(shù)據(jù)在磁盤上都存儲(chǔ)在一起，讀取性能會(huì)很好。但在使用過程中會(huì)發(fā)現(xiàn)：當(dāng)TAG數(shù)目比較多時(shí)，性能會(huì)非常差，而且整個(gè)HBase的搭建和維護(hù)比較麻煩。

當(dāng)前更加流行的開源產(chǎn)品有InfluxDB，Prometheus和Netflix的atlas，未開源產(chǎn)品有Twitter的Manhattan。我們現(xiàn)在主要使用InfluxDB，它是用Golang寫的，根據(jù)官方的benchmark，讀寫性能和數(shù)據(jù)壓縮都大幅領(lǐng)先當(dāng)前的產(chǎn)品。并且它支持類似SQL語法的數(shù)據(jù)查詢語言，使用起來非常方便。

機(jī)器學(xué)習(xí)的引入

監(jiān)控系統(tǒng)的最大價(jià)值就是將故障準(zhǔn)確地通知出來，但現(xiàn)實(shí)情況中卻有非常多的誤報(bào)以及頻繁的調(diào)節(jié)閾值。關(guān)于使用機(jī)器學(xué)習(xí)來調(diào)整閾值的研究，已經(jīng)在上一期《程序員》中做了簡單的分享，最核心的思想就是根據(jù)數(shù)據(jù)的歷史，來做一些未來數(shù)據(jù)的預(yù)測(cè)。

另一方面，報(bào)警事件的關(guān)聯(lián)其實(shí)也是非常有趣的事情，比如一臺(tái)服務(wù)器上面的磁盤空間滿了，同時(shí)，這臺(tái)服務(wù)器上運(yùn)行的MySQL也失去響應(yīng)了，這兩個(gè)報(bào)警，是不是可以認(rèn)為是一個(gè)相互關(guān)聯(lián)的事件呢？這方面我的研究不多，但這個(gè)問題是確實(shí)存在的。我的想法是，系統(tǒng)在初始情況下，所有的報(bào)警事件是沒有關(guān)聯(lián)的，經(jīng)過一些“專家”的訓(xùn)練（比如將兩件報(bào)警事件人為的關(guān)聯(lián)），當(dāng)下次這兩個(gè)報(bào)警事件再同時(shí)出現(xiàn)時(shí)，系統(tǒng)就會(huì)提示這些關(guān)聯(lián)的關(guān)系。

監(jiān)控系統(tǒng)的分布式架構(gòu)

監(jiān)控系統(tǒng)在發(fā)展過程中都非常喜歡將所有的時(shí)間放在自己這，比如數(shù)據(jù)的傳輸、計(jì)算之類。例如Zabbix就自己實(shí)現(xiàn)了數(shù)據(jù)的隊(duì)列、緩存以及數(shù)據(jù)是否需要報(bào)警的邏輯處理，其實(shí)這些如果能交給大數(shù)據(jù)組件來解決，應(yīng)該是更好的選擇。當(dāng)規(guī)模足夠大以后，監(jiān)控系統(tǒng)所面對(duì)的場(chǎng)景就是大數(shù)據(jù)的場(chǎng)景——海量數(shù)據(jù)的傳輸、計(jì)算和存儲(chǔ)。專業(yè)的事情交給專業(yè)的平臺(tái)來做，這樣更合適。

結(jié)合上面三點(diǎn)，我認(rèn)為，監(jiān)控系統(tǒng)應(yīng)該專注在如何讓監(jiān)控更準(zhǔn)確、更智能，而數(shù)據(jù)的計(jì)算、傳輸?shù)扔么髷?shù)據(jù)的工具來解決。這樣，監(jiān)控系統(tǒng)會(huì)有更強(qiáng)大的生命力。