寫在前面

之前文章中講到筆者想要實現(xiàn)一個新的監(jiān)控系統(tǒng)，原文地址。細(xì)思之，重做一遍Open-Falcon并沒有意義。所以新的系統(tǒng)會從Open-Falcon借鑒很多東西，但是理念不會相同，我稱之為下一代監(jiān)控系統(tǒng)，那也是有點標(biāo)題黨了，未來的服務(wù)很可能會全部container化，這里所謂的下一代監(jiān)控系統(tǒng)，就會著眼于container化的服務(wù)監(jiān)控。

以前做部署做PaaS，搞了個DINP算是一個總結(jié)，這次做監(jiān)控，也手寫一套出來，算是個總結(jié)。

叫個什么名字呢？其實特別想叫Minos，Minos是希臘神話中的判官，跟監(jiān)控系統(tǒng)有點貼切，但是github上沒法注冊這個organization了，只能加個open的前綴叫做Open-Minos，湊合著用吧，代碼還沒開始寫，你有好名字么？給筆者參考參考唄~

重大改變

下面先闡述一些與Open-Falcon不同的地方，這些改變都有一些考量，要么是為了簡化系統(tǒng)，要么是為了去除單點，要么是為了便于運維，要么，是因為我個人的偏執(zhí)，哈哈

干掉HostGroup

閹割掉了機器分組和策略模板！聽起來可真不是個好消息，重大改變，反而是做了閹割。

*我的腦洞歷程是這樣的

策略表達式在Open-Falcon中只能配置一條規(guī)則，太弱了，加強之。可以支持配置多條規(guī)則，相同metric，tags長的覆蓋tags短的。這樣用起來就比較爽了，普通dev再也不用去關(guān)心機器分組，不用去關(guān)心策略模板，不用去關(guān)心復(fù)雜的繼承關(guān)系。

策略表達式做強大了之后，機器是否也可以用策略表達式來監(jiān)控呢？

其實是可以的，機器監(jiān)控數(shù)據(jù)匯報的時候帶上業(yè)務(wù)tags即可。比如minos這個項目用到了20臺機器，每個機器采集了監(jiān)控指標(biāo)之后，都額外帶上這么一個tag：project=minos,host=xx，這樣就可以在web端做如下配置來監(jiān)控所有機器的cpu.idle：

metric=cpu.idle project=minos all(#2) < 5

這種做法特別適合那些使用container來部署服務(wù)的公司，因為每個container都是唯一服務(wù)于一個業(yè)務(wù)，方便打上業(yè)務(wù)的tags。據(jù)說美團的虛機做得特別好，業(yè)務(wù)沒有混部，基本也是一臺虛機只屬于一個業(yè)務(wù)，這種場景也比較容易打上業(yè)務(wù)tags。比較麻煩的情況是一個機器部署了多個服務(wù)，不同的團隊收同一批機器的報警，這個大家有好辦法解決么？這里先賣個關(guān)子，我的辦法先不透露，防止限制了你的思路。

變更Data Model

endpoint不再單獨一個字段，如果需要endpoint，放到tags中，這樣做簡化了系統(tǒng)，與OpenTSDB的做法一致。endpoint其實也是一種篩選數(shù)據(jù)的手段，放到tags中，處理起來就變得一致了。

數(shù)據(jù)存儲放棄RRD

RRD是文件系統(tǒng)，處理起來速度比較快，但是不易運維，現(xiàn)在的每個Graph實例都是單點真的是讓我如鯁在喉。以前用的zabbix是采用數(shù)據(jù)庫存放歷史數(shù)據(jù)的，history表和trends表其實還不是瓶頸，瓶頸會先出在存放last數(shù)據(jù)的表。

那么如果我們做一些分庫分表的手段，MySQL也可以抗非常大的量，而業(yè)界MySQL的運維，已經(jīng)是非常成熟，這是一個極大的優(yōu)點。

使用Team貫穿整個系統(tǒng)的權(quán)限

用戶注冊登錄進來之后，可以創(chuàng)建Team，這個跟以前的UIC差不多。然后，所有的東西都是與Team掛鉤的，比如報警策略，隸屬于某個Team；上傳的數(shù)據(jù)，隸屬于某個Team；報警事件，也是某個Team來處理。

組件瘦身

所有組件采用Go編寫，編譯完成之后一個二進制，扔到任何一臺機器上都可以跑，組件該合并的合并。

Frontend

首先肯定是需要有個web端，提供用戶登錄、注冊功能，團隊維護，報警策略維護，未恢復(fù)的報警查看，歷史趨勢圖表查看等等。也就是把以前的多個web端合并在一起了。

數(shù)據(jù)也push給Frontend，通過http的方式。每個Team有個token，數(shù)據(jù)push的時候要帶上這個token，用來做安全防護，另外就是數(shù)據(jù)就和某個Team關(guān)聯(lián)起來了。

Frontend可以水平擴展，無狀態(tài)。

Backend

Frontend拿到數(shù)據(jù)之后，通過一致性哈希打到后端多個Backend組件，這樣就可以做到，某個Backend只處理整個集群的一小部分?jǐn)?shù)據(jù)，可以在內(nèi)存中有針對性的做一些緩存之類的。

Backend要去判斷報警，寫索引庫，寫歷史數(shù)據(jù)，做歸檔。重要的活計都是交給Backend來做了，那某Backend實例掛了怎么辦？Frontend會感知到，然后踢掉掛了的Backend實例，重做hash環(huán)即可。

Backend可以很輕易的擴容，F(xiàn)rontend也可以很快感知，兩個組件之間有心跳機制。這樣一來，Backend也沒有單點風(fēng)險。

MySQL

Open-Minos嚴(yán)重依賴MySQL，首先會從業(yè)務(wù)上分庫，用來給Frontend組件存放基礎(chǔ)信息的frontend庫，用來存放索引的indexes庫，用來存放報警歷史事件的events庫，用來存放心跳信息的naming庫，最后是存放歷史數(shù)據(jù)的history庫。我們的數(shù)據(jù)上來之后會寫索引庫，產(chǎn)生一個自增ID，根據(jù)自增ID去分庫分表即可。

Redis

報警事件仍然采用Redis存儲，Redis的高可用，筆者思考準(zhǔn)備在前面架設(shè)一個四層負(fù)載均衡，兩個Redis一主一備，備是冷備，外加一個keepalive腳本放在備機，不斷去探測主是不是掛了，主掛了，啟動備。

Redis的作用類似一個隊列，此處的報警事件需要有個alarm組件來處理，但是我們也可以輕松引入其他consumer，通過redis做多個隊列，代碼中實現(xiàn)多播即可。

為什么沒有引入專門的MQ呢？為了簡化系統(tǒng)。

Alarm

處理報警事件，發(fā)送報警，可以水平擴展，因為閹割了報警合并功能。

Housekeeper

最后一個組件，家庭主婦，負(fù)責(zé)清理老舊數(shù)據(jù)。單點，但是掛個幾天無所謂。記得再把她起來即可。

嗯，看起來應(yīng)該是可以走通，也能處理比較大的數(shù)據(jù)量。如果你們公司監(jiān)控數(shù)據(jù)實在太大，每個周期幾十億條，可以考慮部署多套Open-Minos，只有這幾個組件的話，應(yīng)該不用10分鐘就可以搭建起來一套吧，O(∩_∩)O~

*更新
我現(xiàn)在覺得部署多套其實是個挺好的方案，比如miui這個部門的sre部署一套，給miui的dev使用；duokan這個部門的sre部署一套給duokan的dev使用；這些dev相互之間根本沒有交集，不同的部門單獨一套，還可以有針對性的做一些二次開發(fā)。

那這樣一來維護成本是不是就高了？那要看Open-Minos做得是不是易于維護了，呵呵。