openfalcon源碼分析之graph
本節內容
- graph功能
- graph源碼分析
- 2.1 graph中重要的數據結構
- 2.2 graph的簡要流程圖
- 2.3 graph處理數據過程
- 2.4 graph數據遷移
- graph設計優缺點
- 優點:
- 缺點:
1. graph功能
graph
在整個falcon
項目中的位置就是把transfer
push
上來的數據進行采樣存儲,並提供查詢接口。
graph使用rrdtool保存數據,上報來的數據,被存在一個個的rrd文件中,同時會對數據進行采采樣,最大值,最小值,和平均值,保存歷史數據歸檔,這樣既節省了存儲空間,又不會在查詢長時間段時導致數據量太大,加載效率變低。
2. graph源碼分析
2.1 graph中重要的數據結構
首先,介紹下graphs中幾個重要的數據結構:
MD5
Endpoint+Metric+Tags
拼接之后通過MD5
計算出的HASH
值RRD
緩存數據的KEY
MD5+dsType+step
拼接的字符串UUID
endpoint+metric+tags+dstype+step
拼接之后通過MD5
計算出的HASH
值IndexedItemCache
一個大MAP
,key
是MD5
,value
是UUID
和GraphItem
組成的struct
,用來保存每個上報的數據對應的索引,默認最大大小500WunIndexedItemCache
一個大MAP
,key
是MD5
,value
是UUID
和GraphItem
組成的struct
,用來保存沒有被上報到數據庫中的數據的索引默認最大大小500WdbEndpointCache
graph
庫中的endpoint
表的內存緩存,key:endpoint(string) / value:id(int64)
dbEndpointCounterCache
graph
庫中的endpoint_counter
表的內存緩存,key:endpoint_id-counter(string) / val:dstype-step(string)
緩存時間10分鍾,每1分鍾檢查一次GraphItemMap
大MAP
,默認大小是1800的一個list
,來了數據之后,先對RRD-KEY
進行CRC32
進行循環冗余之后,對1800取余,獲取索引,該索引對應的是一個MAP
,key
是RRD-KEY
,value
是鏈表,鏈表的每個節點保存一個GraphItem
。HistoryCache
大MAP
,key
是MD5
,value
是鏈表,每個節點是GraphItem
,只保留最新的三個數據
2.2 graph的簡要流程圖
下面是整個graph的流程簡圖:
2.3 graph處理數據過程
上面已經做好了前期鋪墊,接下來展開分析一下graph中數據處理的流程。
首先介紹graph
從transfer
中拿到數據后的操作:
Graph.Send
方法獲取到transfer
傳輸過來的GraphItems
,交給HandleItems
處理。- 循環
GraphItems
,獲取每個GraphItem
都進行下面三個操作:- 把
GraphItem
push
到store.GraphItems
這個大MAP
對應的位置中 - 調用
index.ReceiveItem
方法,判斷數據是否之前已經上報過,如果上報過,更新到IndexedItemCache MAP
中,否則,判斷其對應的rrd
文件是否存在,如果存在,直接加入到IndexedItemCache
中,如果不存在,放到unIndexedItemCache map
中。 - 調用
store.AddItem
方法,將數據添加到HistoryCache
中,並把老的數據刪掉,只保留最近三個數據
- 把
unIndexedItemCache
中的數據會定期刷新到數據庫的graph
庫的endpoint
表tag_endpoint
表endpoint_counter
表中並添加到IndexedItemCache
中,最后在unIndexedItemCache
中刪除。store.GraphItems
中的數據定期刷入到磁盤上的RRD
文件中。
graph中的Graph.Query
方法獲取要查詢的數據后進行的操作:
- 根據
param.Endpoint
,param.Counter
生成MD5
值,去IndexedItemCache
中找dsType
和step
,若沒找到,去dbEndpointCache
和dbEndpointCounterCache
查詢,若還是沒找到,則到數據庫中查找對應的dsType
和step
,后把找到的數據緩存到dbEndpointCache
和dbEndpointCounterCache
中。 - 計算
start_ts
和end_ts
,從store.GraphItems
中拿到還沒被緩存進RRD
文件的數據,再去RRD
文件中取出對應的數據(如果cfg
支持migrate
,以及判斷查詢數據不在這個Graph
實例,則從其它Graph
實例進行查詢) - 將
RRD
文件中查到的數據和緩存的數據進行merge
之后,生成最終數據返回給調用方。
graph
中的Graph.Delete
方法接收GraphDeleteParam
組成的列表,並徹底刪除相應的數據
IndexedItemCache
和unIndexedItemCache
中刪除對應的數據store.GraphItems
中清空對應節點緩存的數據- 刪除對應的RRD文件
以上就是主要提供使用最頻繁的 RPC API
,下面介紹Http
提供的主要API
/index/updateAll
該API
將觸發索引全量更新, 同步操作,會把所有IndexedItemCache
中的數據,全部刷入到數據庫中,這個功能在調試的時候有用。/index/updateAll/concurrent
該API
能獲取索引全量更新的並行數/api/v2/index
更新一條索引數據,用於手動建立索引endpoint metric step dstype tags
/counter/all
和/statistics/all
獲取所有關於graph
中各種操作的統計數據
2.4 graph數據遷移
graph支持數據遷移,在配置文件中打開相應的配置
"migrate": {
"enabled": false, // 默認不開啟
"concurrency": 2, // 開啟的任務協程數量
"replicas": 500, // 一致性hash環中的重復點數
"cluster": { // 集群節點配置
"graph-00" : "127.0.0.1:6070"
}
3. graph設計優缺點
優點:
- 使用rrdtool存儲數據,相對於數據庫存儲數據,大大減輕了壓力,最大的性能瓶頸被解決了
- 支持集群數據冗余,以及數據動態拉取,對於數據災備提供了很好的支持
缺點:
- 對磁盤資源消耗嚴重。rrdtool自帶的歸檔功能,會消耗大量的磁盤IO。
- 精確的歷史數據保存時間短,不利於歷史的現場回放。默認只保存12H的原始數據。