Ganglia-3.1.1.tar 파일입니다.




The latest version of all ganglia software can always be downloaded from

Ganglia runs on Linux (i386, ia64, sparc, alpha, powerpc, m68k, mips, arm, hppa, s390), FreeBSD, NetBSD, OpenBSD, DragonflyBSD, MacOS X, Solaris, AIX, IRIX, Tru64, HPUX and Windows NT/XP/2000/2003/2008 making it as portable as it is scalable.

Monitoring Core Installation

If you use the Linux RPMs provided on the ganglia web site, you can skip to the end of this section.

Ganglia uses the GNU autoconf so compilation and installation of the monitoring core is basically

  % ./configure
  % make
  % make install

but there are some issues that you need to take a look at first.

Kernel multicast support
If you use the ganglia multicast support, you must have a kernel that supports multicast. The vast majority of machines have multicast support by default. If you have problems with ganglia this is a core issue.

Gmetad is not installed by default
Since gmetad relies on the Round-Robin Database Tool ( see ) it will not be compiled unless you explicit request it by using a --with-gmetad flag.
  % ./configure --with-gmetad

The configure script will fail if it cannot find the rrdtool library and header files. By default, it expects to find them at /usr/include/rrd.h and /usr/lib/ If you installed them in different locations then you need to instruct configure where to find them using:

  % ./configure --with-librrd=/rrd/path --with-gmetad

Of course, you need to substitute /rrd/path with the real location of the rrd tool directory where the header file can be located inside an include subdirectory and the library can be located inside a lib subdirectory. As an alternative you could set ``-L'' in LDFLAGS, and ``-I'' in CFLAGS and CPPFLAGS for the library path and the header path respectively.

AIX should not be compiled with shared libraries
You must add the --disable-shared configure flags if you are running on AIX. For more details refer to the README.AIX file
  % ./configure --disable-shared

Solaris dependencies could be problematic
Not really a Solaris specific problem, but since Solaris has several different package repositories, all of them unofficial, it is difficult to be sure that all possible permutations have been confirmed to work reliably.

Be sure to have all dependencies covered, as explained in the INSTALL file and to use GNU make and a gcc compiler that builds 32bit binaries with all other libraries matching that ISA.

When in doubt, build the problematic dependency from source and remember to distribute it together with your ganglia build as everything is dynamically linked by default.

Be particularly careful with libConfuse, especially if using the old 2.5 version. LibConfuse 2.5 is known to be incorrectly packaged and to compile by default as a static library which will fail to link with ganglia.

Propietary *NIX systems might not work at all
The good news is that the libmetrics code that used to work before 3.1 is still most likely working fine and so there is nothing fundamentally broken about it.

But the bad news is that in order to add the dynamic metric functionality, the build system and the way gmond used to locate its metrics had to be changed significantly. Therefore getting gmond to build and work again required fixes to be implemented for all platforms.

Since none of the developers had access to HPUX, IRIX, Tru64 (OSF/1), or Darwin (MacOS X) those platforms might not be able to build or run a 3.1 gmond yet. If you have access to any of these platforms and want to run ganglia 3.1, feel free to drop by the ganglia-developers list with suggestions, or even better patches.

GEXEC confusion
GEXEC is a scalable cluster remote execution system which provides fast, RSA authenticated remote execution of parallel and distributed jobs. It provides transparent forwarding of stdin, stdout, stderr, and signals to and from remote processes, provides local environment propagation, and is designed to be robust and to scale to systems over 1000 nodes. Internally, GEXEC operates by building an n-ary tree of TCP sockets and threads between gexec daemons and propagating control information up and down the tree. By using hierarchical control, GEXEC distributes both the work and resource usage associated with massive amounts of parallelism across multiple nodes, thereby eliminating problems associated with single node resource limits (e.g., limits on the number of file descriptors on front-end nodes). (from )

gexec is a great cluster execution tool but integrating it with ganglia is a bit clumsy. GEXEC can run standalone without access to a ganglia gmond. In standalone mode gexec will use the hosts listed in your GEXEC_SVRS variable to run on. For example, say I want to run hostname on three machines in my cluster: host1, host2 and host3. I use the following command line.

  % GEXEC_SVRS="host1 host2 host3" gexec -n 3 hostname

and gexec would build an n-ary tree (binary tree by default) of TCP sockets to those machines and run the command hostname

As an added feature, you can have gexec pull a host list from a locally running gmond and use that as the host list instead of GEXEC_SVRS. The list is load balanced and gexec will start the job on the n least-loaded machines.

For example..

  % gexec -n 5 hostname

will run the command hostname on the five least-loaded machines in a cluster.

To turn on the gexec feature in ganglia you must configure ganglia with the --enable-gexec flag

  % ./configure --enable-gexec

Enabling gexec means that by default any host running gmond will send a special message announcing that gexec is installed on it and open for requests.

Now the question is, what if I don't want gexec to run on every host in my cluster? For example, you may not want to have gexec run jobs on your cluster frontend nodes.

You simply add the following line to your gmond configuration file (/etc/ganglia/gmond.conf by default)

  no_gexec on

Simple huh? I know the configuration file option, no_gexec, seems crazy (and it is). Why have an option that says ``yes to no gexec''? The early versions of gmond didn't use a configuration file but instead commandline options. One of the commandline options was simply --no-gexec and the default was to announce gexec as on.

Once you have successfully run

  % ./configure <options>
  % make
  % make install

you should find the following files installed in /usr (by default).


If you installed ganglia using RPMs then these files will be installed when you install the RPM. The RPM is installed simply by running

  % rpm -Uvh ganglia-gmond-3.1.1.i386.rpm
  % rpm -Uvh ganglia-gmetad-3.1.1.i386.rpm

Once you have the necessary binaries installed, you can test your installation by running

   % ./gmond

This will start the ganglia monitoring daemon. You should then be able to run

   % telnet localhost 8649

And get an XML description of the state of your machine (and any other hosts running gmond at the time).

If you are installing by source on Linux, scripts are provided to start gmetad and gmond at system startup. They are easy to install from the source root.

   % cp ./gmond/gmond.init /etc/rc.d/init.d/gmond
   % chkconfig --add gmond
   % chkconfig --list gmond
     gmond              0:off   1:off   2:on    3:on    4:on    5:on    6:off
   % /etc/rc.d/init.d/gmond start
     Starting GANGLIA gmond:                                    [  OK  ]

Repeat this step with gmetad.

PHP Web Frontend Installation

  1. The ./web directory of the ganglia distribution contains all the necessary PHP files for running your web frontend. Copy those files to /var/www/html, however look for the variable DocumentRoot in your Apache configuration files to be sure. All the PHP script files use relative URLs in their links, so you may place the ganglia/ directory anywhere convenient.

  2. Ensure your webserver understands how to process PHP script files. Currently, the web frontend contains certain php language that requires PHP version 4 or greater. Processing PHP script files usually requires a webserver module, such as the mod_php for the popular Apache webserver. In RedHat Linux, the RPM package that provides this module is called simply ``php''.

    For Apache, mod_php module must be enabled. The following lines should appear somewhere in Apache's *conf files. This example applies to RedHat and Mandrake Linux. The actual filenames may vary on your system. If you installed the php module using an RPM package, this work will have been done automatically.

      <IfDefine HAVE_PHP4>
      LoadModule php4_module    extramodules/
      AddModule mod_php4.c
      AddType  application/x-httpd-php         .php .php4 .php3 .phtml
      AddType  application/x-httpd-php-source  .phps

  3. The webfrontend requires the existance of the gmetad package on the webserver. Follow the installation instructions on the gmetad page. Specifically, the webfrontend requires the rrdtool and the rrds/ directory from gmetad. If you are a power user, you may use NFS to simulate the local existance of the rrds.

  4. Test your installation. Visit the URL:

    With a web-browser, where localhost is the address of your webserver.

  5. Installation of the web frontend is simplified on Linux by using rpm.

      % rpm -Uvh ganglia-web-3.1.1-1.i386.rpm
      Preparing...                ########################################### [100%]
         1:ganglia-web            ########################################### [100%]


    Gmond Configuration

    The configuration file format has changed between gmond version 2.5.x and version 3.x. The change was necessary in order to allow more complex configuration options.

    Gmond has a default configuration it will use if it does not find the default configuration file /etc/ganglia/gmond.conf. To see the default configuration simply run the command:

      % gmond --default_config

    and gmond will output its default configuration to stdout. This default configuration can serve as a good starting place for building a more custom configuration.

      % gmond --default_config > gmond.conf

    would create a file gmond.conf which you can then edit to taste and copy to /etc/ganglia/gmond.conf or elsewhere.

    To start gmond with a configuration file other then /etc/ganglia/gmond.conf, simply specify the configuration file location by running

      % gmond --config /my/ganglia/configs/custom.conf

    If you want to convert a 2.5.x configuration file to 3.x file format, run the following command

      % gmond --convert ./old_25_config.conf

    and gmond with output the equivalent 3.x configuration file to stdout. You can then redirect that output to a new configuration file which can serve as a starting point for your configuration.

      % gmond --convert ./old_25_config.conf > ./new_26_config.conf

    For details about gmond configuration options, simply run

      % man gmond.conf

    for a complete listing of options with detailed explanations.

    Gmetad Configuration

    The behavior of the Ganglia Meta Daemon is completely controlled by a single configuration file which is by default /etc/ganglia/gmetad.conf. For gmetad to do anything useful you much specify at least one data_source in the configuration. The format of the data_source line is as follows

      data_source "Cluster A"
      data_source "Cluster B"

    In this example, there are two unique data sources: ``Cluster A'' and ``Cluster B''. The Cluster A data source has three redundant sources. If gmetad cannot pull the data from the first source, it will continue trying the other sources in order.

    If you do not specify a port number, gmetad will assume the default ganglia port which is 8649 (U*N*I*X on a phone key pad)

    For a sample gmetad configuration file with comments, look at the gmetad.conf file provided as part of the distribution package in the gmetad directory

    gmetad has a --conf option to allow you to specify alternate configuration files

      % ./gmetad -conf=/tmp/my_custom_config.conf

    PHP Web Frontend Configuration

    Most configuration parameters reside in the ganglia/conf.php file. Here you may alter the template, gmetad location, RRDtool location, and set the default time range and metrics for graphs.

    The static portions of the Ganglia website are themable. This means you can alter elements such as section lables, some links, and images to suit your individual tastes and environment. The template_name variable names a directory containing the current theme. Ganglia uses TemplatePower to implement themes. A user-defined skin must conform to the template interface as defined by the default theme. Essentially, the variable names and START/END blocks in a custom theme must remain the same as the default, but all other HTML elements may be changed.

    Other configuration variables in conf.php specify the location of gmetad's files, and where to find the rrdtool program. These locations need only be changed if you do not run gmetad on the webserver. Otherwise the default locations should work fine. The default_range variable specifies what range of time to show on the graphs by default, with possible values of hour, day, week, month, year. The default_metric parameter specifies which metric to show on the cluster view page by default.