Linux运维：分布式监控系统Ganglia
Posted 计算机与网络安全
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux运维：分布式监控系统Ganglia相关的知识，希望对你有一定的参考价值。
一次性付费进群，长期免费索取教程，没有付费教程。
ID：Computer-network
Ganglia是一款为HPC（高性能计算）集群而设计的可扩展的分布式监控系统，它可以监视和显示集群中节点的各种状态信息，它由运行在各个节点上的gmond守护来采集CPU、内存、硬盘利用率、I/O负载、网络流量情况等方面的数据，然后汇总到gmetad守护下，使用rrdtool存储数据，最后将历史数据以曲线方式通过页面呈现。
Ganglia的特点如下：
● 良好的扩展性，分层架构设计能够适应大规模集群的需要。
● 负载开销低，支持高并发。
● 广泛支持各种（UNIX等）和CPU架构，支持虚拟机。
1、Ganglia的组成
Ganglia监控系统由三部分组成，分别是gmond、gmetad、webfrontend，作用如下。
gmond：即ganglia monitoring daemon，是一个守护，运行在每一个需要监测的节点上，用于收集本节点的信息并发送到其他节点，同时也接收其他节点发过来的数据，默认的监听端口为8649。
gmetad：即ganglia meta daemon，是一个守护，运行在一个数据汇聚节点上，定期检查每个监测节点的gmond并从那里获取数据，然后将数据指标存储在本地RRD存储引擎中。
webfrontend：是一个基于的图形化监控界面，需要和gmetad安装在同一个节点上，它从gmetad取数据，并且读取RRD，通过rrdtool生成图表，用于前台展示，界面美观、丰富，功能强大。
图1是一个简单的Ganglia监控系统架构图。
图1 Ganglia监控系统架构图
从图1中可以看出，一个Ganglia监控系统是由多个gmond和一个主gmetad组成，所有gmond将收集到的监控数据汇总到gmetad管理端，而gmetad将数据存储到RRD中，最后通过程序在界面进行展示。
这是最简单的Ganglia运行结构图，在复杂的网络环境下，还有更复杂的Gnaglia监控架构。图2是Ganglia的另一种分布式监控架构图。
图2 分布式Ganglia监控架构图
从图2中可以看出，gmond可以等待gmetad将监控数据收集走，也可以将监控数据交给其他gmond，进而让其他gmond将数据最终交付给gmetad，同时，gmetad也可以收集其他gmetad的数据。比如，对于图2中的Cluster1和Cluster2集群，Cluster2就是一个gmetad，它将自身收集到的数据再次传输给Cluster1集群；而Cluster1将所有集群的数据进行汇总，然后通过进行统一展现。
2、Ganglia的工作原理
在介绍Ganglia的工作原理之前，需要介绍一下在Ganglia中经常用到的几个名词，这些是了解Ganglia分布式架构的基础。在Ganglia分布式结构中，经常提到的几个名词有node、cluster和grid，这三部分构成了Ganglia分布式监控系统。
node：Ganglia监控系统中的最小单位，即被监控的单台。
cluster：表示一个集群，由多台组成，是具有相同监控属性的一组的集合。
grid：表示一个网格。grid由多个集群组成，即多个cluster组成一个grid。
从上面的介绍可以看出这三者之间的关系：
● 一个grid对应一个gmetad，在gmetad配置文件中可以指定多个cluster。
● 一个node对应一个gmond，gmond负责采集其所在机器的数据，同时gmond还可以接收来自其他gmond的数据，而gmetad定时去每个node上收集监控数据。
（1）Ganglia数据流向分析
在Ganglia分布式监控系统中，gmond和gmetad之间是如何传输数据的呢？接下来介绍Ganglia是如何实现数据的传输和收集的。图3是Ganglia的数据流向图，也是Ganglia的内部工作原理。
图3 Ganglia数据流向图
下面简述下Ganglia基本运作流程。
1）gmond收集本机的监控数据，发送到其他机器上，并收集其他机器的监控数据，gmond之间通过UDP通信，传递文件格式为XDL。
2）gmond节点间的方式支持单播点对点传送外，还支持多播传送。
3）gmetad周期性地到gmond节点或gmetad节点上获取（poll）数据，gmetad只有通道，因此gmond与gmetad之间的数据都以XML格式传输。
4）gmetad既可以从gmond也可以从其他的gmetad得到XML数据。
5）gmetad将获取的数据更新到rrds中。
6）通过监控界面，从gmetad取数据，并且读取rrds，生成图片显示出来。
（2）Ganglia工作模式
Ganglia的收集数据工作可以在单播（unicast）或多播（multicast）模式下进行，默认为多播模式。
单播：每个被监控节点发送自己收集到的本机数据到指定的一台或几台机器上。单播模式可以跨越不同的网段。如果是多个网段的网络环境，就可以采用单播模式采集数据。
多播：每个被监控节点发送自己收集到的本机数据到同一网段内所有的机器上，同时也接收同一网段内的所有机器发送过来的监控数据。因为数据是以广播包的形式发送，因此这种模式需要所有在同一网段内。但在同一网段内，又可以定义不同的发送通道。
3、Ganglia的安装
在介绍Ganglia的安装之前，首先说明一下安装环境，这里采用CentOS 5.8 x86_64的发行版本，其他版本的安装过程基本相同。
Ganglia的安装很简单，可以通过源码和yum源两种方式进行安装。yum源方式安装方便，可以自动安装依赖关系，但是版本往往不是最新的，而通过源码方式，可以安装最新版的Ganglia。下面具体介绍一下这两种安装方式。
（1）yum源安装方式
[root@node1 ~]# wget http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
[root@node1 ~]# rpm -ivh epel-release-5-4.noarch.rpm
完成yum源安装，就可以直接通过yum源方式安装Ganglia了。
Ganglia的安装分为两个部分，分别是gmetad和gmond，gmetad安装在监控管理端，gmond安装在需要监控的客户端，对应的yum包名称分别为ganglia-gmetad和ganglia-gmond。
下面介绍通过yum源方式安装Ganglia的过程。
以下操作是在监控管理端上进行的，首先通过yum命令查看下可用的Ganglia安装信息：
[root@monitor ~]#yum list ganglia * 可安装的软件包
ganglia.x86_64 3.7.2-2.el7 epel
ganglia-devel.x86_64 3.7.2-2.el7 epel
ganglia-gmetad.x86_64 3.7.2-2.el7 epel
ganglia-gmond.x86_64 3.7.2-2.el7 epel
ganglia-gmond.x86_64 3.7.2-2.el7 epel
ganglia-gmond-python.x86_64 3.7.2-2.el7 epel
ganglia-web.x86_64 3.7.2-2.el7 epel
从输出可知，通过yum安装的Ganglia版本为ganglia-3.7.2，这个版本并不是最新版本。接着开始安装ganglia-gmetad：
[root@monitor ~]# yum -y install ganglia-gmetad.x86_64
安装gmetad需要rrdtool的支持，而通过yum源方式安装，会自动查找gmetad依赖的安装包，自动完成安装，这也是yum源方式安装的优势。
最后在需要监控的所有客户端上安装gmond服务：
[root@node1 ~]# yum -y install ganglia-gmond.x86_64
这样，Ganglia监控系统就安装完成了。通过yum源方式安装的Ganglia默认配置文件位于/etc/ganglia中。
（2）源码方式
通过源码方式安装Ganglia有一定的复杂性，但是可以使用最新的版本，这也是我们推荐的安装方式。源码方式安装Ganglia也分为监控管理端的安装和客户端的安装，这里我们安装的是ganglia-3.7.2，安装的路径是/opt/app/ganglia。首先在监控管理端通过yum命令安装Ganglia的基础依赖包，操作如下：
[root@monitor ~]# yum install -y expat expat-devel pcre pcre-devel zlib cairo-devel libxml2-devel pango-devel pango libpng-devel libpng freetype freetype-devel libart_lgpl-devel apr-devel rrdtool rrdtool-devel
接着安装ganglia的依赖程序，首选是apr，操作过程如下：
[root@monitor ~]# tar zxvf apr-1.6.3.tar.gz
[root@monitor ~]# cd apr-1.6.3
[root@monitor apr-1.6.3]# ./configure
[root@monitor apr-1.6.3]# make
[root@monitor apr-1.6.3]# make install
接着是confuse的安装，操作过程如下：
[root@monitor ~]# tar zxvf confuse-2.7.tar.gz
[root@monitor ~]# cd confuse-2.7
[root@monitor confuse-2.7]# ./configure CFLAGS=-fPIC --disable-nls
[root@monitor confuse-2.7]# make
[root@monitor confuse-2.7]# make install
最后进入ganglia-gmetad的安装，过程如下：
[root@monitor ~]# tar zxvf ganglia-3.7.2.tar.gz
[root@monitor ~]# cd ganglia-3.7.2
[root@monitor ganglia-3.7.2]# ./configure --prefix=/opt/app/ganglia --with-static-modules --enable-gexec --enable-status --with-gmetad --with-python=/usr --with-libexpat=/usr --with-libconfuse=/usr/local --with-libpcre=/usr/local
[root@monitor ganglia-3.7.2]# make
[root@monitor ganglia-3.7.2]# make install
[root@monitor gmetad]# mkdir -p /opt/app/gangliaar/run
[root@monitor gmetad]# systemctl enable gmetad
至此，ganglia-gmetad安装完成。
下面介绍Ganglia客户端的安装过程，ganglig-gmond的安装与ganglia-gmetad大致相同，对于系统依赖包和基础软件包的安装完全相同，只是ganglig-gmond不需要rrdtool的支持，因此重点讲述ganglig-gmond的编译安装过程。
[root@node1 ~]# tar zxvf ganglia-3.7.2.tar.gz
[root@node1 ~]# cd ganglia-3.7.2
[root@node1 ganglia-3.7.2]# ./configure --prefix=/opt/app/ganglia --enable-gexec
--enable-status --with-python=/usr --with-libapr=/usr/local/apr/bin/apr-1-config
--with-libconfuse=/usr/local --with-libexpat=/usr --with-libpcre=/usr
[root@node1 ganglia-3.7.2]# make
[root@node1 ganglia-3.7.2]# make install
[root@node1 gmond]#cd gmond
[root@node1 gmond]# ./gmond -t > /opt/app/ganglia/etc/gmond.conf #用于生成gmond服务配置文件
[root@node1 gmond]#mkdir -p /opt/app/gangliaar/run
[root@node1 gmond]# systemctl enable gmond
到这里为止，ganglig-gmond安装完成。
4、配置一个Ganglia分布式监控系统
（1）Ganglia配置文件介绍
Ganglia的配置文件主要有两个，分别是监控管理端的gmetad.conf和客户端的gmond.conf文件。根据Ganglia安装方式的不同，配置文件的路径也不相同，通过yum源方式安装的Ganglia，默认的配置文件位于/etc/ganglia下，而通过源码方式安装的Ganglia，配置文件路径位于Ganglia安装路径的etc目录下，例如，前面通过源码方式安装的Ganglia配置文件路径为/opt/app/ganglia/etc。在监控管理端，只需要配置gmetad.conf文件即可，而在客户端也只需要配置gmond.conf文件就行了。
（2）Ganglia监控系统架构图
Ganglia支持多种监控架构，这是由gmetad的特性决定的，gmetad可以周期性地去多个gmond节点收集数据，这就是ganglia的两层架构。同时，gmetad不但可以从gmond收集数据，也可以从其他的gmetad得到数据，这就形成了Gnaglia的三层架构。多种架构方式也体现了Ganglia作为分布式监控系统的灵活性和扩展性。
这里介绍一个简单的Ganglia配置架构，即一个监控管理端和多个客户端的两层架构。我们假定gmond工作在多播模式，并且有一个Cluster1集群，其中有4台要监控的，名从cloud0到cloud3，这4台在同一个网段内。
（3）Ganglia监控管理端配置
监控管理端的配置文件是gmetad.conf，这个配置文件内容比较多，但是需要修改的配置仅有如下几个：
data_source "Cluster1" cloud0 cloud2
gridname "TopGrid"
xml_port 8651
interactive_port 8652
rrd_rootdir "/opt/app/ganglia/rrds"
各参数含义如下。
上面通过data_source参数定义了一个集群Cluster1，对于要监控多个应用系统的情况，还可以对不同用途的进行分组，定义多个集群，分组方式可以通过下面的方法定义：
data_source "my cluster" 10 localhost my.machine.edu:8649 1.2.3.5:8655
data_source "my grid" 50 1.3.4.7:8655 grid.org:8651 grid-backup.org:8651
data_source "another source" 1.3.4.7:8655 1.3.4.8
gridname：此参数是定义一个网格名称。一个网格有多个集群组成，每个集群由“data_source”选项来定义。
xml_port：此参数定义了一个收集数据汇总的交互端口，如果不指定，默认是8651，可以通过telnet这个端口得到监控管理端收集到的客户端的所有数据。
interactive_port：此参数定义了端获取数据的端口，这个端口在配置Ganglia的监控界面时需要指定。
rrd_rootdir：此参数定义了rrd的存放路径，gmetad在收集到监控数据后会将其更新到该目录下对应的rrd中。
到这里为止，在Ganglia监控管理端的配置完成了。
（4）Ganglia的客户端配置
Ganglia监控的客户端gmond安装完成后，配置文件位于Ganglia安装路径的etc目录下，名称为gmond.conf，这个配置文件稍微复杂，如下所示：
globals {
daemonize = yes #是否后台运行，这里表示以后台的方式运行
setuid = yes #是否设置运行用户，在Windows中需要设置为false
user = nobody #设置运行的用户名称，必须是操作系统已经存在的用户，默认是nobody
debug_level = 0 #调试级别，默认是0，表示不输出任何日志，数字越大表示输出的日志越多
max_udp_msg_len = 1472
mute = no #是否发送监控数据到其他节点，设置为no表示本节点将不再广播任何自己收集到的数据到网络上
deaf = no #是否接受其他节点发送过来的监控数据，设置为no表示本节点将不再接收任何其他节点广播的数据包
allow_extra_data = yes#是否发送扩展数据
host_dmax = 0 /*secs */#是否删除一个节点，0代表永远不删除，0之外的整数代表节点的不响应时间，超过这个时间后，Ganglia就会刷新集群节点信息进而删除此节点
cleanup_threshold = 300 /*secs */ #gmond清理过期数据的时间
gexec = no #是否使用gexec来告知主机是否可用，这里不启用
send_metadata_interval = 60 #主要用在在单播环境中，如果设置为0，那么如果某个节点的gmond重启后，gmond汇聚节点将不再接受这个节点的数据，将此值设置大于0，可以保证在gmond节点关闭或重启后，在设定的时间内，gmond汇聚节点可以重新接收此节点发送过来的信息。单位秒
}
cluster {
name = "Cluster1" #集群的名称，是区分此节点属于某个集群的标志，必须和监控服务端data_source中的某一项名称匹配
owner = "junfeng" #节点的拥有者，也就是节点的管理员
latlong = "unspecified" #节点的坐标，经度、纬度等，一般无需指定
}
host {
location = "unspecified" #节点的物理位置，一般无需指定
}
udp_send_channel { #udp包的发送通道
port = 8649 #监听端口
ttl = 1
}
udp_recv_channel { #接收udp包配置
port = 8649 #监听端口
}
tcp_accept_channel {
port = 8649 #通过tcp协议监听的端口，在远端可以通过连接到8649端口得到监控数据
}
在一个集群内，所有客户端的配置是一样的。完成一个客户端配置后，将配置文件复制到此集群内的所有客户端上即可完成客户端的配置。
（5）Ganglia的Web端配置
Ganglia的监控界面是基于的，因此需要安装环境。环境的安装这里不做介绍，可以下载ganglia-web的最新版本，然后将ganglia-web程序放到Apche 的根目录即可，这里我们推荐下载的版本是ganglia-web-3.5.7。
配置Ganglia的界面比较简单，只需要修改几个文件即可。首先是conf_default.php，可以将conf_default.php重命名为conf.php，也可以保持不变，Ganglia的默认先找conf.php，找不到会继续找conf_default.php，需要修改的内容如下：
这里需要说明的是：“$conf['dwoo_compiled_dir']”和“$conf['dwoo_cache_dir']”指定的路径在默认情况下可能不存在，因此需要手动建立compiled和cache目录，并授予下“777”的权限。另外，rrd的存储目录/opt/app/ganglia/rrds一定要保证rrdtool可写，因此需要执行授权命令：
chown –R nobody:nobody /opt/app/ganglia/rrds
这样rrdtool才能正常读取rrd，进而将数据通过界面展示出来。其实ganglia-web的配置还是比较简单的，一旦配置出错会给出提示，根据错误提示进行问题排查，一般都能找到解决方法。
5、Ganglia监控系统的管理和维护
在Ganglia的所有配置完成之后，就可以启动Ganglia监控服务了，首先在被监控节点依次启动gmond服务，操作如下：
[root@node1 ~]# systemctl start gmond
然后通过查看系统的/var/log/messages日志信息，判断gmond是否成功启动，如果出现问题，根据日志的提示进行解决。
接着就可以启动监控管理节点的gmetad服务了，操作如下：
[root@monitor ~]# systemctl start gmetad
同样，也可以跟踪一下系统的/var/log/messages日志信息，看启动过程是否出现异常。
最后，将Apache/的服务启动，就可以查看Ganglia收集到的所有节点的监控数据信息。图4是Ganglia 某一时刻的运行状态图。
图4 Ganglia Web某一时刻的运行状态图
6、Ganglia监控扩展实现机制
在默认情况下，Ganglia通过gmond守护收集CPU、内存、磁盘、IO、、网络6大方面的数据，然后汇总到gmetad守护下，使用rrdtools存储数据，最后将历史数据以曲线方式通过页面呈现。但是很多时候这些基础数据还不足以满足我们的监控需要，我们还要根据应用的不同，扩展Ganglia的监控范围。下面我们就介绍通过开发Ganglia插件扩展Ganglia监控功能的实现方法。
（1）扩展Ganglia监控功能的方法
默认安装完成的Ganglia仅向我们提供基础的系统监控信息，通过Ganglia插件可以实现两种扩展Ganglia监控功能的方法。
1）添加带内（in-band）插件，主要是通过gmetric命令来实现。
这是通常使用的一种方法，主要是通过crontab方法并调用Ganglia的gmetric命令来向gmond输入数据，进而实现统一监控。这种方法简单，对于少量的监控可以采用，但是对于大规模自定义监控时，监控数据难以统一管理。
2）添加一些其他来源的带外（out-of-band）插件，主要是通过或者接口来实现。
在Ganglia3.1.x版本以后，增加了或接口，通过这个接口可以自定义数据收集模块，并且可以将这些模块直接插入gmond中以监控用户自定义的应用。
（2）通过gmetric接口扩展Ganglia监控
gmetric是Ganglia的一个命令行工具，它可以将数据直接发送到负责收集数据的gmond节点，或者广播给所有gmond节点。由此可见，采集数据的不一定全部都是gmond这个服务，也可以直接通过应用程序调用Ganglia提供的gmetric工具将数据直接写入gmond中，这就很容易地实现了ganglia监控的扩展。因此，我们可以利用、Perl、等语言工具，通过调用gmetric将我们想要监控的数据直接写入gmond中，简单而快速地实现了Ganglia的监控扩展。
在Ganglia安装完成后，会在bin目录下生成gmetric命令。下面通过一个实例介绍一下gmetric的使用方法：
[root@cloud1 ~]# /opt/app/ganglia/bin/gmetric
>-n disk_used -v 40 -t int32 -u '% test'-d 50 -S '8.8.8.8:cloud1'
其中：
-n，表示要监控的指标名。
-v，表示写入的监控指标值。
-t，表示写入监控数据的类型。
-u，表示监控数据的单位。
-d，表示监控指标的存活时间。
-c，用于指定Ganglia配置文件的位置。
通过不断地执行gmetric命令写入数据，Ganglia 的监控报表已经形成，如图5所示。
图5 通过gmetric生成的监控报表
从图5中可以看到刚才执行命令时设置的几个属性值在报表中都呈现出来了，例如disk_used、“%test”、cloud1等。同时，通过gmetric写入的监控数值，在报表中也很清楚地展示出来。
在上面的实例中，我们通过执行命令的方式不断写入数据，进而生成监控报表。事实上，所有的监控数据都是自动收集的，因此，要实现数据的自动收集，可以将上面的命令写成一个脚本，然后将脚本文件放入cron运行。
假设生成的脚本文件是/opt/ganglia/bin/ganglia.sh，运行“crontab -e”命令，将此脚本每隔10分钟运行一次：
*/10 **** /opt/ganglia/bin/ganglia.sh
最后，打开Ganglia 进行浏览，即可看到通过gmetric命令收集到的数据报表。
（3）通过Python插件扩展Ganglia监控
要通过插件扩展Ganglia监控，必须满足如下条件：
● Ganglia 3.1.x以后版本
● 2.6.6或更高版本
● 开发头文件（通常在python-devel这个软件包中）
在安装Ganglia客户端（gmond）的时候，需要加上“--with-python”参数，这样在安装完成后，会生成modpython.so文件，这个文件是Ganglia调用的动态链接库，要通过接口开发Ganglia插件，必须编译安装此模块。
这里假定Ganglia的安装版本是ganglia3.4.0，安装目录是/opt/app/ganglia，要编写一个基于的Ganglia插件，需要进行如下操作。
1）修改modpython.conf文件（Ganglia客户端）
在Ganglia安装完成后，modpython.conf文件位于/opt/app/ganglia/etc/conf.d目录下，此文件内容如下：
modules {
module {
name = "python_module" #python主模块名称
path = "modpython.so" #ganglia调用python的动态链接库。这个文件应该在ganglia的安装目录的lib64/ganglia下面。
params = "/etc/ganglia/python_modules" #指定我们编写的python脚本放置路径
}
}
include ("/etc/ganglia/conf.d/*.pyconf") #python脚本配置文件存放路径
2）重启gmond服务
在客户端的所有配置修改完成后，重启gmod服务即可完成接口环境的搭建。
（4）实战：利用Python接口监控nginx运行状态
搭建完接口环境，这只是实现Ganglia监控扩展的第一步，接下来还要编写基于的Ganglia监控插件。不过幸运的是，网上有很多已经编写好的各种应用服务的监控插件，我们只需要拿来使用即可。可以从https://github.com/ganglia/gmond_python_modules下载需要的各种Ganglia扩展监控插件，这里要下载的是nginx_status这个插件。下载完成的nginx_status插件的目录结构如下：
[root@cloud1nginx_status]# ls conf.d graph.d python_modules README.mkdn
其中，conf.d目录下存放的是配置文件nginx_status.pyconf，python_modules目录下放的是插件的主程序nginx_status.py，graph.d目录下放的是用于绘图的程序。这几个文件接下来都会用到。
对Nginx的监控，需要借助with-http_stub_status_module模块，此模块默认不开启，所以需要指定开启，用于编译Nginx。
1）配置Nginx，开启状态监控
在Nginx配置文件nginx.conf中添加如下配置：
接着，重启Nginx，通过http://IP:8000/nginx_status即可看到状态监控结果。
2）配置Ganglia客户端，收集nginx_status数据
根据前面对modpython.conf文件的配置，我们将nginx_status.pyconf文件放到/opt/app/ganglia/etc/conf.d目录下，将nginx_status.py文件放到/opt/app/ganglia/lib64/ganglia目录下。
nginx_status.py文件无需改动，nginx_status.pyconf文件需要做一些修改，修改后的文件内容如下：
[root@cloud1 conf.d]# more nginx_status.pyconf
modules {
module {
name = 'nginx_status' #模块名，该文件存放于/opt/app/ganglia/lib64/ganglia下面
language = 'python' #声明使用Python语言
....# 其他部分不需要修改
3）绘图展示的PHP文件
在完成数据收集后，还需要将数据以图表的形式展示在Ganglia 界面中，所以还需要前台展示文件，将graph.d目录下的两个文件nginx_accepts_ratio_report.php和nginx_scoreboard_report.php放到Ganglia 的绘图模板目录即可。根据上面的设定，Ganglia 的安装目录是/var/www/html/ganglia，因此，将上面这两个文件放到/var/www/html/ganglia/graph.d目录下即可。
4）nginx_status.py输出效果图
完成前面所有步骤后，重启Ganglia客户端gmond服务，在客户端通过“gmond -m”命令可以查看支持的模板，最后就可以在Ganglia 界面查看Nginx的运行状态，如图6所示。
图6 通过Python插件实现Ganglia监控Nginx
7、Ganglia在实际应用中要考虑的问题
（1）网络IO可能存在瓶颈
在Ganglia分布式监控系统中，运行在被监控节点上的gmond消耗的网络资源是非常小的，通常在1~2MB之间，而gmond将收集到的数据仅保存在内存中，因此gmond消耗的网络资源基本可以忽略不计。但有一种情况，就是在采用单播模式下，所有gmond都会向一个gmond中央节点发送数据，而这个gmond中央节点可能存在网络开销，如果单播传输的节点过多，那么在中央节点上就会存在网络IO瓶颈。
另外，gmetad管理节点会收集所有gmond节点上的监控数据，同时Ganglia-也运行在gmetad所在的节点上，因此，gmetad所在节点的网络IO也会很大，可能存在网络IO瓶颈。
（2）CPU可能存在瓶颈
对于gmetad管理节点，它将收集所有gmond节点收集到的UDP数据包，如果一个节点每秒发送10个数据包，300个节点每秒将会发送3000个，假如每个数据包300B，那么每秒就有近1MB的数据，这么多数据包需要的CPU处理能力也会增加。
gmetad在默认情况下每15s到gmond取一次数据，同时gmetad请求完数据后还要汇总到XML文件，还需要对XML文件进行解析，如果监控的节点较多，比如1000个节点，那么收集到的XML文件可能有10~20MB左右。如果按照默认情况每隔15s去解析一个20MB左右的XML文件，那么CPU将面临很大压力，而gmetad还要将数据写入rrd，同时还要处理来自客户端的解析请求进而读rrd，这些都会加重CPU的负载，因此在监控的节点比较多时，gmetad节点应该选取性能比较好的，特别是CPU性能。
（3）gmetad写入rrd数据库可能存在瓶颈
gmetad进程在收集完成客户端的监控数据后，会通过rrdtool工具将数据写入到rrd的存储目录。由于rrd拥有独特的存储方式，它将每个metric作为一个文件来存储，并且如果配置了数据采集的频率，gmetad还会为每个采集频率保存一个单独的文件，这就意味着，gmetad将metric值保存到rrd的操作将是针对大量小文件的IO操作。假设集群有500个节点，每个节点有50个metric，那么gmetad将会存储25000个metric，如果这些metric都是每秒更新一次，这将意味着每秒有25000个随机写入操作，而对于这种写入操作，一般的硬盘是无法支撑的。
ID：Computer-network
【推荐书籍】
以上是关于Linux运维：分布式监控系统Ganglia的主要内容，如果未能解决你的问题，请参考以下文章