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产品线，基于它上面做业务需求开发

预警模块对比

不需要对比，我们差的太远，当然目前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/