一早例检发现，监控数据没了，检查spark，应用还在，但是error一堆，hbase连不上了，难道又是zk连不上，导致hbase挂了。。。
登陆hbase服务器，妥妥的。。。
再看zk日志显示Too many connections。。。
因为我的spark应用里面基本都会写入hbase，而且这个测试环境zk基本只有我在用，重启spark，发现zk连接数还是居高不下，后面就走了弯路了：
开始以为是我的hbase的client连接数设置的太小了，把zk和hbase的配置全都重新设置了一遍，
设置 hbase.zookeeper.property.maxClientCnxns 值 300,600,1000重启问题依旧；
是不是我的spark应用里面没有关闭hbase连接，造成连接未释放，上周还没问题，过了个周末就不行了，好吧，开始检查修改hbase client，确实没关，修改后，突然想到我的spark应用每次执行完会自动销毁，为什么之前没问题？
测试下，果然问题依旧。。。
这下要好好想想了，还是从头开始检查吧:
1、检查下zk
看看2181端口都谁在链接
sudo netstat -nap |grep 2181
好多。。。挨个看看，突然发现有个进程是一个调度系统的执行器，而且数据巨多，怎么没有关闭呢？
这个调度系统是上周刚刚部署的，查~
2、检查调度系统
调度日志各种mysql链接不上，怎么mysql挂了？果然mysql已经无法链接了。。
其他系统的应用把mysql链接都沾满了，估计是谁的程序出bug了。不管他，重启mysql，可以链接了
这个调度系统里面也有写入hbase的动作，对应的客户端都一个，肯定也没关闭链接
3、修改调度系统源码
修改hbase客户端代码，添加destroy过程
更新部署，重启，再看zk连接数，正常了
总结：
这个故障实际是个连锁反应造成的 ：
调度系统mysql连不上了，导致写入hbase动作未完成，且未释放（严重bug），由于调度系统会不停的执行调度任务，累计造成zk链接数高涨，其他spark应用都跟着出问题了
修改了hbase客户端关闭链接的bug后，故障解决。
不过这里有个问题，之前hbase写完未关闭的bug存在，但是没出问题，是因为spark已经自动销毁了。但是调度系统里面由于未能及时销毁，造成遗留的bug终于爆发了，出现上面的故障。