关于监控系统的一些想法心得
我这篇文章[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毕竟是模板化的工具,在使用上比之自行开发会存在一些限制,但胜在部署方便、快速,也基本能满足需求。