Fork me on GitHub

版权声明 本站原创文章 由 萌叔 发表
转载请注明 萌叔 | http://vearne.cc

真正有必要存储的数据可能有两个

1) 应用的历史状态信息(时序数据)
2) 应用的监控项数据(元数据)

1. RRD

早期的开源监控系统,如cacti、nagios和ganglia,采用的是RRD,这种做法的好处是占用空间小,而且数据点的聚合是自动完成的,不需要监控系统的开发者自己开实现,另外出图也比较方便

但它的缺点也不少:
– 1) 数据的提取和迁移非常的不方便
– 2) 聚合点的调整不方便
– 3) 监控数据的后期统计和分析十分不便
– 4) 由于它的出图是直接保存为图片格式的导致传输成本更大

2. RMDB

这几年开始,不少监控系统如zabbix开始采用RMDB来存储监控项的数据,个人认为这种做法,应该是各大互联网公司的监控系统的主流做法,监控系统的数据存储具有以下特点:

  • 1) 大量的写操作,但是写操作相对均匀,突发现象较少
  • 2) 对时间的敏感度不是特别高,特别适合批量写的做法
  • 3) 读操作较少(相对于写操作),单次读取的数据量较大
  • 4) 且一般只做插入,不做变更

对于以mysql为代表的关系型数据库而言,经过调优以后,每秒至少可处理 10000+的写请求,再考虑读写分库的做法,对于一家拥有数万台机器的公司而言,我相信以关系型数据库作为存储,应该也是没有问题的

3.Hbase

以OpenTSDB作为代表,以Hbase 来存储数据
这个做法的好处是存储空间可以无限扩容,提取速度也比较快,因为笔者对Hbase 也不是特别了解,因此也不敢妄下结论,但是总是觉得用它来作为存储,有些杀鸡用牛刀的感觉。

后记

本文是我2014年的文章
这里做一点补充
其实所有的时序型数据库,比如ES,InfluxDB等等都可以用来存储监控数据
监控数据的典型特点是
高频写,低频读,而且一般比较平稳,没有太多的尖峰
* 对于RRD数据库好处是空间小,且可以自动聚合,不过扩容比较难,需要预先就设定好大小
* 对于RMDB的最大问题,数据需要经常清理,但是向MySQL这样的数据库,即使数据删除了,所占的磁盘空间也不能自动回收,这个是比较麻烦的
* 对于HBase Hadoop这套东西上手的难度太大,一般人玩不转。这也是让人都疼的东西
* 对于ES,搭建确实简单,如果数据按月分库,也确实能够支持历史数据清理的问题,不过ES比较吃内存。不过要是数据做前期聚合,就占用空间,后聚合,如果查询时间跨度大,速度有可能变慢
* 对于InfluxDB, 它没有集群模式

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据