一早例檢發現，監控數據沒了，檢查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終於爆發了，出現上面的故障。