近日，國(guó)際互聯(lián)網(wǎng)運(yùn)維圈內(nèi)有著系統(tǒng)工程屆“好萊塢”之稱的SREcon大會(huì)2017年度會(huì)議正式舉辦。了解SREcon的朋友都知道SREcon 是 SRE 領(lǐng)域最專業(yè)的大會(huì)，由 USENIX 組織，今年的正式名稱是 SREcon17 Americas. SREcon 聚集了關(guān)注網(wǎng)站可靠性、系統(tǒng)工程、以及復(fù)雜分布式系統(tǒng)等領(lǐng)域的技術(shù)專家。大會(huì)從2014年開(kāi)始一直在歐美地區(qū)主辦，而今年則首次登陸亞洲地區(qū)。
根據(jù)大會(huì)主辦方顯示，大會(huì)參與企業(yè)均來(lái)自互聯(lián)網(wǎng)領(lǐng)域內(nèi)頂尖級(jí)企業(yè)，海外部分(Google，F(xiàn)acebook，Twitter, LinkedIn，Dropbox， Netflix)中國(guó)部分(百度、阿里、騰訊、滴滴、小米、華為)等共同參與組成。而大會(huì)的分享嘉賓則通過(guò)投稿的形式由大會(huì)評(píng)審團(tuán)商議決定，本屆大會(huì)共計(jì)收到100多篇來(lái)自全球范圍內(nèi)，知名互聯(lián)網(wǎng)企業(yè)的專家投稿。在經(jīng)過(guò)層層篩選后，僅有33篇技術(shù)內(nèi)容得到大會(huì)技術(shù)團(tuán)的認(rèn)可并受邀出席分享嘉賓。就在這33篇嘉賓名單中，光載無(wú)限臺(tái)灣研發(fā)中心(以下簡(jiǎn)稱光載無(wú)限)首席專家則榜上有名。
據(jù)悉，本次光載無(wú)限專家分享的內(nèi)容是，圍繞企業(yè)級(jí)開(kāi)源分布式監(jiān)控系統(tǒng)的演進(jìn)來(lái)和參會(huì)的各路技術(shù)達(dá)人們進(jìn)行了充分的互動(dòng)。在光載無(wú)限專家的介紹中了解到這個(gè)臺(tái)灣研發(fā)中心前身由光載無(wú)限旗下的北京快網(wǎng)CDN發(fā)起組建而成。致力于以開(kāi)源式監(jiān)控解決方案基礎(chǔ)為藍(lán)本，打造企業(yè)自主創(chuàng)新并領(lǐng)先于業(yè)內(nèi)的前沿的分布式監(jiān)控體系。在接受采訪時(shí)光載無(wú)限專家毫無(wú)避諱的表示，我們以open-falcon開(kāi)源解決方案打造的監(jiān)控平臺(tái)，已經(jīng)在現(xiàn)有CDN網(wǎng)絡(luò)層中得到了實(shí)戰(zhàn)的應(yīng)用。未來(lái)一段時(shí)間內(nèi)我們將會(huì)推出一塊黑科技產(chǎn)品OWL(項(xiàng)目計(jì)劃)，相信將會(huì)更好的服務(wù)于企業(yè)與客戶的共同成長(zhǎng)。
未來(lái)網(wǎng)絡(luò)的發(fā)展，需要不同領(lǐng)域內(nèi)更多的技術(shù)變革。但誰(shuí)的技術(shù)能踏上這班高速發(fā)展的快車的前提，在于你對(duì)技術(shù)市場(chǎng)發(fā)展觀的解析。相信正是光載無(wú)限專家對(duì)于分布式監(jiān)控的技術(shù)發(fā)展觀以及應(yīng)用領(lǐng)域的實(shí)際落地得到了大會(huì)評(píng)審圖高度的認(rèn)可。
以下內(nèi)容為大會(huì)分享實(shí)錄精選
光載無(wú)限技術(shù)專家：
今天主要分五個(gè)部份跟大家介紹Open-Falcon，首先介紹我們Open-Falcon 的項(xiàng)目緣起，接著介紹我們的主要特色。然后從系統(tǒng)架構(gòu)層面跟大家講解我們什么樣的設(shè)計(jì)讓Open-Falcon 成為具有這些特性.
再來(lái)跟大家做海外最熱門(mén)的開(kāi)源監(jiān)控系統(tǒng)Prometheus 的比較，同時(shí)讓大家了解一下我們目前的生態(tài)系。
Open-Falcon 有六大特性，接下來(lái)逐一為大家講解。
可擴(kuò)展性監(jiān)控系統(tǒng)是否可以隨著業(yè)務(wù)規(guī)模成長(zhǎng)而伸縮的重要特性，這也是我們自研監(jiān)控系統(tǒng)最主要的理由，務(wù)必得做好，才能支撐業(yè)務(wù)的快速成長(zhǎng)。也因?yàn)檫@個(gè)訴求，所以在Open-Falcon 中我們每個(gè)模塊都可以輕松地水平擴(kuò)展。因?yàn)樗綌U(kuò)展的關(guān)系，Open-Falcon 一個(gè)周期中(默認(rèn)為一分鐘)可支援上億個(gè)查詢、告警判定、儲(chǔ)存、搜索。
提高數(shù)據(jù)查詢速度以及圖表渲染速度對(duì)于運(yùn)維巡檢的效率會(huì)有很大的提升，Open-Falcon 透過(guò)RRA (Round Robin Archive)歸檔機(jī)制，一百個(gè)監(jiān)控項(xiàng)一整年的監(jiān)控?cái)?shù)據(jù)可以在一秒內(nèi)返回結(jié)果。由于歸檔機(jī)制，節(jié)省了硬盤(pán)資源的使用，Open-Falcon 可以輕松地存儲(chǔ)歷史資料超過(guò)十年以上。
我們秉持著分布式系統(tǒng)的設(shè)計(jì)哲學(xué)來(lái)設(shè)計(jì) Open-Falcon，監(jiān)控是超一級(jí)服務(wù)，所有的系統(tǒng)都可以下線，監(jiān)控系統(tǒng)不行。一旦監(jiān)控系統(tǒng)下線的話，我們就像是瞎子一樣，不知道哪里出了問(wèn)題。所以我們不允許系統(tǒng)有嚴(yán)重的單點(diǎn)故障，系統(tǒng)中多數(shù)的模塊都是無(wú)狀態(tài)的。宕機(jī)的話就是無(wú)腦重啟就好，在操作以及部署上面的工作相當(dāng)簡(jiǎn)單。
Falcon-Agent 內(nèi)置監(jiān)控項(xiàng)就已經(jīng)有四百多個(gè)服務(wù)器指標(biāo)，使用者還可以透過(guò)插件或是簡(jiǎn)單運(yùn)行程式再透過(guò)Falcon-Agent 轉(zhuǎn)發(fā)的方式來(lái)自定義監(jiān)控項(xiàng)。因?yàn)槭欠植际较到y(tǒng)，加上模塊都是按照微服務(wù)的精神來(lái)設(shè)計(jì)，系統(tǒng)有極佳的擴(kuò)展性，可以靈活的按照公司內(nèi)部需求定制化自己的監(jiān)控系統(tǒng)。
為了簡(jiǎn)化告警策略的管理，Open-Falcon 支援策略模板、集成以及多個(gè)策略制定，還有回調(diào)函數(shù)用以自動(dòng)恢復(fù)告警。除此之外，為了最佳化工作效率，我們所有的監(jiān)控項(xiàng)上報(bào)的 Endpoint 以及 Counter 都可以被自動(dòng)發(fā)現(xiàn)的，少了很多配置工作。
接下來(lái)，向大家介紹一下Open-Falcon 的系統(tǒng)，讓大家能清楚的了解我們?yōu)槭裁纯梢跃哂羞@些特性，投影片上面的流程圖從左到右表示的是一個(gè)監(jiān)控項(xiàng)的生命周期，底下的字代表的是元件名稱。紅色是核心功能元件。從這張圖可以看得出來(lái)Open-Falcon 采用的就是Stream Processing 來(lái)處理監(jiān)控?cái)?shù)據(jù)。監(jiān)控項(xiàng)從采集，存儲(chǔ)，到告的流程中，都是單向資料流的，這種設(shè)計(jì)的好處是簡(jiǎn)單高效;壞處則是犧牲了一定的靈活性。
Open-Falcon 架構(gòu)，為什么這個(gè)架構(gòu)能夠提供我們以上六點(diǎn)特性呢?首先先從最初的設(shè)計(jì)開(kāi)始吧。在Open-Falcon 中有九大模塊，先從數(shù)據(jù)采集與上報(bào)開(kāi)始，安裝在目標(biāo)機(jī)器上的Falcon-Agent可以采集內(nèi)建的監(jiān)控項(xiàng)指標(biāo)，并且透過(guò)Proxy gateway 代理上報(bào)或是自己直接上報(bào)給Transfer。在某些情況下(如：交換機(jī)、應(yīng)用程序中的性能指標(biāo))，F(xiàn)alcon-Agent 是無(wú)法安裝的，那么我們就需要透過(guò)Client Library 或是SNMP 的方式將數(shù)據(jù)上報(bào)到我們的Proxy gateway，這也會(huì)是一臺(tái)agent，但它不一定是在本機(jī)上面，也就是說(shuō)一臺(tái)設(shè)備中所安裝的Falcon-Agent 可能上報(bào)除了這臺(tái)設(shè)備以外的監(jiān)控指標(biāo)。采集后的數(shù)據(jù)都會(huì)上報(bào)到Transfer，大家可以用Queue 來(lái)理解Transfer，Transfer 會(huì)不斷地消化清空監(jiān)控項(xiàng)隊(duì)列，同時(shí)透過(guò)一致性哈希的算法發(fā)送給Judge 與Graph 模塊，需要特別提醒的是兩個(gè)模塊可能分散在不同設(shè)備上部署。監(jiān)控?cái)?shù)據(jù)到了Judge 之后可以作為告警判定，如果沒(méi)有滿足任何條件的話，就丟棄這份數(shù)據(jù)了。若滿足，則透過(guò)Alarm 模塊通知相應(yīng)的用戶組。到了Graph 則是永久的儲(chǔ)存下來(lái)，背后的數(shù)據(jù)庫(kù)是RRDTool，并且按照RRA 策略?來(lái)做歸檔。Query 作為一個(gè)API 模塊，當(dāng)Dashboard 有畫(huà)圖需求的時(shí)候就可以調(diào)用Query 的API 來(lái)取用數(shù)據(jù)。還沒(méi)有提到的是Portal 以及Aggregator，Portal 是Open-Falcon 的配置中心，包含監(jiān)控策略以及模板綁定都是在Portal 中進(jìn)行操作。這些數(shù)據(jù)的關(guān)聯(lián)性我們都記錄在MySQL 中，并且透過(guò)HBS 與所有的Falcon-Agent 保持心跳定期的下發(fā)監(jiān)控策略已經(jīng)模板綁定關(guān)系。以上的流程講的都還是Streaming Processing 只能針對(duì)單臺(tái)設(shè)備的監(jiān)控指標(biāo)儲(chǔ)存監(jiān)控?cái)?shù)據(jù)、進(jìn)行告警判定。只利用RRDTool 的數(shù)據(jù)庫(kù)不透過(guò)其他數(shù)據(jù)庫(kù)要做到集群監(jiān)控確實(shí)有點(diǎn)局限，Aggregator 的目的就是為了滿足我們對(duì)集群監(jiān)控的需求。Aggregator 會(huì)按照我們欲監(jiān)控的集群配置從Graph 拉取數(shù)據(jù)，做了相應(yīng)的計(jì)算聚合之后，將它作為一個(gè)監(jiān)控項(xiàng)重新打到Transfer 去，這種簡(jiǎn)單的設(shè)計(jì)就滿足了我們對(duì)集群監(jiān)控的需求。
所有組件我們都是透過(guò) Center Status 來(lái)同步系統(tǒng)的狀態(tài)，Center Status 主要有兩個(gè)數(shù)據(jù)庫(kù)組成，分別是 Redis 與 MySQL。
在過(guò)去 v0.1 版本中，我們的模塊很多，圖上寫(xiě)的就是我們 Open-Falcon 模塊的名稱，右下角的數(shù)字表示的是在 Open-Falcon 系統(tǒng)集群中部署的實(shí)例數(shù)量，紅色的是最關(guān)鍵的模塊：Transfer 作為傳輸隊(duì)列，負(fù)責(zé)收集 Agent 采集上來(lái)的數(shù)據(jù)并且發(fā)送給 Graph 以及 Judge，所以負(fù)擔(dān)最大。
因此在 v0.2 版本中，我們進(jìn)一步的整合模塊讓系統(tǒng)簡(jiǎn)化，最終系統(tǒng)可以被分為四大部份：
1. 前端： 第一部份是 Dashboard，Dashboard 是 Open-Falcon 的前端模塊，包含所有告警規(guī)則、用戶、與設(shè)備的管理。
2. 后端模塊：第二部份是 Falcon-Plus，F(xiàn)alcon-Plus 是 Open-Falcon 的后端模塊，它整合了所有 v0.1 中的模塊，我們可以使用 Driver 程序來(lái)驅(qū)動(dòng)選定的模塊并且保留 v0.1 的優(yōu)良傳統(tǒng)。
3. 中心狀態(tài)：第三部份是 Central Status，Central Status 在前面已經(jīng)介紹過(guò)了，我們這里就不贅述。
4. 數(shù)據(jù)采集：最后一部份是 Falcon-Agent。
這樣的簡(jiǎn)化改進(jìn)后不但沒(méi)有犧牲過(guò)去模塊化的彈性，還讓我們凝聚了社區(qū)的開(kāi)發(fā)力量。除此之外，Open-Falcon 可以輕易地結(jié)合社區(qū)優(yōu)秀的開(kāi)源項(xiàng)目，像是 InfluxDB, OpenTSDB, 和Grafana。
前面已經(jīng)介紹了Open-Falcon 與OpenTSDB 還有InfluxDB 不同的設(shè)計(jì)理念，也比較了彼此的優(yōu)缺點(diǎn)，所以在此就忽略不提了。Prometheus 作為海外最熱門(mén)的開(kāi)源監(jiān)控系統(tǒng)，確實(shí)成功的吸引了我們的眼球。相信大家也會(huì)對(duì)這個(gè)比較感興趣。相比于Prometheus，Open-Falcon 的優(yōu)點(diǎn)是什?么呢?
1. 更豐富的API：我們的目標(biāo)是希望讓Open-Falcon 形成一個(gè)業(yè)界的監(jiān)控標(biāo)準(zhǔn)，既然要形成標(biāo)準(zhǔn)就需要簡(jiǎn)單且完善的API 來(lái)提供支持。在API 的支援，開(kāi)發(fā)者完全可以自己設(shè)計(jì)自己的Dashboard 基于我們后端的Falcon-Plus 就可以設(shè)計(jì)自己的監(jiān)控系統(tǒng)。
2. 配置成本低：采用了Push Model 讓系統(tǒng)有自發(fā)現(xiàn)的能力，這簡(jiǎn)化了很多配置工作。即便?是大規(guī)模集群，我們也可以透過(guò)簡(jiǎn)單的tag 機(jī)制讓服務(wù)器自動(dòng)歸屬于對(duì)應(yīng)的HostGroup 之中。支持多種數(shù)據(jù)展示接口。
3. 可以監(jiān)控大規(guī)模的設(shè)備：在小米內(nèi)部已經(jīng)跑了三年多的 Open-Falcon 就是最好的鐵證，在中國(guó)被各大互聯(lián)網(wǎng)公司大規(guī)模采用也證明了 Open-Falcon 極佳的伸縮性。
4. 自有的Dashboard：Open-Falcon API 是針對(duì)整個(gè)系統(tǒng)設(shè)計(jì)的，基于這個(gè)API 我們開(kāi)發(fā)了自己的Dashboard，相較來(lái)說(shuō)Prometheus 如果數(shù)據(jù)在不同的節(jié)點(diǎn)上就只能把其他Prometheus 配置為數(shù)據(jù)源然后展示在不同的Dashboard。Open-Falcon 有自己的Dashboard 組件，接合LDAP可以做一些簡(jiǎn)單的團(tuán)隊(duì)和人員管理，另外就是組合多個(gè)Endpoint 和Metrics。這些是Prometheus 沒(méi)有直接支持的，需要自己開(kāi)發(fā)Dashboard。不過(guò)因?yàn)樵诟婢牟呗怨芾砩厦?Prometheus Alertmanager 還是具有較高的彈性，例如：聚合、去重、以及靜音等等功能。這部份 Prometheus 勝出。
5. 畫(huà)圖效率高：相較于 Prometheus 的 Recording rules，RRDTool 提供的 RRA 歸檔機(jī)制能在更短的時(shí)間內(nèi)返回繪圖數(shù)據(jù)。 Faster query performance of RRA compared to Recordingrules. Metric Type: Summary, Histogram
6. 使用與開(kāi)發(fā)的門(mén)檻低：與Prometheus 的Collector/Exporter 相比，我們只保證Agent 收到的客制化監(jiān)控項(xiàng)，是符合Open-Falcon 格式規(guī)范的使用者可以用自己熟悉的編程語(yǔ)言寫(xiě)程序或是腳本來(lái)開(kāi)發(fā)客制化監(jiān)控項(xiàng)。開(kāi)發(fā)插件的門(mén)檻較低。
7. 有限的表達(dá)式：Prometheus 的最大優(yōu)點(diǎn)在于它有很靈活的查詢語(yǔ)言： PromQL ;使用 PullModel 的設(shè)計(jì)讓它在告警的判定與策略的管理更具有彈性，支持很多組合加工數(shù)據(jù)的方式;除此之外，Prometheus 在監(jiān)控項(xiàng)的數(shù)據(jù)型別也額外支持了Summary , Histogram，圖標(biāo)的展現(xiàn)方式也更多元。這是prometheus最大的亮點(diǎn)。 PromQL 語(yǔ)言還用于存儲(chǔ)前的Recording Rule 和報(bào)警配置的 Alert Rule。相較之下， Open-Falcon 支持有限的組合方式，比如 SUM, AVG, MAX 等等取樣方式。這部份 Prometheus 勝出。
微信掃一掃
