openfalcon源碼分析之graph

openfalcon源碼分析之graph

本節內容

1. graph功能
2. graph源碼分析
   • 2.1 graph中重要的數據結構
   • 2.2 graph的簡要流程圖
   • 2.3 graph處理數據過程
   • 2.4 graph數據遷移
3. graph設計優缺點
   • 優勢：
   • 缺點：

1. graph功能

graph在整個falcon項目中的位置就是把transfer push上來的數據進行採樣存儲，並提供查詢接口。

graph使用rrdtool保存數據，上報來的數據，被存在一個個的rrd文件中，同時會對數據進行采采樣，最大值，最小值，和平均值，保存歷史數據歸檔，這樣既節省了存儲空間，又不會在查詢長時間段時致使數據量太大，加載效率變低。

2. graph源碼分析

2.1 graph中重要的數據結構

首先，介紹下graphs中幾個重要的數據結構：

1. MD5 Endpoint+Metric+Tags拼接以後經過MD5計算出的HASH值
2. RRD緩存數據的KEY MD5+dsType+step拼接的字符串
3. UUID endpoint+metric+tags+dstype+step拼接以後經過MD5計算出的HASH值
4. IndexedItemCache 一個大MAP，key是MD5，value是UUID和GraphItem組成的struct,用來保存每一個上報的數據對應的索引，默認最大大小500W
5. unIndexedItemCache 一個大MAP，key是MD5，value是UUID和GraphItem組成的struct,用來保存沒有被上報到數據庫中的數據的索引默認最大大小500W
6. dbEndpointCache graph庫中的endpoint表的內存緩存，key:endpoint(string) / value:id(int64)
7. dbEndpointCounterCache graph庫中的endpoint_counter表的內存緩存, key:endpoint_id-counter(string) / val:dstype-step(string)緩存時間10分鐘，每1分鐘檢查一次
8. GraphItemMap 大MAP，默認大小是1800的一個list,來了數據以後，先對RRD-KEY進行CRC32進行循環冗餘以後，對1800取餘，獲取索引，該索引對應的是一個MAP，key是RRD-KEY，value是鏈表，鏈表的每一個節點保存一個GraphItem。
9. HistoryCache 大MAP，key是MD5，value是鏈表，每一個節點是GraphItem,只保留最新的三個數據

2.2 graph的簡要流程圖

下面是整個graph的流程簡圖：

2.3 graph處理數據過程

上面已經作好了前期鋪墊，接下來展開分析一下graph中數據處理的流程。
首先介紹graph從transfer中拿到數據後的操做：

1. Graph.Send方法獲取到transfer傳輸過來的GraphItems，交給HandleItems處理。
2. 循環GraphItems，獲取每一個GraphItem都進行下面三個操做：
   • 把GraphItem push到store.GraphItems這個大MAP對應的位置中
   • 調用index.ReceiveItem方法，判斷數據是否以前已經上報過，若是上報過，更新到IndexedItemCache MAP中，不然，判斷其對應的rrd文件是否存在，若是存在，直接加入到IndexedItemCache中，若是不存在，放到unIndexedItemCache map中。
   • 調用store.AddItem方法，將數據添加到HistoryCache中，並把老的數據刪掉，只保留最近三個數據
3. unIndexedItemCache中的數據會按期刷新到數據庫的graph庫的endpoint表 tag_endpoint表 endpoint_counter表中並添加到IndexedItemCache中，最後在unIndexedItemCache中刪除。
4. store.GraphItems中的數據按期刷入到磁盤上的RRD文件中。

graph中的Graph.Query方法獲取要查詢的數據後進行的操做：

1. 根據param.Endpoint, param.Counter生成MD5值，去IndexedItemCache中找dsType和step，若沒找到，去dbEndpointCache和dbEndpointCounterCache查詢，若仍是沒找到，則到數據庫中查找對應的dsType和step，後把找到的數據緩存到dbEndpointCache和dbEndpointCounterCache中。
2. 計算start_ts和end_ts，從store.GraphItems中拿到還沒被緩存進RRD文件的數據，再去RRD文件中取出對應的數據（若是cfg支持migrate，以及判斷查詢數據不在這個Graph實例，則從其它Graph實例進行查詢）
3. 將RRD文件中查到的數據和緩存的數據進行merge以後，生成最終數據返回給調用方。

graph中的Graph.Delete方法接收GraphDeleteParam組成的列表，並完全刪除相應的數據

1. IndexedItemCache和unIndexedItemCache中刪除對應的數據
2. store.GraphItems中清空對應節點緩存的數據
3. 刪除對應的RRD文件

以上就是主要提供使用最頻繁的 RPC API,下面介紹Http提供的主要API

1. /index/updateAll 該API將觸發索引全量更新, 同步操做，會把全部IndexedItemCache中的數據，所有刷入到數據庫中，這個功能在調試的時候有用。
2. /index/updateAll/concurrent 該API能獲取索引全量更新的並行數
3. /api/v2/index 更新一條索引數據,用於手動創建索引 endpoint metric step dstype tags
4. /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設計優缺點

優勢：

1. 使用rrdtool存儲數據，相對於數據庫存儲數據，大大減輕了壓力，最大的性能瓶頸被解決了

2. 支持集羣數據冗餘，以及數據動態拉取，對於數據災備提供了很好的支持

   缺點：

3. 對磁盤資源消耗嚴重。rrdtool自帶的歸檔功能，會消耗大量的磁盤IO。

4. 精確的歷史數據保存時間短，不利於歷史的現場回放。默認只保存12H的原始數據。