我的监控世界观(4) — 监控数据的存储 RRD or RMDB OR Hbase
版权声明 本站原创文章 由 萌叔 发表
转载请注明 萌叔 | https://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, 它没有集群模式