我这篇文章[http://blog.csdn.net/u014654002/article/details/54345381]里写过的kairosdb，那是我开始接触监控系统的第一步，它帮助我了解了时序数据库在监控端的优秀表现。
kairosdb算是相当优秀的监控系统存储后端，并且支持使用grafana（一款可视化效果极佳的数据可视化软件）作为数据展示端。同时也支持使用Tcollector（openTSDB专用的数据采集工具，集成了大量的数据采集脚本，覆盖面很广泛）作为数据采集端，并且在我学习kairosdb的过程中，发现其api很清晰，适合配合各种插件进行二次开发。
如果仅仅是做数据展示，那么kairosdb无疑是很合适的，但是监控系统往往还需要对监控的数据做告警监控，这样才是一个完整的监控系统，而在当时我学习kairosdb的过程中，没有发现有合适的插件能完成这样一个功能，自己去写的话无疑会耗费很长的时间。grafana自身也带有一些告警功能，但是功能很单一，配置起来也不方便，所以也放弃了这个方法。
后来想到可以使用与kairosdb很相似的时序数据库OpenTSDB，因为OpenTSDB的实际存储是HBase，可以使用大数据的一些插件完成数据计算从而实现报警。使用OpenTSDB，因为之前没有接触过大数据相关的东西，所以Hbase的部署、配置给我带来不少问题。最后使用OpenTSDB的过程中，发现grafana对OpenTSDB的支持和对接更友好，使用起来很方便，Tcollector更不用说了，这个采集器本身就是为OpenTSDB写的。所以数据展示这部分实现起来很高效。
在使用OpenTSDB实现报警功能的阶段，发现并没有像想象中那么简单···
最后是找到了open-falcon来实现我们监控系统的报警功能。open-falcon是近两年出现的监控系统，其发展势头和功能、架构都很不错，并且其支持使用
OpenTSDB作为存储后端，这样使得我们前面做的事情都没有白费。我们数据展示端使用原来的Tcollector+OpenTSDB+grafana的形式，本来是想直接使用Tcollector将数据发到open-falcon的数据转接组件transfer中，但是open-falcon只允许其他插件将数据传给Falcon-agent，再由agent传给transfer，所以我们Tcollector需要修改传输协议，是的数据格式与agent端对应。
最后形成的结果是Tcollector+agent+OpenTSDB+（grafana、open-falcon），从而构成整个监控系统。
而使用Tcollector+agent两个采集端，会显得结果有点冗余，这个只能后面再进行优化。
就目前部署的情况来看，这个系统架构基本能实现对系统、机器、数据库服务等的监控。但是由于监控需求的不同，需要花费一定的时间去修改Tcollector采集器，需要花费时间去制作grafana的Dashboard。
grafana毕竟是模板化的工具，在使用上比之自行开发会存在一些限制，但胜在部署方便、快速，也基本能满足需求。