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