1.同事反映某ambari集群访问不了，故登陆上去， 发现几个节点的磁盘空间全占满了，细查了一下，发现zk日志占用巨大。 当时以为很简单，删除日志，腾出空间，再重启ambari中的所有服务。  结果5分钟过去后， 发现namenode以及后面的什么 hbasemaster等都无法启动。 尝试不断重启等操作后无果。

2.细下心来看日志。首先看namenode相关的日志，

关键日志如下：

WARN org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited 96070 ms (timeout=120000 ms) for a response for getJournalState(). Succeeded so far: [XXX.XXX.XXX.XXX:8485]

发现是写journalnode 出错。 一直在等待。

看journalnode的3个节点是启动成功的,看journalnode的日志也是正常的。 后面各种尝试，始终卡在这里。

3. 后来偶然想到会不会由于集群中的各个节点磁盘空间并不是同时占满，那有可能就是数据完整性的问题， datanode中的数据丢失不会导致namenode启动问题。那就只剩下namenode中的元数据了， 分别看各个journalnode的 元数据目录 

/hadoop/hdfs/journal/mycluster/current

统计文件个数：

ls /hadoop/hdfs/journal/mycluster/current/ | wc -l

发现有一个journalnode的个数和其它两个不一样。   果断去有问题的节点， 删除原文件夹， 再重启journalnode的所有节点

4.再次重启namenode  发现报错不一样了， 报

No live collector to send metrics to

这个简单， 是Metrics Collector 没启动成功导致的。

5. 启动Metrics Collector  发现它卡在hbase:meta相关表那里， 此时hbase还没启动成功， 果断删除 Metrics的数据 （也可以备份一下）

rm -rf /var/lib/ambari-metrics-collector/*

6.再重启 Metrics Collector    成功

7.重启namenode 成功

8.重启datanode 成功

9.重启hbase相关  结束。