Gmond：Gmond运行在每台计算机上，它主要监控每台机器上收集和发送度量数据（如处理器速度、内存使用量等）。

Gmetad：Gmetad运行在Cluster的一台主机上，作为WebServer，或者用于与WebServer进行沟通。

GangliaWeb前端：Web前端用于显示Ganglia的Metrics图表。

Hadoop和HBase本身对于Ganglia的支持非常好。通过简单的配置，我们可以将Hadoop和HBase的一些关键参数以图表的形式展现在Ganglia的WebConsole上。这些对于我们洞悉Hadoop和HBase的内部系统状态有很大的帮助。

在Hadoop的conf文件夹下面，找到hadoop-metrics.properties，配置好Ganglia的Server即可。这里要注意，Ganglia3.0和Ganglia3.1的区别，它们使用了不同的class。

dfs.class=org.apache.hadoop.metrics.ganglia.GangliaContext31

dfs.period=10

dfs.servers={Ganglia_Server}:8649

有了这些图表，Hadoop和HBase就不再是一个黑盒。无论是Hadoop的Namenode、Datanode，还是HBase的MasterServer、RegionServer任何时刻的情况，都会一目了然。由于图标的跨度可以是小时、天、月甚至是年，这样，就可以非常方便地定期生成周报、月报和年报。同时，根据图中Metrics的状况，我们可以通过调整参数、增加内存和硬盘、增加机器等的方法调整单个机器或者整个Service的性能。

图3Hadoop其中一个DataNode的Metrics

Nagios最大的问题在于不能洞悉到Service内部的状况。像Hadoop、HBase这样的分布式系统，一个节点的故障并不等于整个Service的故障，影响的只是Service的性能。所以，在测定Service的SLA时，我们不能以某一台机器的故障作为Service故障的评判标准。比如在我们的HBaseSLA的设定上，我们定义了HBaseService完全不能工作的评判标准如下。

MasterServer联系不上。所有RegionServer都无法联系上。-ROOT-表无法访问。.META.表无法访问。

图4Ganglia对Hadoop/HBase使用情况的监测

那么，我们就可以根据这个规则定义SLA，通过定期调用HBaseAdmin相应API，将测试的结果发给Ganglia。采用同样的方法，我们还可以自定义一些规则，监视HBaseMaster、Zookeeper等的情况。

通过这些方法，我们完全能够针对Hadoop/HBase使用的实际情况，做出Service级别而不是机器级别的监控系统并生成报表。

此外，Ganglia还可以通过Server反馈回来的Load信息，给出各个机器的Load情况，给我们做升级和扩容提供依据。

如图5所示，Ganglia分别会用不同颜色，标注出当前时刻的机器Load分布情况。如果Load过重，就应该检查机器的具体使用情况。

图5HBaseClusterLoadMetrics

Ganglia的安装配置，可以参考：http://www.spnguru.com/?p=604。

Splunk：像查Google一样查日志

有了Nagios和Ganglia，算是成功了一大半。作为一名优秀的管理员，我们需要具备一定的Troubleshooting能力，对一些常见的问题能给出解决方案。那么，对日志的分析就必不可少。

但Hadoop/HBase的日志分布在各个机器上面，而日志之间关联性强。Client端的错误有可能是RegionServer引起，而RegionServer的错误有可能是Zookeeper导致。有没有一个统一的日志管理平台呢？

众里寻它千百度，蓦然回首，我们找到了Splunk——日志界的Google。

很遗憾，Splunk不是开源的，但它的免费版本提供每天500MB日志索引。如果数据量较小，通过定义好Log的级别，基本上也能满足需求。但对于数据量较大的公司，就有些捉襟见肘。

Splunk支持AdHoc的日志搜索，而且可以与Nagios配合使用。比如Nagios报警某台RegionServer端口不可达，我们收到Notification后，登录Splunk，直接搜索shutdown和host名称，找到RegionServer退出的日志。点击详细信息，分析日志，就能快速定位问题。如图6所示。

图6Splunk与Nagios配合使用进行日志搜索

对Hadoop和HBase有了进一步了解后，我们可以利用Splunk实时检测日志中的关键字，定义关键字规则，如监控“shutdown”、“quit”、“ERROR”、“ZookeeperSessionExpired”等，一旦出现，利用Splunk的Notification功能，发出邮件通知管理员，管理员通过Splunk定位问题，就可以在系统真正出现问题之前，对系统进行调整，防患于未然。

总结

搭建一套云计算平台，强大的监控管理系统是必不可少的。当然，任何工具都不是万能的，在实际维护过程中，我们也发现，Nagios和Splunk经常出现误报，如果规则定义得不好，大量的警报邮件如潮水一样涌来，反而掩盖了真正的问题。可以说，在云计算平台的运维管理上，没有一劳永逸的事情，随着规模的不断增大和应用的不断多样化，需要大家不断地实践和总结。