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 一个大MAPkeyMD5valueUUIDGraphItem组成的struct,用来保存每个上报的数据对应的索引,默认最大大小500W
  5. unIndexedItemCache 一个大MAPkeyMD5valueUUIDGraphItem组成的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. GraphItemMapMAP,默认大小是1800的一个list,来了数据之后,先对RRD-KEY进行CRC32进行循环冗余之后,对1800取余,获取索引,该索引对应的是一个MAPkeyRRD-KEYvalue是链表,链表的每个节点保存一个GraphItem
  9. HistoryCacheMAPkeyMD5value是链表,每个节点是GraphItem,只保留最新的三个数据

2.2 graph的简要流程图

下面是整个graph的流程简图:
openfalcon源码分析之graph-LMLPHP

2.3 graph处理数据过程

上面已经做好了前期铺垫,接下来展开分析一下graph中数据处理的流程。
首先介绍graphtransfer中拿到数据后的操作:

  1. Graph.Send方法获取到transfer传输过来的GraphItems,交给HandleItems处理。
  2. 循环GraphItems,获取每个GraphItem都进行下面三个操作:
    • GraphItem pushstore.GraphItems这个大MAP对应的位置中
    • 调用index.ReceiveItem方法,判断数据是否之前已经上报过,如果上报过,更新到IndexedItemCache MAP中,否则,判断其对应的rrd文件是否存在,如果存在,直接加入到IndexedItemCache中,如果不存在,放到unIndexedItemCache map中。
    • 调用store.AddItem方法,将数据添加到HistoryCache中,并把老的数据删掉,只保留最近三个数据
  3. unIndexedItemCache中的数据会定期刷新到数据库的graph库的endpointtag_endpointendpoint_counter表中并添加到IndexedItemCache中,最后在unIndexedItemCache中删除。
  4. store.GraphItems中的数据定期刷入到磁盘上的RRD文件中。

graph中的Graph.Query方法获取要查询的数据后进行的操作:

  1. 根据param.Endpoint, param.Counter生成MD5值,去IndexedItemCache中找dsTypestep,若没找到,去dbEndpointCachedbEndpointCounterCache查询,若还是没找到,则到数据库中查找对应的dsTypestep,后把找到的数据缓存到dbEndpointCachedbEndpointCounterCache中。
  2. 计算start_tsend_ts,从store.GraphItems中拿到还没被缓存进RRD文件的数据,再去RRD文件中取出对应的数据(如果cfg支持migrate,以及判断查询数据不在这个Graph实例,则从其它Graph实例进行查询)
  3. RRD文件中查到的数据和缓存的数据进行merge之后,生成最终数据返回给调用方。

graph中的Graph.Delete方法接收GraphDeleteParam组成的列表,并彻底删除相应的数据

  1. IndexedItemCacheunIndexedItemCache中删除对应的数据
  2. store.GraphItems中清空对应节点缓存的数据
  3. 删除对应的RRD文件

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

  1. /index/updateAllAPI将触发索引全量更新, 同步操作,会把所有IndexedItemCache中的数据,全部刷入到数据库中,这个功能在调试的时候有用。
  2. /index/updateAll/concurrentAPI能获取索引全量更新的并行数
  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的原始数据。

 
 
 
04-28 12:43