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

作者介紹

kun：鳳凰網(wǎng)運維開發(fā),負責公司運維自動化平臺設(shè)計開發(fā),InfluxDB contributer、open-falcon contributer 、golang愛好者.

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

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

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

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

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

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

先簡單介紹下幾個概念：

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

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

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

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

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

2.2關(guān)于高可用

考慮到服務(wù)樹(service registry)組件的重要性,架構(gòu)上一定是高可用的,于是我們底層數(shù)據(jù)存儲 store 層多實例是基于 raft 算法保證數(shù)據(jù)一致性的,最底層是用了 boltDB 來存儲服務(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 }

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

2.3關(guān)于擴展性

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

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

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

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

2.4關(guān)于性能

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

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

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

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

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

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

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

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

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

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

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

3.2各模塊功能

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

3.3為什么選擇InfluxDB

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

舉個例子,2000臺左右服務(wù)器,100天數(shù)據(jù)占用400G空間.面對10s級別的上報采集頻率,這個成績是非常不錯的.

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

四、Highlight

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

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

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

監(jiān)控上報

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

相關(guān)插件

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

儀表板顯示

支持自動注冊,服務(wù)器根據(jù)主機名自動注冊到服務(wù)樹相應(yīng)節(jié)點,根據(jù)節(jié)點的配置自動采集和報警

新節(jié)點注冊

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

內(nèi)存占用率

CPU占用率

支持分級報警,方便值班人員看到正在發(fā)生的報警,每個報警持續(xù)的時長,以及是否恢復.

報警DashBord

靈活的機器管理,你可以看到當前機器有無報警,機器狀態(tài)是否online,如果機器維護可以隨時設(shè)置為維護狀態(tài),屏蔽這臺機器的所有報警,專注于處理問題.

機器管理

五、展望

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

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

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

機器學習、人工智能的盛行給運維工作帶來更多暢想和變革,這也是我們正在努力的方向.

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