《鳳凰網(wǎng)：基于服務(wù)樹的監(jiān)控系統(tǒng)實(shí)踐》要點(diǎn)：
本文介紹了鳳凰網(wǎng)：基于服務(wù)樹的監(jiān)控系統(tǒng)實(shí)踐，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

作者介紹

kun：鳳凰網(wǎng)運(yùn)維開發(fā),負(fù)責(zé)公司運(yùn)維自動(dòng)化平臺(tái)設(shè)計(jì)開發(fā),InfluxDB contributer、open-falcon contributer 、golang愛(ài)好者.

一、傳統(tǒng)監(jiān)控系統(tǒng)的困擾

說(shuō)到監(jiān)控,大家肯定能列舉不少,zabbix、nagios、open-falcon、Prometheus等.鳳凰網(wǎng)和其他大多數(shù)互聯(lián)網(wǎng)公司一樣,一開始選擇了開源的zabbix來(lái)做為公司的監(jiān)控系統(tǒng).就這樣,相安無(wú)事,多年過(guò)去了.隨著公司服務(wù)器的不斷增長(zhǎng),我們遇到了一些難題：

1. 當(dāng)服務(wù)器量級(jí)達(dá)到3000左右時(shí),監(jiān)控?cái)?shù)據(jù)存儲(chǔ)和查詢遇到瓶頸.
2. 業(yè)務(wù)上報(bào)監(jiān)控系統(tǒng)不方便,沒(méi)有相應(yīng)的接口或SDK.
3. zabbix中的組概念沒(méi)有層次和依賴關(guān)系,不利于服務(wù)治理.
4. 一些定制化的監(jiān)控需求難以滿足(集群監(jiān)控等).

相信第一個(gè)問(wèn)題很多體量稍大的公司都遇到過(guò),大家用得最多的一個(gè)解決方案是拆分zabbix,部署多套來(lái)分擔(dān)壓力.但是后端查詢過(guò)慢的問(wèn)題沒(méi)有從根本上解決,而且增加了維護(hù)成本,考慮到zabbix后端是c語(yǔ)言寫的,二次開發(fā)有一定難度,于是我們打算自己造個(gè)輪子.

二、自建監(jiān)控系統(tǒng)需求分析

2.1關(guān)于服務(wù)樹

先簡(jiǎn)單介紹下幾個(gè)概念：

服務(wù)樹：某些公司為了方便管理服務(wù)集群,利用樹形結(jié)構(gòu)建立起了一種服務(wù)組織關(guān)系,方便集群 ? ? ? ? ?服務(wù)治理,以服務(wù)集群節(jié)點(diǎn)為管理單元,而不是某臺(tái)機(jī)器.

Open-Falcon：是小米開源的一套分布式高性能監(jiān)控系統(tǒng),支持服務(wù)樹管理.

有人可能會(huì)問(wèn),你們?yōu)槭裁床恢苯佑瞄_源的 open-falcon ,不得不承認(rèn), open-falcon 的某些設(shè)計(jì)還是非常不錯(cuò)的,我們也從中學(xué)習(xí)了很多思路.但是由于小米公司當(dāng)時(shí)沒(méi)有開源出結(jié)合監(jiān)控的服務(wù)樹,我們不得不自己設(shè)計(jì)一套適合自己,也可能適合你的服務(wù)樹.

基于服務(wù)樹,我們可以更方便的管理自己的服務(wù), 服務(wù)樹是整個(gè)監(jiān)控系統(tǒng)的基礎(chǔ)服務(wù),后來(lái)我們開發(fā)的發(fā)布系統(tǒng)也是基于服務(wù)樹實(shí)現(xiàn)的.基于 golang 的運(yùn)維友好性和高性能,整個(gè)服務(wù)樹是用 golang 實(shí)現(xiàn)的,對(duì)于新手來(lái)說(shuō),上手難度也不高.服務(wù)樹架構(gòu)圖如下：

服務(wù)樹架構(gòu)圖

2.2關(guān)于高可用

考慮到服務(wù)樹(service registry)組件的重要性,架構(gòu)上一定是高可用的,于是我們底層數(shù)據(jù)存儲(chǔ) store 層多實(shí)例是基于 raft 算法保證數(shù)據(jù)一致性的,最底層是用了 boltDB 來(lái)存儲(chǔ)服務(wù)樹的數(shù)據(jù),另外為了提高服務(wù)樹的讀性能我們還為 store 層添加了支持 lru 算法的 cache 模塊, cache 結(jié)構(gòu)體如下：

// Cache implements a non-thread safe fixed size LRU cache. type Cache struct { ? ?mu ? ? ? ?sync.RWMutex ? ?count ? ? int ? ?evictList *list.List ? ?items ? ? map[string]map[string]*list.Element ? ?size ? ?uint64 ? ?maxSize uint64 ? ?enable bool ? ?logger *log.Logger }

在啟動(dòng)服務(wù)樹的時(shí)候,我們可以指定服務(wù)樹開啟的內(nèi)存大小,現(xiàn)在我們開啟了 50M , 效果還是非常不錯(cuò)的.

2.3關(guān)于擴(kuò)展性

如果你啟動(dòng)了 3 個(gè)實(shí)例,正常情況下 raft 底層是有一個(gè) leader 和兩個(gè) follower 的,寫操作必須落在 leader 上才能成功,很多開源軟件也都是這樣的,但是這樣服務(wù)樹就有狀態(tài)了,對(duì)于用戶提交數(shù)據(jù)不是特別友好.

于是我們?cè)?cluster 這一層會(huì)做判斷,如果進(jìn)來(lái)一個(gè)寫操作,直接嘗試本機(jī),如果失敗了,再把請(qǐng)求轉(zhuǎn)發(fā)到 leader 上,底層幫助用戶做數(shù)據(jù)轉(zhuǎn)發(fā),這樣用戶不用關(guān)心那個(gè)是 leader ,3臺(tái)對(duì)他來(lái)說(shuō)是一樣的,前端加個(gè)負(fù)載均衡可以隨便接受請(qǐng)求了.

在這里我們底層還做了一些工作,就是把 cluster 監(jiān)聽的 TCP 端口和 raft 數(shù)據(jù)同步的端口復(fù)用,這樣,用戶的配置也就精簡(jiǎn)了.

另外服務(wù)器可以根據(jù)一定策略自動(dòng)注冊(cè)到服務(wù)樹上的某個(gè)服務(wù)節(jié)點(diǎn)當(dāng)中,機(jī)器,報(bào)警,權(quán)限在服務(wù)中都是一種資源,這種資源都有增刪改查的操作,對(duì)于服務(wù)樹來(lái)說(shuō)這些沒(méi)有什么區(qū)別,只是人定義了它,服務(wù)樹中一切皆資源,后期擴(kuò)展極為方便.

2.4關(guān)于性能

zabbix 很大的一個(gè)問(wèn)題就是用結(jié)構(gòu)型數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)了時(shí)序性數(shù)據(jù).考慮到整個(gè)監(jiān)控系統(tǒng)的配置數(shù)據(jù)和監(jiān)控指標(biāo)數(shù)據(jù)是有不同特點(diǎn)的：

• 配置數(shù)據(jù)：量小、讀取頻繁、可用性要求高
• 監(jiān)控?cái)?shù)據(jù)：量大、讀取冷熱分明、可用性要求高

可以考慮把監(jiān)控配置數(shù)據(jù)抽象城資源存儲(chǔ)到服務(wù)樹中,保證數(shù)據(jù)可用性,而對(duì)于監(jiān)控指標(biāo)數(shù)據(jù)可以存儲(chǔ)到時(shí)序性數(shù)據(jù)庫(kù)當(dāng)中,開源的有 OpenTSDB、InfluxDB、Prometheus等.

2.5關(guān)于業(yè)務(wù)數(shù)據(jù)上報(bào)

業(yè)務(wù)上有越來(lái)越多上報(bào)打點(diǎn)需求,我們可以考慮從 agent 端開放出接口,把業(yè)務(wù)上報(bào)的數(shù)據(jù)作為普通數(shù)據(jù)一起打包入庫(kù),這樣也復(fù)用了監(jiān)控系統(tǒng)數(shù)據(jù)傳遞的整條鏈路,同時(shí)降低了系統(tǒng)維護(hù)難度.對(duì)于一些標(biāo)準(zhǔn)的基礎(chǔ)服務(wù)采集,我們采用插件的方式來(lái)實(shí)現(xiàn),在 zabbix 中叫模板,比如 nginx 的一些指標(biāo), mysql 的一些指標(biāo)等.

三、自建監(jiān)控系統(tǒng)構(gòu)建

設(shè)計(jì)需求分析完了,關(guān)于鳳凰網(wǎng)的監(jiān)控架構(gòu),我們先上架構(gòu)圖：

3.1系統(tǒng)數(shù)據(jù)流

服務(wù)器通過(guò)拉取服務(wù)樹的用戶配置采集策略,通過(guò)部署的agent進(jìn)行監(jiān)控?cái)?shù)據(jù)采集上報(bào),每個(gè)IDC內(nèi)部會(huì)有一個(gè)消息隊(duì)列防止公網(wǎng)傳輸延遲或丟數(shù)據(jù),數(shù)據(jù)會(huì)進(jìn)入消息隊(duì)列,然后會(huì)有router模塊負(fù)責(zé)把數(shù)據(jù)寫入到InfluxDB中.

由于InfluxDB已經(jīng)閉源了集群功能,為了保證后端數(shù)據(jù)的高可用,我們通過(guò)router進(jìn)行多寫.受限于大量的寫入請(qǐng)求,我們通過(guò)router對(duì)后端InfluxDB做了分片,這樣當(dāng)后端某個(gè)db出問(wèn)題時(shí),不至于影響其他服務(wù)數(shù)據(jù)寫入和報(bào)警.

報(bào)警我們用了開源的kapacitor,為了提高用戶易用性,我們圍繞它做了一些改進(jìn),也在支持了監(jiān)控指標(biāo)的無(wú)值監(jiān)控.

3.2各模塊功能

• agent：采集服務(wù)器上的各種資源監(jiān)控指標(biāo)
• registry：服務(wù)樹,管理各種采集,報(bào)警策略
• MQ：消息隊(duì)列,負(fù)責(zé)數(shù)據(jù)緩沖和容錯(cuò)
• router：后端數(shù)據(jù)的讀寫入口,負(fù)責(zé)數(shù)據(jù)分片和多寫
• InfluxDB：開源的時(shí)序數(shù)據(jù)庫(kù)
• Alarm：報(bào)警組件,負(fù)責(zé)向各渠道下發(fā)報(bào)警消息,報(bào)警屏蔽和報(bào)警收斂等

3.3為什么選擇InfluxDB

InfluxDB是一個(gè)時(shí)序數(shù)據(jù)庫(kù),為時(shí)序數(shù)據(jù)而生,它新版的TSM存儲(chǔ)引擎性能非常好,數(shù)據(jù)壓縮做的非常好.

舉個(gè)例子,2000臺(tái)左右服務(wù)器,100天數(shù)據(jù)占用400G空間.面對(duì)10s級(jí)別的上報(bào)采集頻率,這個(gè)成績(jī)是非常不錯(cuò)的.

目前,監(jiān)控系統(tǒng)大部分監(jiān)控項(xiàng)是10秒級(jí)的上報(bào)粒度,InfluxDB的每秒寫入5w.每天入庫(kù)的數(shù)據(jù)點(diǎn)10億.

四、Highlight

agent原生支持Windows,開源社區(qū)支持linux做的比較好,但是我們公司有些微軟的服務(wù)(exchange)是windows服務(wù)器,于是我們做了很多工作來(lái)原生支持win系統(tǒng),

支持windows的相關(guān)源文件

支持第三方打點(diǎn)上報(bào),方便開發(fā)接入監(jiān)控系統(tǒng),我認(rèn)為這個(gè)已經(jīng)是現(xiàn)在監(jiān)控系統(tǒng)的標(biāo)配了.

監(jiān)控上報(bào)

插件庫(kù)支持豐富,得益于開源社區(qū),支持插件監(jiān)控,擁有完善的插件庫(kù)

相關(guān)插件

更優(yōu)化的圖像展示速度,在長(zhǎng)時(shí)間跨度查詢的時(shí)候能夠做到快速展示, 支持grafana展示 (原生支持)

儀表板顯示

支持自動(dòng)注冊(cè),服務(wù)器根據(jù)主機(jī)名自動(dòng)注冊(cè)到服務(wù)樹相應(yīng)節(jié)點(diǎn),根據(jù)節(jié)點(diǎn)的配置自動(dòng)采集和報(bào)警

新節(jié)點(diǎn)注冊(cè)

更優(yōu)化的agnet,agnet的安全性和性能是我們非常關(guān)注的問(wèn)題,我們盡可能降低agent的資源消耗(mem.used<30MB cpu.used<1%),為此我們還砍了一些采集項(xiàng).

內(nèi)存占用率

CPU占用率

支持分級(jí)報(bào)警,方便值班人員看到正在發(fā)生的報(bào)警,每個(gè)報(bào)警持續(xù)的時(shí)長(zhǎng),以及是否恢復(fù).

報(bào)警DashBord

靈活的機(jī)器管理,你可以看到當(dāng)前機(jī)器有無(wú)報(bào)警,機(jī)器狀態(tài)是否online,如果機(jī)器維護(hù)可以隨時(shí)設(shè)置為維護(hù)狀態(tài),屏蔽這臺(tái)機(jī)器的所有報(bào)警,專注于處理問(wèn)題.

機(jī)器管理

五、展望

回到文章開頭遇到的問(wèn)題,我們借助于現(xiàn)有的開源時(shí)序數(shù)據(jù)庫(kù),大量監(jiān)控?cái)?shù)據(jù)的寫入和讀取已經(jīng)不是問(wèn)題了.

服務(wù)樹的出現(xiàn)可以更好的幫助運(yùn)維人員管理自己的服務(wù)集群,同時(shí)我們?cè)?agent 端開啟了一個(gè) unix domain socket 用于本機(jī)的業(yè)務(wù)上報(bào),這是一個(gè)異步接口,不會(huì)阻塞請(qǐng)求,甚至可以把監(jiān)控平臺(tái)看成是一個(gè)開放的消息總線,通過(guò)這個(gè)上報(bào)接口,給了自己和他人一個(gè)無(wú)限可能.

未來(lái)的監(jiān)控系統(tǒng)肯定會(huì)更加智能,這也是最近比較火的“AIOPS”的一部分,運(yùn)維監(jiān)控系統(tǒng)擁有大量的監(jiān)控原始數(shù)據(jù)卻沒(méi)能發(fā)揮它的價(jià)值,通過(guò)分析這部分?jǐn)?shù)據(jù)我們可以挖掘很多潛在的有價(jià)值的信息,從而降低運(yùn)維成本,提高運(yùn)維效率,這部分?jǐn)?shù)據(jù)甚至可以通過(guò)人工標(biāo)注后進(jìn)行機(jī)器學(xué)習(xí),這樣監(jiān)控系統(tǒng)就可以不用設(shè)置報(bào)警策略來(lái)進(jìn)行報(bào)警了.

機(jī)器學(xué)習(xí)、人工智能的盛行給運(yùn)維工作帶來(lái)更多暢想和變革,這也是我們正在努力的方向.

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/1947.html