前面我们讲了云计算管理三大利器之一的Nagios，现在来说说第二大利器Ganglia。

　　Ganglia：看到云计算平台的方方面面

　　Nagios的确不错，但你是不是真的可以喝茶、钓鱼、睡大觉呢？显然还不行。有了Nagios，你基本上可以做个优秀的救火队员，能在事发第一时间到达现场、处理事故。但如何防患于未然，真正做到运筹帷幄、游刃有余呢？

　　我们需要更加精确的数据，能够看到云计算平台的方方面面，能根据这些数据，做出性能调整、升级、扩容等的决策，从而保证Service能够满足不断增长的业务需求。

　　这时候，你需要Ganglia。

　　Ganglia是UC Berkeley发起的一个开源实时监视项目，用于测量数以千计的节点，为云计算系统提供系统静态数据以及重要的性能度量数据。Ganglia系统基本包含以下三大部分。

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

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

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

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

　　在Hadoop的conf文件夹下面，找到hadoop-metrics.properties，配置好Ganglia的Server即可。这里要注意，Ganglia 3.0和Ganglia 3.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的性能。

图3 Hadoop其中一个DataNode的Metrics

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

　　所有RegionServer 都无法联系上。

　　-ROOT- 表无法访问。
　　.META. 表无法访问。

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

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

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

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

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

图5 HBase Cluster Load Metrics