开源服务内部监控系统（二） ganglia简介

在上文 开源服务内部监控系统（一），简单介绍了一下开源监控系统Graphite。本篇将简单介绍一下颇有名气的Ganglia与个人的使用体验。从功能上讲，Ganglia远比Graphite强大。除了监控服务内部状态之外，Ganglia本身就能做到对服务器节点状态(包括CPU使用,load,memory占用,network占用)的整体监控。

Ganglia的架构

Ganglia是一个可扩展的，分布式监控系统。我google翻译了一下单词Ganglia，有神经节的意思，正如其名，Ganglia正是采用了层次化的设计思想为大规模的分布式集群而设计的服务感知系统。按官说介绍，ganglia可支持2000多个节点的集群的监控工作。
Ganglia采用XML数据格式，RRDtool作数据存储与绘图。上一篇提到的whisper类似，RRDtool同样都是采用固定文件大小的环形数据库。

 Ganglia 主要包括三个部分：gmond,gmetad,ganglia web。

Gmond

Gmond是一个安装在被监控节点的监控代理。Gmond具有以下四点责能：

• 监控主机状态变化信息。
• 发布相关变化。
• 通过主播/单播方式监听其他ganglia节点状态，将它们保存在内存缓冲区中。
• 响应请求，以XML格式汇报集群状态。
  默认情况下，gmond以多播的方式工作的，这样每个gmond能接收到集群所有节点的 metric数据。这是ganglia鲁棒性的一个重要实现，当任何一个监控节点挂了，gmetad可以切换到其他任意存活节点上拉取数据。

Gmetad

Gmetad 会定期从数据源收集数据，最终将metric数据存储在RRD存储引擎中,可以为Ganglia Web导出聚合后的XML数据。Gmetad的数据源可以是Gmond,也可以是Gmetad进程。数据源直接以ip形式配置，可以采用多个ip代表一个数据源的方式实现failover。正是因为每个Gmond收集了它所在集群的整个状态信息，所以Gmetad天然的能做到对集群状态数据聚合的功能。（这是Graphite所做不到的。）

Ganglia Web

顾名思义，Ganglia web是Ganglia系统的前端展现部份。Ganglia web是用php写的，依赖gmetad生成的图表。

Ganglia与自建服务的集成

Ganglia具有扩展性很强，使用者可以自定义metric发送给Gmond.
例如，Jmx是java开发者用于暴露服务内部状态的很好的工具，但它没有解决后续的问题，即数据的汇总与图表展现。很多文章都有提到jmxtrans这个解决方案，它本身也是用Java 实现的，以JSON作配置。使用可以在Gagnlia web上看到java服务的jvm内存使用与回收的报表。详细配置不表，其实我也没干过。感兴趣的话，很可以在网上找到关于如用采用此方案实现Graphite监控hadoop,flume,kafka,storm等集群的配置方法。
向ganglia加入自定义metric还有两种方法，一种是通过命令行的方式运行Gmetric，另一种是通过Ganglia提供的面向c和python的扩展模块，加入自定义的模块支持。
目前我们使用的方案是利用metrics库中的GangliaReporter工具类，向Gmond发送自义的Gmetric信息。 Metris库的pom如下定义：

<dependencies>
    <dependency>
        <groupId>com.codahale.metrics</groupId>
        <artifactId>metrics-core</artifactId>
        <version>${metrics.version}</version>
    </dependency>
</dependencies>

对应Graphite，有GraphiteReporter。

 

个人体验

尽管本文主要是以服务开发者角度，介绍服务内部的状态的监控，但从文中可以以会得出，ganglia所做不仅于此，他可以方便的帮你监控服务以外的服务器节点的状态信息。而且他在大规模集群监控上的表现，使得Graphite就显得有点小打小闹。让我更看重的一点是，通过用户配置主动分组，可以将不同集群的节点归属到不同的Source。无需用户额外的开发工作，就可以将同个Source中的节点的状态信息整合，绘制到一张图表中。如下图所示，同一个集群中的47个结点的CPU使用、load等信息各自被汇总到一个图表中，而Graphite却无法做到。

 

 说到缺点，首先让我感觉不爽的，是Ganglia web的界面，与Graphite的Tessera相比，就显得逊多了（可见一向注重功能与实用的后端开发工程师，也是认脸的）。最初使用时，也让人不知所措。Ganglia web采用php开发，也给我一种不知如何更好定制的感觉（可能还是我个人的语言偏见作祟）。

还有一个让我不爽的地方是，Ganglia依赖Gmond的做法，意味着，你每个节点被监控的前提是该节点上Gmond的安装与稳定运行。

总结

总的来说，Ganglia从功能上讲是远比Graphite强大的。但对比Graphite的简单易用，界面清爽，ganglia又显得有点过于复杂。所以对小规模的集群或者单机服务进行监控时，我更倾向于使用Graphite。
无论Ganglia还是Graphite都有一个共同的缺点，它们只是完成了监控的角色，但没有报警功能。所以如果只布署了Ganglia或者Graphite，大多数情况下，很可能是当发生故障一段时间之后，我们都浑然不知，等大错已经铸成之后，我们才会去看一下相应的图表，做一些事后分析。目前Ganglia已有与Nagios的整合方案，来解决这个问题。至于Graphite目前我还没找到类似的方案。这里面的原因，我觉得很可能是因为Ganglia更多被当作运维工具，得以得到“运维界”的重视。而Graphite更多是一种开发者角度的监督工具，与运维工具结合的机会就少得多。自然的，发现这个问题并愿意下足功夫解这个问题的强迫症患者并不多。

 

20150822首发于3dobe.com   http://3dobe.com/archives/164/

iteye链接： http://quentinxxz.iteye.com/blog/2238830/