me vs influxdata.md

influxdata 技术参数对比

所有预警都分4大块：

1. 探针采集器
2. 数据存储
3. 预警
4. 展示

influxdata开源4款产品influxdb,chronograf,telegraf,kapactor，经过阅读这四款产品源码，发现对整个行业贡献相当大同时对创业公司也是打击也是非常大。你一个团队，花上几百万，最后基于influxdata系列产品，可能在一个月时间赶超您的产品。 这时候我们需要对比调整产品技术线路以及产品功能方向： 我们的优势：

1. 多用户平台
2. 微服务架构、docker化
3. 集大成，bosun、dd-agent、opentsdb、librenms每一个都是业内佼佼者

我们的劣势：

1. 部署复杂
2. 维护复杂
3. 开发投入时间不足，无法长期保证产品先进性

结论：

1. 如果继续做平台，我们这套架构体系只需要细节继续完善，功能继续开发，没有其他问题
2. 如果是做内部部署的工具产品，果断采用influxdata产品线，基于它上面做业务需求开发

前端 chronograf 技术参数对比

参数	我们	chronograf	优劣
系统模板	存放mysql	预埋json，通过go-bindata压入执行文件	<>我们灵活，chronograf精简
reactjs	reactjs	reactjs	=
redux	redux	redux	=
router	react-redux	react-redux	=
dashboard控件	react-grid-layout	react-grid-layout	=
风格	materialdesign antd	bootstrap	=
图表	https://www.highcharts.com/	http://dygraphs.com/	+，支持更丰富
主机列表	丰富	基本()	+多侧边栏，设备类型
预警列表	有	有	=
预警配置	主机是否在线，指标预警(绝对)，丢失数据预警	指标预警(相对于绝对)，丢失数据预警 ，预警方式	-
仪表盘定制	有	有	=
拓扑图	有	无	+
接口方式	通过微服务api拉取	内置代理器，通过代理器拉去后端(influxdb,kapacitor)	<>

chronograf对user、source、自定义dashboard存储采用boltdb http://www.opscoder.info/boltdb_intro.html。

预警方式不足，我们采用的是简单(java定时器)+复杂(Bosun)一起预警，Bosun与kapacitor的比较后面介绍。
总之：前端这一块无可挑剔。

编译

进入gopath的chronograf目录，执行go generate 或者直接make，进行资源文件打包进入go文件。
会扫描类似

//go:generate go-bindata -o dist_gen.go -ignore 'map|go' -pkg dist ../ui/build/...

代码，然后生成go文件。最后就可以编译成功。

boltdbweb --db-name=/Users/*****/chronograf-v1.db  --port=8389 --static-path=/Users/*****/go/src/github.com/evnix/boltdbweb/

telegraf 与 我们 探针对比

参数	我们	telegraf	优劣
系统探针	dd agent	telegraf	dd-agent支持多例如vcenter，telegraf更细参考apache模块
snmp	librenms	telegraf	librenms采集数据丰富，但配置复杂
kvm	libvirt	-	+
架构	agent-api-mq-tsdb	agent(...)-telegraf-kafka-telegraf-influxdb(...)	我们微服务架构灵活机动可以快速接入采集器，都需要定制，telegraf架构超出我们，它插件模式，内置了好多input以及output

总之：两种探针模式很难权衡谁优谁劣，我花了两天时间写了一个dd-agent的telegraf input插件。如果不想用telegraf但想用influxdata其他体系产品，那么需要修改chronograf的dashboard内置的json配置文件。如果需要拓扑图，那么我们这套探针模式完全没问题。如果只需要基本（内存、cpu等）以及常用的中间件指标采集，那么采用telegraf部署相当方便，也好维护。

influxdb vs opentsdb

1. 在单机部署上，InfluxDB 非常简单，一两分钟就可以成功运行，而 OpenTSDB 需要搭建 Hbase，创建 TSD 用到的数据表，配置 JAVA 环境等，部署维护相当复杂。
2. 资源占用方面，InfluxDB 都要占据优势，cpu 消耗更小，磁盘占用更是小的惊人。
3. 查询速度，由于测试样本数据量还不够大，速度都非常快，可以看到 InfluxDB 的查询在 10ms 这个数量级，而 OpenTSDB 则慢了接近 10 倍，第二次查询时，由于缓存的原因，OpenTSDB 的查询速度也相当快。
4. 集群方面， InfluxDB 需要购买企业版本 ，而 OpenTSDB 基于 HBase，这一套集群方案已经被很多大公司采用，稳定运行。
5. 维护hbase需要专人维护，反正我没学会。
6. influxdb支持多个filed值，多个tag，opentsdb只支持一个value多个tag。
7. influxdb跟rrdtool一样支持数据的生命周期。

总之：如果公司内部使用，不需要长时间保存历史指标数据，influxdb是不二选择，部署维护相当方便。opentsdb基于hbase这套使用大型平台，这个无可厚非，比较hbase下面的hdfs已经成熟好多年。

附上我修改的opentsdb源码以及知识点介绍，以证明上述比较不是瞎扯淡：
https://github.com/CretanCivil/opentsdb
https://gist.github.com/leapar/245f4f3440727244c833b8c298c711c0

预警模块对比

不需要对比，我们差的太远，当然目前bosun我已经接入，可以一较高下

 boltdbweb --db-name=/usr/local/var/kapacitor/kapacitor.db  --port=8389 --static-path=/Users/*****/go/src/github.com/evnix/boltdbweb/

java梁浩开发的预警系统

定时器任务调度=>查询tsdb=>rabbitmq=>推送、elasticsearch

bosun 看了好久，现在核心代码已经可以自由修改

1. 每个规则编译，因为每个规则都定义了推送方式（mail，post，get），内容模板，数据源(opentsdb,influxdb,elasticsearh)
2. 每个规则启动一个迁程，前程内部定时器
3. 从数据源(opentsdb,influxdb,elasticsearh)读取数据，获得一些列序列化值
4. 根据定义的运算表达式，乘除(+-*/max min mid等)计算出一个值
5. 根据步骤4的值，跟自定义的阈值对比
6. 如果是警告或者错误，那么执行用户定义的推送方式推送

kapacitor

这代码相当复杂，看了一整天还没有完全掌握，暂时无法修改核心代码

1. 分task alert topic
2. 用户定义的一个alert会归到一个topic下面cpu，system等，同时会归到task下面
3. chronograf启用禁用删除alert操作的是task对象
4. alert分stream跟batch
5. 预警时候halder是推送方式，这个可以自己定义扩展，内置的已经相当丰富
6. 主代码启动会注册一系列的service alert task 等等
7. service内部如果需要存储的话都有自己的storage，用的是boltdb。就像java用hsql一样，简单内置。
8. 每个预警一个迁程go runtime内部逻辑就复杂了，还没看懂，因为读取以后进行channel互相之间传递，达到阈值判断已经handler推送。

通过代码比较，kapacitor在开发时候参考了bosun等，因为是新生代，代码功底确实在bosun之上。
kapacitor这个模块一般公司开发者很难超越，该认怂就认怂。

结论

内部开发的这套系统

1. 国际化做完
2. 文档写全
3. 部署线上演示的稳定版本
4. 代码封存

influxdata

1. 安排1~2个人，改一个精简版本，国际化，日本客户部署这套
2. 定制api以及auth，方便集成到其他项目中，供管理员查看健康状况

zabbix

给点时间，安排人读zabbix源码，否则根本没有任何理由说服客户不用zabbix

http://blog.fatedier.com/2016/07/05/research-of-time-series-database-influxdb/