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 | |
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寫入數據。