历史数据存储组件
Branch: master
Clone or download
hitripod Merge pull request #21 from andyxning/master
sort node before added consistent hashing
Latest commit 2d27dc2 Sep 7, 2016
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
api merge cache data after fetch rrd Jan 20, 2016
doc add dock Jan 5, 2016
g add git.go Mar 9, 2016
http add counter for migrate Dec 16, 2015
index fix mysql broken pipe Oct 16, 2015
proc
rrdtool sort node before added consistent hashing May 25, 2016
store update for some variable name/type Dec 17, 2015
test fix bug of Query.merge, use the internal commom lib Aug 27, 2015
.gitignore add git.go Mar 9, 2016
LICENSE
NOTICE add License and NOTICE May 14, 2015
README.md 增加graph扩容步骤文档 Mar 4, 2016
cfg.example.json
control fix bug of Query.merge, use the internal commom lib Aug 27, 2015
main.go if remote rrdfile is not exist, commit rrd anon Feb 21, 2016

README.md

Introduction

对于监控系统来讲,历史数据的存储,高效率查询,快速展现,是个很重要且困难的问题。这主要表现在下面三个方面:

  1. 数据量大:目前我们的监控系统,每个周期,大概有1亿次数据采集项上报(上报周期为1分钟和5分钟两种,各占50%),一天24小时里,从来不会有低峰,不管是白天和黑夜,每个周期,总会有那么多的数据要更新。
  2. 写操作多:一般的业务系统,通常都是读多写少,可以方便的使用各种缓存技术,再者各类数据库,对于查询操作的处理效率远远高于写操作。而监控系统恰恰相反,写操作远远高于读。每个周期几千万次的更新操作,对于常用数据库(MySQL、PostgreSQL、MongoDB)都不是最合适和擅长的。
  3. 高效率的查:我们说监控系统读操作少,是说相对写入来讲。监控系统本身对于读的要求很高,用户经常会有查询上百个metric,在过去一天、一周、一月、一年的数据。如何在秒级返回给用户并在前端展现,这是一个不小的挑战。

graph所做的事情,就是把用户每次push上来的数据,进行采样存储,并提供查询接口。

我们参考RRDtool的理念,在数据每次存入的时候,会自动进行采样、归档。在默认的归档策略,一分钟push一次的频率下,历史数据保存5年。同时为了不丢失信息量,数据归档的时候,会按照平均值采样、最大值采样、最小值采样存三份。用户在查询某个metric,在过去一年的历史数据时,Graph会选择最合适的采样频率,返回采样过后的数据,提高了数据查询速度。

Installation

源码安装过程,如下

# set $GOPATH and $GOROOT

mkdir -p $GOPATH/src/github.com/open-falcon
cd $GOPATH/src/github.com/open-falcon
git clone https://github.com/open-falcon/graph.git

cd graph
go get ./...
./control build

./control start

你可以从这里,下载最新的release安装包,避免源码编译的种种问题。

Configuration

{
    "debug": false, //true or false, 是否开启debug日志
    "http": {
        "enabled": true, //true or false, 表示是否开启该http端口,该端口为控制端口,主要用来对graph发送控制命令、统计命令、debug命令
        "listen": "0.0.0.0:6071" //表示监听的http端口
    },
    "rpc": {
        "enabled": true, //true or false, 表示是否开启该rpc端口,该端口为数据接收端口
        "listen": "0.0.0.0:6070" //表示监听的rpc端口
    },
    "rrd": {
        "storage": "/home/work/data/6070" //绝对路径,历史数据的文件存储路径(如有必要,请修改为合适的路)
    },
    "db": {
        "dsn": "root:@tcp(127.0.0.1:3306)/graph?loc=Local&parseTime=true", //MySQL的连接信息,默认用户名是root,密码为空,host为127.0.0.1,database为graph(如有必要,请修改)
        "maxIdle": 4  //MySQL连接池配置,连接池允许的最大连接数,保持默认即可
    },
    "callTimeout": 5000,  //RPC调用超时时间,单位ms
    "migrate": {  //扩容graph时历史数据自动迁移
        "enabled": false,  //true or false, 表示graph是否处于数据迁移状态
        "concurrency": 2, //数据迁移时的并发连接数,建议保持默认
        "replicas": 500, //这是一致性hash算法需要的节点副本数量,建议不要变更,保持默认即可(必须和transfer的配置中保持一致)
        "cluster": { //未扩容前老的graph实例列表
            "graph-00" : "127.0.0.1:6070"
        }
    }
}

关于扩容时数据自动迁移

当graph集群扩容时,数据会自动迁移达到rebalance的目的。具体的操作步骤如下:

假设1:旧的graph集群为

graph-00 : 192.168.1.1:6070
graph-01 : 192.168.1.2:6070

假设2:在已有的graph集群基础上,需要再扩容两个实例,如下

graph-00 : 192.168.1.1:6070
graph-01 : 192.168.1.2:6070
graph-02 : 192.168.1.3:6070
graph-03 : 192.168.1.4:6070

####1 修改新增加的graph的cfg.json如下:

"migrate": {
      "enabled": true,  //true 表示graph是否处于数据迁移状态
      "concurrency": 2,
      "replicas": 500,
      "cluster": { //未扩容前老的graph实例列表
         "graph-00" : "192.168.1.1:6070",
         "graph-01" : "192.168.1.2:6070"
      }
}

要点说明:

  1. 只有新增加的graph实例配置需要修改,原有的graph实例配置不能变动
  1. 修改配置文件的时候,首先要把migrate -> enabled这个开关修改为true;其次要保证migrate -> cluster这个列表为旧集群的graph列表。

####2 重启所有的graph

cd $WORKSPACE/graph/ && bash control restart

####3 修改所有transfer的cfg.json如下:

"graph": {
    "enabled": true,
     ...,
    "replicas": 500,
    "cluster": {
        "graph-00" : "192.168.1.1:6070",
        "graph-01" : "192.168.1.2:6070",
        "graph-02" : "192.168.1.3:6070",
        "graph-03" : "192.168.1.4:6070"
    }
},

要点说明:最主要的就是修改graph -> cluster列表为扩容后完整的graph实例列表

####4 重启所有的transfer

cd $WORKSPACE/transfer/ && bash control restart

这时候,transfer就会将接收到的数据,发送给扩容后的graph实例;同时graph实例,会自动进行数据的rebalance,rebalance的过程持续时间长短,与待迁移的counter数量以及graph机器的负载、性能有关系。

####5 修改query的配置,并重启所有的query进程

"graph": {
     ...,
    "replicas": 500,
    "cluster": {
        "graph-00" : "192.168.1.1:6070",
        "graph-01" : "192.168.1.2:6070",
        "graph-02" : "192.168.1.3:6070",
        "graph-03" : "192.168.1.4:6070"
    }
},

要点说明:最主要的就是修改graph -> cluster列表为扩容后完整的graph实例列表

####6 如何确认数据rebalance已经完成?

目前只能通过观察graph内部的计数器,来判断整个数据迁移工作是否完成;观察方法如下:对所有新扩容的graph实例,访问其统计接口http://127.0.0.1:6071/counter/migrate 观察到所有的计数器都不再变化,那么就意味着迁移工作完成啦。