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
,用来保存每个上报的数据对应的索引,默认最大大小500W -
unIndexedItemCache
一个大MAP
,key
是MD5
,value
是UUID
和GraphItem
组成的struct
,用来保存没有被上报到数据库中的数据的索引默认最大大小500W -
dbEndpointCache
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的原始数据。