在CDH安裝完成後或者CDH使用過程中經常會有錯誤或者警報，需要我們去解決，積累如下:
解決紅色警報
時鐘偏差
這是因爲我們的NTP服務不起作用導致的，幾臺機子之間有幾秒鐘的時間偏差。
這種情況下一是把NTP重新整理配置一下。
一種是在操作裏調整報警誤差範圍。
因爲NTP的時間同步是平滑同步，不是跳躍式同步，如果設置得不好的話，很難校驗出它同步成功了沒，總感覺會缺少幾秒鐘的感覺。
有一種解決方法是 我們這裏不用NTP的自動同步，而是使用crond每分鐘ntpdate 跳躍式同步一次。
這種方法不建議在生產環境使用，但是一般生成環境都有外網，所以就能正確設置NTP。
所以下面我們在局域網無外網的情況下可以用以下方法(偏方)確保時間同步:
爲了確保能同步時間，我們這裏再加上定時同步步驟。
首先保證cm0的NTP服務是開啓的。
然後停止cm1和cm2的NTP服務。
在cm0中運行
service ntpd start
在cm1和cm2中運行
service ntpd stop
cm1上的配置：修改crond自動運行程序的配置文件：vi /var/spool/cron/root (此處是以root用戶爲例，如果是其他用戶，替換爲對應的用戶文件名，即可)，在該配置文件中，添加一行：*/1 * * * * ntpdate cm0(每隔一分鐘，從cm0同步一次時間）保存，重新啓動crond服務:service crond restart一分鐘以後，cm1的時間就同步爲cm0的時間了。cm2的配置：同cm1一樣。局域網內還有其他機器，設置方法也同cm1一樣。
然後CM中的NTP驗證需要抑制。
變綠了。
進程狀態
HBase--RegionServer--cm1---不良 : 該角色的進程已退出。該角色的預期狀態爲已啓動。
這種情況是cm1的HBase服務好像掛了。
點擊在執行運行狀況測試時查看此角色實例的日誌找一下原因慢慢排查。
org.apache.hadoop.hbase.YouAreDeadException: org.apache.hadoop.hbase.YouAreDeadException: Server REPORT rejected; currently processing cm1,60020,1480324093445 as dead serverat org.apache.hadoop.hbase.master.ServerManager.checkIsDead(ServerManager.java:426)at org.apache.hadoop.hbase.master.ServerManager.regionServerReport(ServerManager.java:331)at org.apache.hadoop.hbase.master.MasterRpcServices.regionServerReport(MasterRpcServices.java:344)at org.apache.hadoop.hbase.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$2.callBlockingMethod(RegionServerStatusProtos.java:8617)at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2170)at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:109)at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)at java.lang.Thread.run(Thread.java:745)
Failed deleting my ephemeral nodeorg.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /hbase/rs/cm1,60020,1480324093445at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:873)at org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.delete(RecoverableZooKeeper.java:178)at org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNode(ZKUtil.java:1236)at org.apache.hadoop.hbase.zookeeper.ZKUtil.deleteNode(ZKUtil.java:1225)at org.apache.hadoop.hbase.regionserver.HRegionServer.deleteMyEphemeralNode(HRegionServer.java:1431)at org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:1100)at java.lang.Thread.run(Thread.java:745)
查了下資料發現這個問題還比較常見。我們這日誌中也能看見
org.apache.hadoop.hbase.util.JvmPauseMonitorDetected pause in JVM or host machine (eg GC): pause of approximately 2489msNo GCs detected
這種情況是FULL GC，就是內存不夠用了。
JVM垃圾回收異常的錯誤。
界面中也能看到大概原因
發現有2種解決方法，或者同時使用:
方法一 設置達到70%時清理GC
方法二 增加超時時長
方法一 設置達到70%時清理GC(推薦)
hbase中和GC相關的參數：
修改前（默認）：
export HBASE_OPTS="$HBASE_OPTS -ea -verbose:gc -Xloggc:$HBASE_LOG_DIR/hbase.gc.log -XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"
諮詢開發修改後：
export HBASE_OPTS="$HBASE_OPTS -verbose:gc -Xloggc:$HBASE_LOG_DIR/hbase.gc.log -XX:ErrorFile=$HBASE_LOG_DIR/hs_err_pid.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=70"
-XX UseConcMarkSweepGC ：設置年老代爲併發收集。（新老都有）
老：-XX:+CMSIncrementalMode :設置爲增量模式。適用於單CPU情況。
新：-XX:+UseParNewGC：設置年輕代爲並行收集。可與 CMS 收集同時使用。
-XX:CMSInitiatingOccupancyFraction=70:這個參數是我覺得產生最大作用的。因爲最終的目的是減少FULL GC，因爲full gc是會block其他線程的。
默認觸發GC的時機是當年老代內存達到90%的時候，這個百分比由 -XX:CMSInitiatingOccupancyFraction=N 這個參數來設置。concurrent mode failed發生在這樣一個場景：
當年老代內存達到90%的時候，CMS開始進行併發垃圾收集，於此同時，新生代還在迅速不斷地晉升對象到年老代。當年老代CMS還未完成併發標記時，年老 代滿了，悲劇就發生了。CMS因爲沒內存可用不得不暫停mark，並觸發一次全jvm的stop the world（掛起所有線程），然後採用單線程拷貝方式清理所有垃圾對象，也就是full gc。而我們的bulk的最開始的操作就是各種刪表,建表頻繁的操作，就會使用掉大量master的年輕代的內存，就會發生上面發生的場景，發生full gc。
方法二 增加超時時長
加大zookeeper會話超時時間，編輯hbase-site.xml文件，添加下面的屬性
zookeeper.session.timeout
120000
hbase.regionserver.lease.period
240000
hbase.rpc.timeout
280000
加大zookeeper會話最大超時時間編輯zoo.cfg 提高MaxSessionTimeout=120000，修改後重啓zookeeper。
zookeeper的超時時間不要設置太大，在服務掛掉的情況下，會反映很慢。
我們這裏在CM管理界面中更改，找到RegionServer ( Cluster 1 HBase cm1 )界面，點擊配置。看到如下圖:
我們找參數修改保存即可。
然後在右上角操作中重啓RegionServer 。
羣集連接
羣集連接 ( Cluster 1 HBase RegionServer cm1 ) 2016年11月29日, 下午3點48 CST
測試 HBase Master 是否將 RegionServer 視爲已連接。
不良 : 該 RegionServer 當前未連接至其 cluster。
這種情況就是RegionServer 服務掛了。但是一般都是伴隨着其他原因的。
解決完其他原因之後嘗試重啓RegionServer 即可。
如圖 點擊 RegionServer
右上角重啓
啓動成功。
好了，HBase綠了。
HDFS-副本不足的塊
副本不足的塊 ( Cluster 1 HDFS ) 2016年11月29日, 下午4點02 CST
測試 HDFS 是否具有過多副本不足塊。
不良 : 羣集中有 707 個 副本不足的塊 塊。羣集中共有 710 個塊。百分比 副本不足的塊: 99.58%。 臨界閾值：40.00%。
操作
爲此服務更改“副本不足的塊監控閾值”。
建議
這是 HDFS 服務級運行狀況測試，用於檢查副本不足的塊數是否未超過羣集塊總數的某一百分比。
該運行狀況測試失敗可能表示 DataNode 丟失。使用 HDFS fsck 命令可確定哪些文件含有副本不足的塊。
可使用 副本不足的塊監控閾值 HDFS 服務範圍內的監控設置配置該測試。
原因
原因是設置的副本備份數與DataNode的個數不匹配。
我們在之前理論篇中已經說明了dfs. replication屬性默認是3，也就是說副本數---塊的備份數默認爲3份。
hadoop基礎----hadoop理論(三)-----hadoop分佈式文件系統HDFS詳解
但是我們這裏集羣只有兩個DataNode。
所以導致了達不到目標---副本備份不足。
解決方法
這種情況下的修復有2個步驟，1是設置目標備份數爲2，2是通過命令更改當前備份數。
副本不足和副本過多都可以用這2個步驟解決，主要是跟DataNode的個數對應。
設置目標備份數爲2
點擊集羣-HDFS-配置
搜索dfs. replication，設置爲2後保存更改。
dfs.replication這個參數其實只在文件被寫入dfs時起作用，雖然更改了配置文件，但是不會改變之前寫入的文件的備份數。
所以我們還需要步驟2
在cm0中通過命令更改備份數：
su hdfs
hadoop fs -setrep -R 2 /
這裏的-R 2的數字2就對應我們的DataNode個數。
好了，HDFS也綠了。
root運行hadoop命令還是很多Permission denied
修復root使用
permissions of '/user': Permission denied. user=root is not the owner of inode=user
這是因爲這些文件不是本地文件，而是集羣上的文件。
所以root用戶對他們沒有操作執行權限。
而CDH安裝hadoop時默認設立了hdfs用戶是對集羣文件的最高權限用戶。
所以需要給root用戶集羣文件的權限。
2個步驟
1.在mater機器也就是cm0中運行一下命令給權限即可。
sudo -u hdfs hadoop fs -mkdir /user/root
sudo -u hdfs hadoop fs -chown root:root /user/root
sudo -u hdfs hadoop fs -ls /user
sudo -u hdfs hadoop fs -chmod 777 /user
2.在hdfs的配置文件中，將dfs.permissions修改爲False
兩個步驟都需要執行。
重啓HDFS服務。
cm0中hdfs用戶運行
如果以上設置後root運行還是會報權限錯誤，那我們還是使用hdfs用戶運行即可。
su hdfs
然後執行命令hadoop fs -setrep -R 2 /等命令。注意是在master機器cm0中su hdfs才行。
如果是在slave機器cm1或者cm2會報sudo: unable to execute /usr/bin/hadoop: Permission denied。