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. 支持集群数据冗余，以及数据动态拉取，对于数据灾备提供了很好的支持

缺点：

1. 对磁盘资源消耗严重。rrdtool自带的归档功能，会消耗大量的磁盘IO。
2. 精确的历史数据保存时间短，不利于历史的现场回放。默认只保存12H的原始数据。