opentsdb遇到的坑和优化建议_opentsdb 性能问题

  opentsdb是基于hbase的时间序列数据库，数据库能力依赖于hbase集群，是一个比较重型的监控解决方案。网上介绍比较多，但大多只是粗浅的介绍，在实际使用了一段时间后也遇到了一些坑和一些使用方法，跟大家分享下。

  1.opentsdb能做什么

   一个完善的监控系统应该大致包括收集，存储，展示，报警这四大块。

   opentsdb主要功能还是一个时间数据库，存储收集到的监控数据，另外官网还附带了一些常用的监控脚本。opentsdb也有一个展示页面但是做的非常简单。展示和报警还需要找其他组件配合。推荐可以使用grafana。

  2.opentsdb遇到的一些坑

  我在项目中做了一个日志服务，全量存储分析日志后的数据，每天大概有1亿左右的数据。

   第一次安装测试时，我只部署了一个opentsdb，读写都一个，经常出现opentsdb假死，只能重启opentsdb才能解决问题。开始以为访问量过大造成的，就部署了两个opentsdb，读写分离。运行一段时间后发现，写数据的opentsdb运行稳定，但是读数的opentsdb依然经常假死，后来找官网的文档，有一条大致的意思是不要跨太大时间范围查询，否则容易出现内存不足。因为opentsdb是根据查询条件把所有的符合条件的数据都查到内存再聚合，时间范围太大容易导致内存不足。（其实我也只是查询最近24小时的数据）。

  3.一些优化

   1.又写了一个调度任务，先把全量的数据按1s,1min,5min,10min等聚合。这样极大的减少了查询数据点,提升查询效率

    2.如果需要个比较大的监控集群，建议建多个hbaes集群，一个hbase集群专门存储原始的监控数据，另外一个存储聚合后的监控数据。可以极大提高查询效率。