ganglia原理，配置参数
http://www.taobaotest.com/blogs/2519
工欲善其事必先利其器——第三弹 用云存储实现对云计算的监控
引言
大凡集群系统的性能、压力测试，都要通过监控系统进行收集整理。其中ganglia是集群监控最常用的工具之一。它与Hadoop生态圈结合的非常好，且性能优良，不会对系统本身性能造成影响。
Ganglia是UC Berkeley发起的一个开源集群监视项目，包含gmond、gmetad两个服务，以及一个web展示前端。本身部署后就立即可以对cpu、memory、network、disk等情况进行监控汇总。gmond负责收集系统的这些监控指标数据，一般若干个节点会有一个master，负责从子节点上通过tcp协议抓取这些节点的xml格式的监控数据。若干master再向更上一层的master汇总，直到gmetad这一层会将所有数据保存到rrd数据库中。这样层层抓取进而汇总的模式，保证了节点性能不至于受到gmond监控的影响，且各级master也不会产生过多的网络IO压力。
RRDTool负责保存这些监控数据到RRD（Round RobinDatabase）文件中，RRD数据库顾名思义是一个环装的数据库。越久远的数据在这个数据库中就会被不断规整合并，点与点之间的时间差距越来越大，越来越稀疏，当时的细节也跟着逐渐丢失。这样的数据库对于存储大规模集群的监控数据是非常有好处的。它保证了RRD文件的大小可以限制在一定范围内，而且对于集群运维来说，我们往往只关心近期的数据细节，至于过去很久的监控数据看不到细节也没多大妨碍。RRDTool还可以负责绘图，ganglia的web展示上的图正是由此而来。
ganglia和RRD虽然占用系统资源极少，但当集群规模超过5K之后，gmetad对监控数据的收集越来越显得力不从心，而RRD文件即使是高效且压缩的，也同样面临机器IO能力不足的问题。这些都是ganglia这套体系的短板，对于大多数公司团体来说，集群规模远没有达到触发ganglia瓶颈的程度，但是对于云梯来说，这个天花板却是触手可及。
同时RRD数据库的远期数据细节丢失问题，对于集群运维来说毫无影响，但是对于测试人员来说却是一个灾难。因为细节的丢失将导致刚做的性能测试无法与一个月前甚至一年前的同样的测试用例得到的结果进行对比。如果不解决这个问题，那么集群的性能监控对于测试人员的帮助将非常有限。
破解难题
上面提到的问题，在云梯这种大规模集群的测试中都遇到了。早期云梯测试人员试图将监控数据从RRD数据库中提取出来保存到mysql中，这样方便查询、对比、展示。但是对于上百个节点的测试集群来说，mysql数据库往往只需一周时间就会被撑爆。一个简单的指标数据的查询往往就要等上半个多小时才能从mysql中提取出来。而监控数据保存到RRD文件，再使用RRDTool导出监控数据到mysql中，整个过程也是及其低效的。在我接手云梯1项目的集成测试之后，深深的被这个问题所困扰，整理测试数据让每一次的集成测试结果汇总都苦不堪言。
2012年上半年，测试这边开始主导设计DST（分布式测试工具）测试框架，随着云梯项目的进行，DST也在不断迭代中向前发展。其中集群监控数据的收集整理展示被我标记为首要必须完成的功能。经过深思熟虑，最终采用了“替代gmetad，并直接存储监控数据至HBase”这个解决方案，设计的工具被我命名为“GGL2HBase”。
这个方案是做成一个与gmetad类似的服务，直接去所有节点的gmond master上抓取监控数据，从网络拿到后，直接从内存中存储到一个HBase集群中。利用HBase的高效解决了查询慢的问题，同时RRD文件远期数据细节丢失的问题也迎刃而解。
设计细节
HBase是一个典型的key/value结构的nosql数据库，利用其RowKey自动排序的功能，我按机器编号（4字节int型）、指标编号（4字节int型）、时间戳（8字节long型）这样的顺序组合成了RowKey，Value中保存的则是这台机器这个指标当前时间戳的监控数据（16个字节的double型数值）。这样在查询的时候，我可以根据机器名+指标名，快速的scan出一段时间内的监控数据。而存储的时候，我在创建该表时，主动根据开始字节做了split，切分成1024个region（原本设想会有不到1000台机器的监控数据导入HBase，后来随着DST的推广发展，导入的机器数量并发高峰期达到了3000多台的规模，历史上共有6000多台机器正在或曾经导入过监控数据），这样保证了写入的监控数据不会集中分布在某台regionserver上，提高了写入性能。
GGL2HBase工具被我部署在多台机器上，通过并发方式提高抓取监控数据的性能，同时每个工具还启动了一个web服务，查询操作被我封装成了RESTful方式提供给web端实时展示。加入监控的gmond master列表则做成了动态监测，这样保证在增加新机器的监控数据时，导入服务也不会停止，防止了丢数据的可能性。整个过程经过整合优化后，原先需要半个小时以上的简单查询，被我压缩到了毫秒级别。而即使是复杂的运算查询，也控制在了半秒之内（这在最初那个模式中，由于多次查询耗时太长，根本不可能去做）。这个系统持续不断的已经运行超过一年，而我们即使是今天刚做的测试也可以与一年前的数据进行对比，方便历次多条基线的参照，以及快速出测试报告。这套系统完成后，加上DST的自动化功能，促使之前需要至少耗时一个多月的集成测试周期被压缩到了一周之内。
如下图所示，展现十多个指标的数据图（只是作为一个例子），这些数据从10多TB的数据中捞出来只需要不到半秒的时间。
该工具除了速度快之外，还充分利用了gmond汇报数据的特点，完整记录了所有指标的单位、分组、描述等信息，以及所有机器的机器名、IP地址、包含的指标等信息，与前端mysql数据库搭配后，完成了DST对集群信息的整体掌控。
此外，由于是收集了所有被监控节点的所有监控指标数据，因此当我们想查看以前被忽略的某个指标的历史数据时，也完全不用担心找不到这些数据。HBase的海量存储能力保证了再多的数据也能放得下，当前20台规模的HBase集群已经存储了10多个TB的监控数据，而对于整个HBase系统来说，即使存放10年的数据量也是绰绰有余的。
发展计划
当前GGL2HBase的发展方向是有能力兼容接入更多种类的监控数据，完成监控体系的一体化。同时，配合DST前端，更好的展示这些监控数据。并利用HBase集群的能力，将更多的计算过程放到后端集群中去做，减少前端的计算压力。这些都是任重而道远的工作，但是做这些事情本身也是对个人技术能力的考验和提升，而解决问题的过程，更是难得的乐趣。
做个广告：欢迎装上来往，扫描我的二维码或搜索“凡提”加我进行技术交流
运行下列命令可以生成gmond默认配置文件：
User@host:$ gmond -t
配置文件由大括弧括起来的几个section组成。这些section可以粗略划分为两个逻辑分类。第一类中的section处理主机和集群的配置；第二类中的section处理指标数据收集和调度的特定问题。
所有section名和属性不区分大小写，例如下列属性是等价的：
name NAME Name NaMe
有些section是可选的，而有些则是必需的；有些section在配置文件中可能多次出现，而有些section可能只出现一次；有些section还可能包含subsection。
在需要大型复杂配置的情况下，include指令可以将gmond.conf文件划分为多个文件。include指令支持typeglob的使用。例如下列命令表示gmond可以加载/etc/ganglia/confd./中所有以“.conf”结尾的文件：
include('/etc/ganglia/conf.d/*.conf')
注意： gmond.conf快速启动
为了快速启动和运行gmond，只需要设置默认配置文件中“cluster”section的name属性。
配置文件由第三方API——libconfuse进行语法分析。一般规则适用于libconfuse文件格式。尤其是，在表示布尔值时，可以使用yes、true和on表示正值，用no、false和off表示负值。布尔值不区分大小写。
有8个section处理主机自身配置。
section:globals。globals这一section配置守护进程本身的通用特性，它在配置文件中只出现一次。下面是Ganglia 3.3.1中的默认globals section。
globals {
daemonize = yes
setuid = yes
user = nobody
debug_level = 0
max_udp_msg_len = 1472
mute = no
deaf = no
allow_extra_data = yes
host_dmax = 86400 /*secs. Expires (removes from web interface) hosts in 1 day */
host_tmax = 20 /*secs */
cleanup_threshold = 300 /*secs */
gexec = no
send_metadata_interval = 0 /*secs */
}
daemonize（布尔类型）
当值为true时，gmond将在后台分散运行。当在守护进程管理器（如daemontool）下运行gmond时，将此值设置为false。
setuid（布尔类型）
当值为true时，gmond将user属性指定的特定用户的UID作为有效UID；当值为false时，gmond将不会改变其有效用户。
debug_level（整数值）
当值为0时，gmond将正常运行。当debug_level大于0时，gmond将在前台运行并输出调试信息。debug_level值越大，输出越详细。
max_udp_msg_len（整数值）
该值是gmond发送包所能包含的最大长度。一般情况下该值默认不变。
mute（布尔类型）：
当值为true时，不管其他配置指令如何，gmond将不能发送数据。“单收”（mute）gmond节点只不向其他gmond守护进程发送数据，但仍然会响应诸如gmetad的外部轮询器。
deaf（布尔类型）：
当值为true时，不管其他配置指令如何，gmond将不能接收数据。在每个集群内拥有成千上万节点的大型网格中，或者在细致优化的HPC网格中（例如充分利用CPU的空闲周期），为减少汇聚集群状态的相关开销，经常将普通的计算节点设置为单发。在这些情形下，某些特点的节点被预置为单收，此时这些节点的性能指标将不会被测量，因为这些节点将不会用作网格的运算。因为这些节点的任务是汇聚，所以它们的性能数据会“污染”集群内其他的功能部分。
allow_extra_data（布尔类型）
当值为false时，gmond将不会发送XML的EXTRA_ELEMENT和EXTRA_DATA部分。该值主要应用于用户使用自己的前端并希望节省带宽时。
host_dmax（以秒为单位的整数值）
dmax是delete max的缩写。当值为0时，即使远程主机停止报告，gmond也不会从列表里删除该主机。如果host_dmax设置为正值，当gmond在“host_dmax”秒内接收不到某台主机的数据，gmond将删除该主机。
host_tmax（以秒为单位的整数值）
tmax是timeout max的缩写，代表gmond等待一台主机更新的最长时间。因为消息可能在网络中丢失，所以如果在4倍的host_tmax时间内接收不到某台主机的任何消息，gmond就认为该主机已经崩溃。
cleanup_threshold（以秒为单位的整数值）
gmond清除过期数据的最小时间间隔。
gexec（布尔类型）
当值为true时，gmond将允许主机运行gexec任务。这种方式需要运行gexecd并安装合适的验证码。
send_metadata_interval（以秒为单位的整数值）
该值设置gmond两次发送元数据包的时间间隔。元数据包是用来描述所有激活指标的数据包。该指令默认设置为0，表示gmond只有在初始启动和收到其他远程运行的gmond节点请求时才会发送元数据包。如果向集群内添加一台运行gmond的主机，则该主机节点需要向其他节点公布自身信息，并告知目前支持的指标标准。在多播模式下，由于任何一个节点都可以向集群内的其他节点请求发送元数据，因此该问题并不存在。然而，在单播模式下必须设置重发间隔。间隔值是两次重发之间的最少秒数。
module_dir（路径；可选）
该指令用来标识已找到的指标收集模块的路径。如果省略，则默认为编译时选项值：--with-moduledir。该选项值即为libganglia安装目录下名为Ganglia的子目录。为了在特定gmond中找到该指令的默认值，可以通过下面命令生成一个简单配置文件：
# gmond -t
例如，在32位兼容英特尔的Linux主机上，默认值通常是/usr/lib/ganglia。
section:cluster。每个gmond守护进程会使用在cluster section中定义的属性来报告它所属集群的信息。默认值为字符串“unspecified”。使用默认值系统即可正常工作。该section在配置文件中可能只出现一次，下面为该section的默认配置：
cluster {
name = "unspecified"
owner = "unspecified"
latlong = "unspecified"
url = "unspecified"
}
注意： cluster section中的属性和gmond中以XML格式输出的CLUSTER标识符的属性相对应。
name（文本格式）
指定集群名称。当轮询节点的集群状态的XML集合时，把该名称插入CLUSTER元素内。轮询该节点的gmetad会使用该值来命名存储集群数据的RRD文件。该指令将取代gmetad.conf配置文件中指定的集群名称。
owner（文本格式）
指定集群管理员。
latlong（文本格式）
指定该集群在地区上的GPS坐标的经纬度。
url（文本格式）
指定携带集群特定信息（如集群用途和使用细节）的URL。
注意： cluster section指定的name属性将该主机置于一个集群内。多播地址和UDP端口指定一个主机是否在某个集群内。name属性只是充当轮询时的标识符。
section: host。host section提供运行gmond主机的相关信息。目前只支持地址字符串属性。默认host section为：
host {
location = "unspecified"
}
location（文本格式）
用来标识主机位置，描述的格式一般与站点位置有关， 经常使用rack,U[,blade]的标识方式。
section: UDP channels。UDP发送和接收通道确定gmond节点间的交互方式。集群是由UDP通信通道所定义的，也就是说，集群只不过是共享同样发送或接收通道的一些gmond节点。
gmond集群内每个节点默认通过UDP将自身指标数据多播至其他节点，同时侦听其他节点的类似UDP多播。这种方式很容易设置和维护：集群内每个节点共享多播地址，而且每个新节点可自动被发现。然而，正如在之前章节对单发和单收节点的介绍，有时需要通过单播地址指定某些节点。
出于这种原因， 任意数量的gmond发送和接收通道可以独立配置以满足特定环境需求。每个发送通道都可以定义gmond发布自己指标数据的一种新方式，而且每个接收通道都可以定义gmond接收其他节点指标数据的一种方式，可能是单播，也可能是多播；可能是IPv4，也可能是IPv6。
请注意gmond节点不能配置为向多个Ganglia集群发送指标数据，也不应该尝试从多个集群接收指标数据。
UDP通道是通过udp_(send|receive)_channel section创建的。下面给出默认的UDP发送通道：
udp_send_channel {
#bind_hostname = yes
mcast_join = 239.2.11.71
port = 8649
ttl = 1
}
bind_hostname（布尔类型；可选；多播或单播）
通知gmond使用源地址解析主机名。
mcast_join（IP；可选；仅多播）
当指定该选项时，gmond将创建UDP套接字并加入由IP地址指定的多播组。该选项创建一个多播通道，并与host相互排斥。
mcast_if（文本格式；可选；仅多播）
当指定该选项时，gmond将发送来自指定接口（例如eth0）的数据。
host（文本格式或IP；可选；仅单播）
当指定该选项时，gmond将向已命名主机发送数据。该选项创建一个单播通道，并与mcast_join相互排斥。
port（数字；可选；多播或单播）
该选项指定gmond发送数据的端口号。如果未指定，则默认为端口8649。
ttl（数字；可选；多播或单播）
time-to-live的缩写。该设置在多播环境中尤其重要，因为该值限制了指标数据所允许传播的跃点（hop）数。当该值设置得比实际所需的更大时，指标数据将能够通过WAN连接传输到多个站点，甚至跳出WAN进入全局Internet。
下面是默认的UDP接收通道：
udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
}
mcast_join（IP；可选；仅多播）
当指定该选项时，gmond将侦听指定IP的多播组所发送的多播数据包。如果未指定多播属性，gmond将在指定端口创建单播UDP服务器。
mcast_if（文本格式；可选；仅多播）
当指定该选项时，gmond将侦听指定接口（例如eth0）的数据。
bind（IP；可选；多播或单播）
当指定该选项时，gmond将捆绑到指定的本地地址。
port（数字；可选；多播或单播）
该选项指定gmond接收数据的端口号。如果未指定，则默认使用端口8649。
family（inet4|inet6；可选；多播或单播）
默认IP版本为inet4。如果用户想要将该端口绑定到inet6端口，请指定family属性为inet6。Ganglia不允许IPv6=>IPv4的映射（出于便捷性和安全性考虑）。如果用户想同时对一个特殊端口进行inet4和inet6侦听，请为该端口定义两个分离的接收通道。
acl（ACL定义；可选；多播或单播）
通过指定接入控制列表（Access Control Line，ACL）可以对接收通道进行精细地接入控制。 详见后面对ACL语法的详细解释。
section: TCP Accept Channel。TCP接收通道（TCP Accept Channel）是gmond节点创建向gmetad或其他外部轮询器汇报集群状态的通道。用户可以配置任意多选项。默认TCP接收通道为：
tcp_accept_channel {
port = 8649
}
bind（IP；可选）
当指定该选项时，gmond将捆绑到指定的本地地址。
port（数字）
gmong接收连接的端口号。
family（inet4|inet6；可选；多播或单播）
默认IP版本为inet4。如果用户想要将该端口绑定到inet6端口，请指定family属性为inet6。Ganglia不允许IPv6=>IPv4的映射（出于便捷性和安全性考虑）。如果用户想同时对一个特殊端口进行inet4和inet6侦听，请为该端口定义两个分离的接收通道。
interface（文本格式；可选）
当指定该选项时，gmond将侦听指定接口（例如eth0）数据。
acl（ACL定义；可选；多播或单播）
通过指定接入控制列表（ACL）可以对接收通道进行精细地接入控制。
Access control。udp_recv_channel指令和tcp_accept_channel指令可以包含一个接入控制列表（ACL）。该列表允许用户指定gmond接收或拒绝连接的地址和地址范围。下面是ACL的一个示例：
acl {
default = "deny"
access {
ip = 192.168.0.0
mask = 24
action = "allow"
}
access {
ip = ::ff:1.2.3.0
mask = 120
action = "deny"
}
}
对接入控制概念稍有认识的人都应该能够读懂该语法。default属性为整个ACL定义了默认方式。任意的access块可以指定列表主机或IP地址，以及这些地址的相应allow或deny行为。mask属性以CIDR记法定义了子网掩码，允许用户指定地址范围，而非一个个的具体地址。注意，当ACL冲突时，以第一个匹配项为准。
optional section: sFlow。sFlow是用于监测高速路由网络的工业标准技术。sFlow聚合器最初定位为嵌入式网络硬件，现在服务于通用操作系统和诸如Tomcat、memcached和Apache Web Server等流行应用。gmond可以通过配置来充当网络中sFlow代理的聚合器，收集sFlow代理的数据并实现对gmetad的透明传输。第8章将提供更多关于sFlow互操作性的信息。整个sFlow section是可选的。下面是sFlow的默认配置：
#sflow {
# udp_port = 6343
# accept_vm_metrics = yes
# accept_jvm_metrics = yes
# multiple_jvm_instances = no
# accept_http_metrics = yes
# multiple_http_instances = no
# accept_memcache_metrics = yes
# multiple_memcache_instances = no
#}
udp_port（数字；可选）
gmond接收sFlow数据的端口。
其他剩余配置参数用来处理特定应用的sFlow数据类型，详见第8章。
section: modules。该section包含了加载指标模块的必要参数。指标模块是动态可加载的共享目标文件，用于扩展gmond可收集的指标。第5章将更为详细地介绍如何使用模块来扩展gmond。
每个modules section必须至少包含一个module subsection。module subsection由5个属性组成。默认配置包含了默认安装中所有可用模块（module），如果不添加新模块则无需更改该节。下面给出假设的模块example_module的配置示例：
modules {
module {
name = "example_module"
language = "C/C++"
enabled = yes
path = "modexample.so"
params = "An extra raw parameter"
param RandomMax {
value = 75
}
param ConstantValue {
value = 25
}
}
}
name（文本格式）
如果模块由C/C++开发，则模块名由模块结构所决定。如果模块由诸如Python的解释型语言开发完成，则模块名与源文件名相同。
language（文本格式，可选）
如果未指定开发模块的源代码语言，则默认为C/C++。目前只支持C、C++和Python。
enabled（布尔类型，可选）
通过配置文件设置模块可用或不可用。如果enabled指令不包含在模块配置中，则默认为yes。
注意： 如果一个模块已经被禁用，但是它包含的指标仍存在于当前指标收集组的列表中时，gmond将发出警告信息，但是将忽略该指标继续正常运行。
path（文本格式）
指示gmond预设的加载模块路径（只支持C/C++编译的动态可加载模块）。如果path值不以正斜线开头，则该值将附加到globals section的module_path属性上。
param（文本格式；可选）
用来将字符串参数传送到模块初始化函数（只支持C/C++）。通过包含多个param section，可以将多个参数传送到模块初始化函数。每个param section必须命名，并包含一条value指令。
section: collection_group。collection_group实体指定了gmond包含的指标及gmond收集和广播这些指标的周期。用户可以定义任意多的收集组，每个收集组必须包含至少一种metric section。
这些逻辑指标分组基于相同的收集间隔。这些在gmond.conf中定义的分组并不影响用于Web接口中的分组，也不能用这种方式来指定Web接口的分组名称。节选部分默认配置如下：
collection_group {
collect_once = yes
time_threshold = 1200
metric {
name = "cpu_num"
title = "CPU Count"
}
}
collection_group {
collect_every = 20
time_threshold = 90
/* CPU status */
metric {
name = "cpu_user"
value_threshold = "1.0"
title = "CPU User"
}
metric {
name = "cpu_system"
value_threshold = "1.0"
title = "CPU System"
}
}
collect_once（布尔类型）
有些指标“不变”，也就是说在两次重启时不变化。这些指标包括OS类型和系统CPU数量等，只在初始启动时收集一次，并将其collect_once属性设置为yes。该属性与collect_every相互排斥。
collect_every（秒）
该值指定了收集组的轮询间隔。在上例中，cpu_user和cpu_system指标的收集间隔是20秒。
time_threshold（秒）
gmond发送collection_group所指定的指标数据到所有已配置的udp_send_channels的最大时间。
name（文本格式）
指标收集模块定义的单个指标标准名称。每个加载模块一般定义好几种单独的指标。name可以由name_match参数替换。使用name_match可以通过单个定义来配置多个符合某个正则表达式的指标，如Perl兼容的正则表达式（pcre）的语法： name_match = “multicpu_([a-z]+)([0-9]+)”。
注意： 通过在gmond上运行一个–m转换（switch ）可以获得可用指标名列表。
value_threshold（数字）
每次收集到指标数据时，会将新值与上一次的数值进行比较。当二者差别大于value_threshold时，整个收集组被发送至已定义的udp_send_channels。在不同的指标模块中该值表示不同的指标单位，例如，对于CPU统计，该值代表百分比，网络统计则将该值理解为原始字节数。
注意： 当收集组中的任意一个指标超过value_threshold时，该收集组内的所有指标将发送到UDP接收通道。
title（文本格式）
一种用户化的用于Web前端的指标名称。
http://yaoweibin2008.blog.163.com/blog/static/11031392008763256465/
Ganglia的体系结构
Ganglia的中文意思是神经中枢，相对其网络的大范围监控也算名副其实。Ganglia现在支持多部分操作系统（包括linux、unix、windows），曾经部署于2000个节点的网络。
名词说明
- Metrics- 监控电脑的运行数据，这个词中文比较难翻译，英语中有度量的意思，下文我就不翻译，直接用原词。
- Node - 一台电脑，或许拥有多个CPU，中文称之为节点。
- Cluster - 一组节点，中文称之为簇。通常节点之间拥有达到G比特的高带宽，簇内通过组播协议，每个节点组播自己的数据，所以每个节点拥有整个簇的状态，这种冗余设计可以提高簇的鲁棒性。一般簇内节点为相同的系统和体系结构，由同一个管理员管理。
- Grid - 一组簇，中文可称之为网格。网格的用处是在一个大范围内把各异构的簇通过宽带汇聚在一起。
在文献3中，还有一个概念是Planetary-scale systems，也就是全球性的网络，一般部署于主干网的根节点。并且假定，网内的带宽不充裕，而且昂贵，经常有拥塞的情况出现。
这是加州伯克利的一个GRID网络：http://monitor.millennium.berkeley.edu 你可以通过选择Grid或者Cluster来查看各类数据。
Ganglia的各种组成
功能 名称及配置文件 位置 数据采集器 名叫gmond（Ganglia MONitor Daemon）的服务程序，配置文件是/etc/gmond.conf 位于每个Node上 数据混合收集器 名叫gmetad（Ganglia METAdata Daemon）的服务程序，配置文件是/etc/gmetad.conf。它通过轮询收集gmond的数据,并聚合簇的各类信息，然后保存在本地rrdtool的数据库中 最好每个cluster都有一个gmetad，以便能构建多级网络 Web可视化工具 这是用PHP脚本实现的将数据可视化，并画出表格。可以是任何支持PHP、SSL和XML的web服务器。一般都用Apache2 web服务器 额外的高级工具 gmetric可以用来添加你需要监控的Node额外状态；gstat可以直接获得Ganglia的数据 每台需要这些功能的Node上
ganglia功能示意图
从图中可以看到，簇内通过UDP协议组播压缩的XML（XDR）数据，每个节点共享簇内所有节点的信息，当gmetad轮询簇内某个节点不成功时，也可以轮询其他节点。gmetad通过TCP协议发送簇内数据给上层gmetad节点。
gmond程序由多个线程组成：collect and publish thread线程用于采集节点的metrics并组播出去；listening thread线程用于监听组播端口，并把这些metrics保存于内存中的一个多级hash表；一组XML export threads线程组用于相应TCP请求，把簇内的metrics发送出去。gmond不会保存数据，仅仅是监听保存并相应发送数据。节点间通过heartbeat信号检测对方节点存活与否，如果一段时间内该节点没有广播metrics，我们视其宕机，而且每次启动时，会广播一个gmond启动时间，这时邻居节点收到以后就视其机器重启，会删除该节点已存的所有metrics。
gmetad周期性的想data source发送轮询包，并为每个源分配一个线程。采集的metrics，经由SAX XML进行解析，内置一个gperf的hash表，便于数据的处理，最后将处理好的数据存于RRDTools中。
metrics的组成
Metrics数据由gmond内置的程序或gmetric程序获得，一般以XDR形式压缩保存，保存格式为：（key，value），key为4字节，value为4-8字节。metrics的采集次数、频率和发送时间间隔均在Gmond.conf中定义，gmond维持一个采集表，每个metric都有其属性。
一个多簇异构Ganglia网络的数据流
图中有四种簇：
- 黄色Cluster - 既有本地的Node，也提供前端显示的接口。它提供web服务器查看Ganglia的数据，其中不仅包含本地的Node（可选），也包括蓝色和绿色簇中的数据。
- 淡绿色Cluster - 前端web服务显示，一般没有本地节点。
- 蓝色Cluster - 这个簇中没有本地的数据收集器。所以这些节点将会共享所有数据（由于gmond是用多播来发送数据，所以实现共享比较容易），然后其中一个节点将数据发送给上层的数据收集器。黄色簇的gmetad服务收集并储存，如果没有保存，这些数据将会丢失。
- 深绿色Cluster - 这个簇中拥有本地数据收集器和仓库。绿色节点中也是共享数据，但是由一个簇头节点收集数据，并储存，在被询问时通过TCP发送给上层的黄色簇。
一般性的组网建议：
1、网络由许多深绿色节点和有本地节点的黄色簇组成
2、网络由许多蓝色节点和没有本地节点的黄色簇组成
各类簇的配置
绿色簇的配置
针对gmond.conf 获得gmond默认配置
gmond -t >/etc/gmond.conf
gmond.conf修改如下：
/* This configuration is as close to 2.5.x default behavior as possible
The values closely match ./gmond/metric.h definitions in 2.5.x */
globals {
daemonize = yes
setuid = yes
user = nobody
debug_level = 0
max_udp_msg_len = 1472
mute = no
deaf = no
host_dmax = 0 /*secs */
cleanup_threshold = 300 /*secs */
gexec = no
}
/* If a cluster attribute is specified, then all gmond hosts are wrapped inside
* of a <CLUSTER> tag. If you do not specify a cluster tag, then all <HOSTS> will
* NOT be wrapped inside of a <CLUSTER> tag. */
cluster {
name = "green"
owner = "unspecified"
latlong = "unspecified"
url = "unspecified"
}
/* The host section describes attributes of the host, like the location */
host {
location = "unspecified"
}
/* Feel free to specify as many udp_send_channels as you like. Gmond
used to only support having a single channel. */
udp_send_channel {
mcast_join = green_header
port = 8649
}
/* You can specify as many udp_recv_channels as you like as well. */
udp_recv_channel {
port = 8649
family = inet4
}
...
对于mcast_join这个参数，green_header是簇头节点的主机名，你可以指定ip。
然后重启gmond服务。
簇头节点中/etc/gmetad.conf需要添加下面一行：
data_source "green" localhost
蓝色簇的配置
蓝色簇的配置与绿色簇类似，你只需要把簇的名字和簇头的名字设定好，然后重启所有节点的gmond服务。
黄色簇的配置
大部分配置与绿色簇类似，在/etc/gmetad.conf中需要加入以下几行：
data_source "yellow" localhost data_source "blue" blue_header data_source "green" green_header
这样gmetad就会：
1、联系本地gmond，获取所有黄色节点的状态数据。
2、联系blue_header节点的gmond，获取所有蓝色节点的状态数据。这些数据将会保存在本地的rrdtool数据库中。
3、联系green_header节点，获取在gmetad收集的rrdtools的整合数据。注意这些数据并不会保存在黄色簇中的rrdtools中，所以如果前端web服务器刷新时，会重新向green_header请求更新的的数据。
此外，在/etc/gmetad.conf ，也可以加入Grid的名称：
gridname "Rainbow"
现在Ganglia的网页会显示一个叫Rainbow的网络，其中有三个簇：yellow,green和blue。
一些高级话题
gmetric的使用
你可以添加固件：
gmetric --name firmware --value `lsattr -El sys0 -a modelname -F value` --type "string"
添加磁盘的数目：
gmetric --name number_of_disks --value `lspv | wc -l` --type int32
添加对某项数据的监控（其中name是现实的名字，value是由myget程序获取的，获取的数字类型是由type决定）：
gmetric --name tpm --value `/usr/local/bin/myget` --type double
上面统计都只是一次，如果你需要长久的显示，最好是把上面的语句每60秒执行一次。然后，过几分钟以后，这些数据就会在网页上显示出来了。
对于gmetric的更多了解，你可以看http://ganglia.wiki.sourceforge.net/ganglia_readme 。
这里有一些自定义的gmetric脚本可以参考：http://ganglia.sourceforge.net/gmetric/
使用gstat获取数据
gstat可以通过命令直接显示数据，如：
$ gstat CLUSTER INFORMATION
Name: demo_p505
Hosts: 9 Gexec Hosts: 0 Dead Hosts: 0
Localtime: Wed Jun 21 17:51:05 2006
There are no hosts running gexec at this time
你也可以通过加参数获取更多的信息：
$gstat --all --single_line CLUSTER INFORMATION
Name: demo_p505
Hosts: 9 Gexec Hosts: 0 Dead Hosts: 0
Localtime: Wed Jun 21 17:56:29 2006
CLUSTER HOSTS Hostname
LOAD CPU Gexec CPUs (Procs/Total) [ 1, 5, 15min] [ User, Nice, System, Idle, Wio]
daic4.aixncc.uk.ibm.com 4 ( 0/ 66) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 99.9, 0.0] OFF
daic3.aixncc.uk.ibm.com 4 ( 0/ 82) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.1, 99.8, 0.1] OFF
daic2.aixncc.uk.ibm.com 4 ( 0/ 57) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.1, 99.9, 0.0] OFF
daivios1.aixncc.uk.ibm.com 4 ( 0/ 77) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 99.9, 0.0] OFF
dainim.aixncc.uk.ibm.com 4 ( 0/ 77) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 100.0, 0.0] OFF
dai6.aixncc.uk.ibm.com 4 ( 0/ 86) [ 0.08, 0.03, 0.01] [ 0.1, 0.0, 0.1, 99.5, 0.3] OFF
daic1.aixncc.uk.ibm.com 4 ( 1/ 60) [ 1.00, 1.02, 1.09] [ 0.0, 0.0, 0.0, 100.0, 0.0] OFF
daic5.aixncc.uk.ibm.com 2 ( 0/ 53) [ 0.00, 0.00, 0.00] [ 0.0, 0.0, 0.0, 99.9, 0.0] OFF
daivios.aixncc.uk.ibm.com 4 ( 1/ 74) [ 2.01, 2.09, 1.94] [ 0.1, 0.0, 0.6, 99.2, 0.0] OFF
参考文献
1、http://www-941.ibm.com/collaboration/wiki/display/WikiPtype/ganglia
2、http://ganglia.wiki.sourceforge.net/ganglia_documents
3、The Ganglia Distributed Monitoring System: Design, Implementation, and Experience. Matthew L. Massie, Brent N. Chun, and David E. Culler. Parallel Computing, Vol. 30, Issue 7, July 2004.
4、Wide Area Cluster Monitoring with Ganglia Federico Sacerdoti, Mason Katz, Matt Massie, David E. Culler. IEEE Cluster 2003 Conference, Hong Kong. December 2003.
5、ApacheconUS2007_ganglia_monitoring.ppt Slideshows and Talks on Ganglia,Presentation given at Apache Con 2007 by Brad Nicholes.
浙公网安备 33010602011771号