Open-falcon原理介紹

open-falcon是小米開源的監控工具。open-falcon有三種安裝方式，一種是單機安裝（分後端和前端安裝，建議各一臺服務器）、一種是Docker安裝、最後一種是在多臺機器上分佈式安裝。

重點：本案介紹第一種，單機安裝（實際上是分兩臺服務器，一臺安裝後端服務、一臺是安裝前端服務）。

分佈式安裝也很簡單，就是把open-falcon二進制包git下來，每臺服務器只留須要的模塊文件夾和open-falcon執行腳本，而後更改模塊文件夾下配置文件，最後啓動便可。生成環境環境通常建議分佈式部署，參考連接：https://book.open-falcon.org/zh_0_2/distributed_install/

open-falcon監控通常是用各類插件。

架構圖：

open-falcon官網架構圖

互聯網上圖

組件描述表：

組件名稱	用途	服務端口	備註
Agent	部署在須要監控的服務器上	http: 1988	http://192.168.153.134:1988/
Transfer	數據接收端，轉發數據到後端的Graph和Judge	http: 6060 rpc: 8433 socket: 4444
Graph	操做rrd文件存儲監控數據	http: 6071 rpc：6070
Query	查詢各個Graph數據，提供統一http查詢接口	http: 9966
Dashboard	查詢監控歷史趨勢圖的web	http: 8081	須要python環境，須要鏈接數據庫dashborad實例、graph組件
Task	負載一些定時任務，索引全量更新、垃圾索引清理、自身組件監控等	http: 8082	須要鏈接數據庫graph實例
Aggregator	集羣聚合模塊	http: 6055
Alarm	告警	http: 9912
Api	API	http: 8080
Gateway	Gateway	http: 16060
Hbs	心跳服務器	6030
Judge	告警判斷	http: 6081 rpc: 6080
Nodata	告警異常處理	http: 6090
Mysql	數據庫	3306
Redis	緩存服務器	6379

工做原理：

Falcon-agent（客戶端）：

每臺服務器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用於自發現的採集單機的各類數據和指標，這些指標包括不限於如下幾個方面，共計200多項指標。

    CPU相關

    磁盤相關

    IO

    Load

    內存相關

    網絡相關

    端口存活、進程存活

    ntp offset（插件）

    某個進程資源消耗（插件）

    netstat、ss 等相關統計項採集

    機器內核配置參數

只要安裝了falcon-agent的機器，就會自動開始採集各項指標，主動上報，不須要用戶在server作任何配置（這和zabbix有很大的不一樣），這樣作的好處，就是用戶維護方便，覆蓋率高。固然這樣作也會server端形成較大的壓力，不過open-falcon的服務端組件單機性能足夠高，同時均可以水平擴展，因此自動多采集足夠多的數據，反而是一件好事情，對於SRE和DEV來說，過後追查問題，再也不是難題。

另外，falcon-agent提供了一個proxy-gateway，用戶能夠方便的經過http接口，push數據到本機的gateway，gateway會幫忙高效率的轉發到server端。

falcon-agent，能夠在咱們的github上找到 : https://github.com/open-falcon/falcon-plus

Transfer（傳輸者）：

falcon-agent將數據上報給transfer，它們之間創建的長連接。

transfer，接收客戶端發送的數據，作一些數據規整，檢查以後，轉發到多個後端系統去處理。在轉發到每一個後端業務系統的時候，transfer會根據一致性hash算法，進行數據分片，來達到後端業務系統的水平擴展。

transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無狀態的，掛掉一臺或者多臺不會有任何影響，同時transfer性能很高，每分鐘能夠轉發超過500萬條數據。

transfer目前支持的業務後端，有三種，judge、graph、opentsdb。judge是咱們開發的高性能告警斷定組件，graph是咱們開發的高性能數據存儲、歸檔、查詢組件，opentsdb是開源的時間序列數據存儲服務。能夠經過transfer的配置文件來開啓。

transfer的數據來源，通常有三種：

    falcon-agent採集的基礎監控數據

    falcon-agent執行用戶自定義的插件返回的數據

    client library：線上的業務系統，都嵌入使用了統一的perfcounter.jar，對於業務系統中每一個RPC接口的qps、latency都會主動採集並上報

說明：上面這三種數據，都會先發送給本機的proxy-gateway，再由gateway轉發給transfer。

Judge集羣（告警判斷）：

falcon-agent將數據上報給transfer後，transfer轉發給Judge集羣，使用一致性hash作數據分片。一個實例只處理一部分數據。

Graph集羣（數據存儲、規定、查詢接口）：

falcon-agent將數據上報給transfer後，transfer轉發給Graph集羣，使用一致性hash作數據分片。一個實例只處理一部分數據。rrdtool的數據歸檔方式存儲，同時提供RPC接口。

Alarm（告警）：

Judge判斷後，放到redis隊列。alarm從redis隊列讀取報警事件作處理，該發短信發短信、該發郵件發郵件，該回調接口就回調。告警合併也在alarm裏面作的，專門發送報警的sender模塊，告警合併依賴的links模塊。

Query：

由於Graph作過度片處理，query要採用和transfer一致的一致性hash數據分片。對外提供一個http接口。query是go寫的後端模塊。

Dashborad：

在dashborad裏面查詢監控數據，是python作的web。

Portal：

portal是python作的web，配置監控策略，而後寫入數據庫。

Heartbeat server：

心跳服務器，falcon-agent每分鐘都會發送心跳給heartbeat server，上報本身的版本、hostname、ip等。從heartbeat拉取要執行的插件和特殊採集項等。這些信息須要heartbeat訪問 Portal的數據庫要獲取。Judge要作告警判斷，須要先從portal數據庫中讀取報警策略，可是Judge實例比較多，都去讀取數據庫會形成很大壓力，因此可讓heartbeat成爲db cache緩存，heartbeat從數據庫中讀取數據緩存到內存，Judge調用heartbeat的rpc接口，獲取報警策略。

數據存儲：

對於監控系統來說，歷史數據的存儲和高效率查詢，永遠是個很難的問題！

    數據量大：目前咱們的監控系統，每一個週期，大概有2000萬次數據上報（上報週期爲1分鐘和5分鐘兩種，各佔50%），一天24小時裏，歷來不會有業務低峯，不論是白天和黑夜，每一個週期，總會有那麼多的數據要更新。

    寫操做多：通常的業務系統，一般都是讀多寫少，能夠方便的使用各類緩存技術，再者各種數據庫，對於查詢操做的處理效率遠遠高於寫操做。而監控系統偏偏相反，寫操做遠遠高於讀。每一個週期幾千萬次的更新操做，對於經常使用數據庫（MySQL、postgresql、mongodb）都是沒法完成的。

    高效率的查：咱們說監控系統讀操做少，是說相對寫入來說。監控系統自己對於讀的要求很高，用戶常常會有查詢上百個meitric，在過去一天、一週、一月、一年的數據。如何在1秒內返回給用戶並繪圖，這是一個不小的挑戰。

open-falcon在這塊，投入了較大的精力。咱們把數據按照用途分紅兩類，一類是用來繪圖的，一類是用戶作數據挖掘的。

對於繪圖的數據來說，查詢要快是關鍵，同時不能丟失信息量。對於用戶要查詢100個metric，在過去一年裏的數據時，數據量自己就在那裏了，很難1秒之類能返回，另外就算返回了，前端也沒法渲染這麼多的數據，還得采樣，形成不少無謂的消耗和浪費。咱們參考rrdtool的理念，在數據每次存入的時候，會自動進行採樣、歸檔。咱們的歸檔策略以下，歷史數據保存5年。同時爲了避免丟失信息量，數據歸檔的時候，會按照平均值採樣、最大值採樣、最小值採樣存三份。

// 1分鐘一個點存 12小時
c.RRA("AVERAGE", 0.5, 1, 720)

// 5m一個點存2d
c.RRA("AVERAGE", 0.5, 5, 576)
c.RRA("MAX", 0.5, 5, 576)
c.RRA("MIN", 0.5, 5, 576)

// 20m一個點存7d
c.RRA("AVERAGE", 0.5, 20, 504)
c.RRA("MAX", 0.5, 20, 504)
c.RRA("MIN", 0.5, 20, 504)

// 3小時一個點存3個月
c.RRA("AVERAGE", 0.5, 180, 766)
c.RRA("MAX", 0.5, 180, 766)
c.RRA("MIN", 0.5, 180, 766)

// 1天一個點存1year
c.RRA("AVERAGE", 0.5, 720, 730)
c.RRA("MAX", 0.5, 720, 730)
c.RRA("MIN", 0.5, 720, 730)

對於原始數據，transfer會打一份到hbase，也能夠直接使用opentsdb，transfer支持往opentsdb寫入數據。