背景

过年前，寂寞哥给我三台机器，说搞个新的openTSDB集群。机器硬件是8核16G内存、3个146G磁盘做数据盘。

我说这太抠了，寂寞哥说之前的TSDB集群运行了两年，4台同样配置的机器，目前hdfs才用了40%，所以前期先用着这三台机器，不够再加。

于是我只好默默地搭好了CDH5、openTSDB(2.1版本，请注意此版本号)、bosun，并在20台左右的机器上部署了scollector用来测试，然后将dfs.replication改为了2，一切正常。

过完年回来后，开始批量在主要业务机器上部署scollector，大概增加到了160台左右。运行了一个星期后，正在添加各种grafana dashboard的时候，就开始发现各种异常了。

这篇文章主要是总结了处理openTSDB各种状况的过程。需要注意的是，这是个持续的过程，中间修改了非常多的参数，有些问题是做了某项修改后，有很明显的改善，而有些问题的解决其实回头看的时候并不能知道究竟是哪些修改解决了问题，也还没有时间重新去修改验证。因此，本文并不能作为一份解决问题的FAQ文档，纯当本人处理问题的记录罢了。

打开文件数

首先是发现了无法打开master:4242页面了，查看了openTSDB的日志，很显眼的too many open file，于是检查了ulimit，还是默认的1024，这肯定不够用的。需要修改系统的资源限制：

首先是/etc/security/limits.conf

# 添加
* soft nofile 102400
* hard nofile 102400

然后是/etc/profile

# 文件末尾添加
ulimit -HSn 102400

重新登录，重启openTSDB，然后检查进程的打开文件数：

# cat /proc/$(ps -ef | /bin/grep 'opentsd[b]' | awk '{print $2}')/limits | /bin/grep 'open files'
Max open files            102400              102400              files

修改已生效，打开文件数的问题解决了。

内核参数

接着没过1小时，就出现了查询非常久都出不来的情况，于是就注意观察openTSDB的打开文件数，然而只有1500左右，怀疑可能是并发数和backlog的问题，检查了连接数以及当前的内核参数，发现此时连接数并没有超过内核设置。不过本着尽量排除影响的原则，还是改大了这两个内核参数：

net.ipv4.tcp_max_syn_backlog = 16384  
net.core.somaxconn = 65535    

没有什么新的线索的情况下，只好又重启了TSDB。重启后又恢复正常了。于是用watch命令持续盯着openTSDB的连接数，一边用grafana每30秒刷新页面。发现正常情况时，连接数大概是900以下，而出现问题时(grafana刷不出来图时)，连接数突然就上升到1200以上，然后1分钟内蹦到了2900。赶紧使用netstat看下是什么状态的连接数上涨了，发现是TIME-WAIT。检查net.ipv4.tcp_tw_reuse已经是1了，然后这天由于有别的事情要忙，就暂时没再看了。

regionserver java堆栈大小

第二天早上的时候发现又是grafana刷新不出图，后来上CDH管理页面才发现是其中有一个regionserver(tsdb3)挂了：经大数据组大神提醒，多半是GC导致regionserver挂了。查看果然有个小时级别的GC：查看了HBase Regionserver java堆栈大小，原来才设置为2.44G。请教了大神，说是因为我部署的这个CDH集群，除了HBase之外还有其他的其实对于openTSDB没有用的Hive、Hue、Oozie、Sqoop2等，所以CDH会根据角色的情况分配java堆栈大小，但是我们完全可以将这些没有用到的服务关掉，手动将HBase Regionserver java堆栈大小设置为物理内存的一半，也就是8G。

改完配置重启了HBase，貌似一切又正常了。而且，由于有更重要的问题要处理，因此就先暂时放一放了。

HBase表压缩

那件更重要的事情，就是磁盘空间用得太快了。才160台机器一星期的数据，磁盘空间就才90%下降到80%，我一开始觉得不可能，之前的旧集群，用了两年才用了40%，新的怎么一星期就用了10%呢，这么下去难道只能用10个星期？后来看了下CDH的图，每秒datanode写入都有1M左右，146G的硬盘前途堪忧啊！原来是旧的tcollector是自己写的收集脚本，一台机器收集的metric平均才30来个，而scollector不算自己写的外部脚本，本身就提供了上百个metric，再加上自己写的外部收集脚本，这么下来两者的数据根本就不是一个数量级了。

想起之前在初始化TSDB的HBase的时候，没有采用压缩：

env COMPRESSION=NONE HBASE_HOME=/usr/lib/hbase /usr/share/opentsdb/tools/create_table.sh  

不知道现在还能不能开启表压缩，赶紧去请教大神。大神甩给我一个文档：