Back to Documentation
| English Version
Guías para la instalación de Ganglia (Linux)
Versión 1.0 - 06/09/2006
GuiaInstalacionGanglia.doc (228 KB)
1 Introducción
1.1 Propósito y alcance de este documento
Este documento describe los pasos a seguir para la instalación de Ganglia y su front end PHP. Ganglia consiste en un sistema de monitoreo para clusters y grids, que permite recolectar métricas tales como ocupación de los procesadores, uso de la memoria y espacio libre en disco.
Este documento no realiza presunciones respecto de software ya instalado, excepto por aquellas herramientas indicadas expresamente en la sección de prerrequisitos.
1.2 Definiciones de términos y abreviaturas
Los siguientes términos y abreviaturas son utilizados en el presente documento:
Término o Abreviatura |
Definición |
PURSe |
Portal-Based User Registration Service |
PKI |
Public Key Infrastructure |
GT |
Globus Toolkit, cuando la sigla sea seguida por un número, éste se referirá a la versión |
GRAM |
Globus Resource Allocation and Management |
GSI |
Grid Security Infrastructure |
MDS |
Monitoring and Discovery Service |
GRIS |
Grid Resource Information Service |
GIIS |
Grid Index Information Service |
RFT |
Reliable File Transfer |
RLS |
Replica Location Service |
OGSA |
Open Grid Services Architecture |
SOAP |
Simple Object Access Protocol |
XML |
Extensible Markup Language |
WS |
Web Service |
WSRF |
Web Services Resource Framework |
JDBC |
Java Database Connectivity |
CA |
Certificate Authority (entidad certificadora) |
PEM |
Privacy-Enhanced Mail (referido a encriptación) |
W3C |
World Wide Web Consortium |
DN |
Distinguished Name |
CN |
Common Name |
OU |
Organizational Unit |
GGF |
Global Grid Forum |
GUI |
Graphical User Interface |
1.3 Referencias
A continuación se detallan los documentos relacionados:
|
Documento |
Descripción |
2 Conceptos generales
2.1 Ganglia Monitoring Daemon
El Ganglia Monitoring Daemon, o gmond , es un programa que corre en cada uno de los nodos que se desean monitorear. Gmond tiene cuatro responsabilidades: monitorea los cambios en el estado del host, anuncia los cambios relevantes, escucha el estado de todos los otros nodos, y responde a pedidos de descripciones XML del estado del cluster. Cada gmond daemon contiene el estado completo del cluster.
2.2 Ganglia Meta Daemon
El Ganglia Meta Daemon, o gmetad , es el programa que permite federar (agregar) múltiples clusters, utilizando un árbol de conexiones punto a punto a los nodos representativos de cada cluster. Gmetad reside en cada uno de esos nodos representativos, obteniendo datos periódicamente de fuentes de datos que pueden a su vez ser otros gmetad daemons (que representan conjuntos de clusters), o bien gmond daemons (que representan clusters específicos).
2.3 Ganglia PHP Web Frontend
Ganglia provee un frontend web que permite visualizar la información recolectada mediante páginas generadas dinámicamente. Ganglia presenta la información de manera amigable y útil para los administradores del sistema y los usuarios, y mantiene un historial de datos recolectados. Además, complementa las métricas con gráficos de las mismas, generados por gmetad. Este frontend está programado en PHP.
3 Instalación de Ganglia
3.1 Prerrequisitos
- make
- GNU tar
- autoconf
- Web server con capacidad para interpretar PHP
3.2 Instalación
3.2.1 Instalación de Ganglia sin gmetad
Para instalar Ganglia, obtener en primer lugar el archivo tar correspondiente al core del monitor Ganglia de http://ganglia.sourceforge.net/downloads.php .
Descomprimir dicho archivo en un directorio en el host y ejecutar configure, make y make install como se indica.
Como un usuario con permisos sobre el directorio en que se descomprimirá el tar:
$ tar -zxvf ganglia-3.0.3.tar.gz
ganglia-3.0.3 $ ./configure
ganglia-3.0.3 $ make
Como root:
ganglia-3.0.3 # make install
Los pasos realizados instalan los siguientes archivos:
/usr/bin/gstat
/usr/bin/gmetric
/usr/sbin/gmond
/usr/lib/libiganglia.a
/usr/lib/libiganglia.la
/usr/lib/libiganglia.so
3.2.2 Configuración de gmond
Gmond utiliza un archivo de configuración ubicado en /etc/gmond.conf. Para generar dicho archivo por primera vez, ejecutar:
Como root:
# gmond --default_config > /etc/gmond.conf
El archivo gmond.conf contiene parámetros de configuración que, entre otras cosas, permiten especificar el nombre y otras propiedades del cluster. A continuación se presenta el archivo luego de las modificaciones (puede utilizarse directamente este contenido, sin ejecutar el comando indicado arriba).
/* 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. */
/* El tag <CLUSTER> es necesario para que gmetad pueda interpretar el XML */
cluster {
name = "Hexacta Nodes"
owner = "Hexacta"
latlong = "S34.5 W58.4"
url = "http://node2.hexacta.com:8080/gridsphere"
}
/* The host section describes attributes of the host, like the location */
host {
location = "Oficinas Hexacta"
}
/* 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 = 239.2.11.71
port = 8649
}
/* You can specify as many udp_recv_channels as you like as well. */
udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
}
/* You can specify as many tcp_accept_channels as you like to share
an xml description of the state of the cluster */
tcp_accept_channel {
port = 8649
}
/* The old internal 2.5.x metric array has been replaced by the following
collection_group directives. What follows is the default behavior for
collecting and sending metrics that is as close to 2.5.x behavior as
possible. */
/* This collection group will cause a heartbeat (or beacon) to be sent every
20 seconds. In the heartbeat is the GMOND_STARTED data which expresses
the age of the running gmond. */
collection_group {
collect_once = yes
time_threshold = 20
metric {
name = "heartbeat"
}
}
/* This collection group will send general info about this host every 1200 secs.
This information doesn't change between reboots and is only collected once. */
collection_group {
collect_once = yes
time_threshold = 1200
metric {
name = "cpu_num"
}
metric {
name = "cpu_speed"
}
metric {
name = "mem_total"
}
/* Should this be here? Swap can be added/removed between reboots. */
metric {
name = "swap_total"
}
metric {
name = "boottime"
}
metric {
name = "machine_type"
}
metric {
name = "os_name"
}
metric {
name = "os_release"
}
metric {
name = "location"
}
}
/* This collection group will send the status of gexecd for this host every 300 secs
/
/* Unlike 2.5.x the default behavior is to report gexecd OFF. */
collection_group {
collect_once = yes
time_threshold = 300
metric {
name = "gexec"
}
}
/* This collection group will collect the CPU status info every 20 secs.
The time threshold is set to 90 seconds. In honesty, this time_threshold could be
set significantly higher to reduce unneccessary network chatter. */
collection_group {
collect_every = 20
time_threshold = 90
/* CPU status */
metric {
name = "cpu_user"
value_threshold = "1.0"
}
metric {
name = "cpu_system"
value_threshold = "1.0"
}
metric {
name = "cpu_idle"
value_threshold = "5.0"
}
metric {
name = "cpu_nice"
value_threshold = "1.0"
}
metric {
name = "cpu_aidle"
value_threshold = "5.0"
}
metric {
name = "cpu_wio"
value_threshold = "1.0"
}
/* The next two metrics are optional if you want more detail...
... since they are accounted for in cpu_system.
metric {
name = "cpu_intr"
value_threshold = "1.0"
}
metric {
name = "cpu_sintr"
value_threshold = "1.0"
}
*/
}
collection_group {
collect_every = 20
time_threshold = 90
/* Load Averages */
metric {
name = "load_one"
value_threshold = "1.0"
}
metric {
name = "load_five"
value_threshold = "1.0"
}
metric {
name = "load_fifteen"
value_threshold = "1.0"
}
}
/* This group collects the number of running and total processes */
collection_group {
collect_every = 80
time_threshold = 950
metric {
name = "proc_run"
value_threshold = "1.0"
}
metric {
name = "proc_total"
value_threshold = "1.0"
}
}
/* This collection group grabs the volatile memory metrics every 40 secs and
sends them at least every 180 secs. This time_threshold can be increased
significantly to reduce unneeded network traffic. */
collection_group {
collect_every = 40
time_threshold = 180
metric {
name = "mem_free"
value_threshold = "1024.0"
}
metric {
name = "mem_shared"
value_threshold = "1024.0"
}
metric {
name = "mem_buffers"
value_threshold = "1024.0"
}
metric {
name = "mem_cached"
value_threshold = "1024.0"
}
metric {
name = "swap_free"
value_threshold = "1024.0"
}
}
collection_group {
collect_every = 40
time_threshold = 300
metric {
name = "bytes_out"
value_threshold = 4096
}
metric {
name = "bytes_in"
value_threshold = 4096
}
metric {
name = "pkts_in"
value_threshold = 256
}
metric {
name = "pkts_out"
value_threshold = 256
}
}
/* Different than 2.5.x default since the old config made no sense */
collection_group {
collect_every = 1800
time_threshold = 3600
metric {
name = "disk_total"
value_threshold = 1.0
}
}
collection_group {
collect_every = 40
time_threshold = 180
metric {
name = "disk_free"
value_threshold = 1.0
}
metric {
name = "part_max_used"
value_threshold = 1.0
}
}
Cabe destacar que por default el archivo de configuración está preparado para enviar la información por multicast. Esto puede representar una dificultad para conexiones de distintos dominios administrativos, por lo que en dicho caso puede recurrirse a una configuración basada en unicast. El archivo que se muestra a continuación corresponde a una configuración que utiliza unicast, para lo cual se han realizado cambios en las secciones de udp_send_channel y udp_recv_channel.
/* 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. */
/* El tag <CLUSTER> es necesario para que gmetad pueda interpretar el XML */
cluster {
name = "Hexacta Nodes"
owner = "Hexacta"
latlong = "S34.5 W58.4"
url = "http://node2.hexacta.com:8080/gridsphere"
}
/* The host section describes attributes of the host, like the location */
host {
location = "Oficinas Hexacta"
}
/* 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 = 239.2.11.71
port = 8649
} */
udp_send_channel {
host = node1.hexacta.com
port = 8649
}
udp_send_channel {
host = node2.hexacta.com
port = 8649
}
udp_send_channel {
host = lsc.dc.uba.ar
port = 8649
}
/* You can specify as many udp_recv_channels as you like as well. */
/* udp_recv_channel {
mcast_join = 239.2.11.71
port = 8649
bind = 239.2.11.71
} */
udp_recv_channel {
port = 8649
}
/* You can specify as many tcp_accept_channels as you like to share
an xml description of the state of the cluster */
tcp_accept_channel {
port = 8649
}
/* The old internal 2.5.x metric array has been replaced by the following
collection_group directives. What follows is the default behavior for
collecting and sending metrics that is as close to 2.5.x behavior as
possible. */
/* This collection group will cause a heartbeat (or beacon) to be sent every
20 seconds. In the heartbeat is the GMOND_STARTED data which expresses
the age of the running gmond. */
collection_group {
collect_once = yes
time_threshold = 20
metric {
name = "heartbeat"
}
}
/* This collection group will send general info about this host every 1200 secs.
This information doesn't change between reboots and is only collected once. */
collection_group {
collect_once = yes
time_threshold = 1200
metric {
name = "cpu_num"
}
metric {
name = "cpu_speed"
}
metric {
name = "mem_total"
}
/* Should this be here? Swap can be added/removed between reboots. */
metric {
name = "swap_total"
}
metric {
name = "boottime"
}
metric {
name = "machine_type"
}
metric {
name = "os_name"
}
metric {
name = "os_release"
}
metric {
name = "location"
}
}
/* This collection group will send the status of gexecd for this host every 300 secs */
/* Unlike 2.5.x the default behavior is to report gexecd OFF. */
collection_group {
collect_once = yes
time_threshold = 300
metric {
name = "gexec"
}
}
/* This collection group will collect the CPU status info every 20 secs.
The time threshold is set to 90 seconds. In honesty, this time_threshold could be
set significantly higher to reduce unneccessary network chatter. */
collection_group {
collect_every = 20
time_threshold = 90
/* CPU status */
metric {
name = "cpu_user"
value_threshold = "1.0"
}
metric {
name = "cpu_system"
value_threshold = "1.0"
}
metric {
name = "cpu_idle"
value_threshold = "5.0"
}
metric {
name = "cpu_nice"
value_threshold = "1.0"
}
metric {
name = "cpu_aidle"
value_threshold = "5.0"
}
metric {
name = "cpu_wio"
value_threshold = "1.0"
}
/* The next two metrics are optional if you want more detail...
... since they are accounted for in cpu_system.
metric {
name = "cpu_intr"
value_threshold = "1.0"
}
metric {
name = "cpu_sintr"
value_threshold = "1.0"
}
*/
}
collection_group {
collect_every = 20
time_threshold = 90
/* Load Averages */
metric {
name = "load_one"
value_threshold = "1.0"
}
metric {
name = "load_five"
value_threshold = "1.0"
}
metric {
name = "load_fifteen"
value_threshold = "1.0"
}
}
/* This group collects the number of running and total processes */
collection_group {
collect_every = 80
time_threshold = 950
metric {
name = "proc_run"
value_threshold = "1.0"
}
metric {
name = "proc_total"
value_threshold = "1.0"
}
}
/* This collection group grabs the volatile memory metrics every 40 secs and
sends them at least every 180 secs. This time_threshold can be increased
significantly to reduce unneeded network traffic. */
collection_group {
collect_every = 40
time_threshold = 180
metric {
name = "mem_free"
value_threshold = "1024.0"
}
metric {
name = "mem_shared"
value_threshold = "1024.0"
}
metric {
name = "mem_buffers"
value_threshold = "1024.0"
}
metric {
name = "mem_cached"
value_threshold = "1024.0"
}
metric {
name = "swap_free"
value_threshold = "1024.0"
}
}
collection_group {
collect_every = 40
time_threshold = 300
metric {
name = "bytes_out"
value_threshold = 4096
}
metric {
name = "bytes_in"
value_threshold = 4096
}
metric {
name = "pkts_in"
value_threshold = 256
}
metric {
name = "pkts_out"
value_threshold = 256
}
}
/* Different than 2.5.x default since the old config made no sense */
collection_group {
collect_every = 1800
time_threshold = 3600
metric {
name = "disk_total"
value_threshold = 1.0
}
}
collection_group {
collect_every = 40
time_threshold = 180
metric {
name = "disk_free"
value_threshold = 1.0
}
metric {
name = "part_max_used"
value_threshold = 1.0
}
}
3.2.3 Configuración de gmond para que se ejecute al iniciar el sistema
Crear el archivo de inicio /etc/init.d/gmond con el contenido que se lista a continuación.
#!/bin/sh
#
# update-rc.d: 2345 70 40
# description: gmond startup script
#
case "$1" in
start)
echo -n "Starting GANGLIA gmond: "
gmond
;;
stop)
echo -n "Shutting down GANGLIA gmond: "
pkill gmond
;;
restart|reload)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0
Para que el script sea invocado en el inicio, utilizar la utilidad update-rc.d para indicar que el daemon se active en los niveles 2,3,4 y 5 (defaults) con prioridad 70 para encendido, y que su prioridad de apagado sea 40.
Como root:
update-rc.d gmond defaults 70 40
3.2.4 Instalación de la Round-Robin Database Tool
La Round-Robin Database Tool (o RRD), puede obtenerse en código fuente de http://oss.oetiker.ch/rrdtool/index.en.html o bien descargarse como un paquete debian, utilizando el comando apt-get. Para contar con las librerías necesarias para este caso, deberá obtenerse como fuente y compilarse.
Una vez obtenido el .tar.gz correspondiente:
Como un usuario con permisos sobre el directorio en que se extraerá el archivo:
$ tar -zxvf rrdtool.tar.gz
Luego exportar las siguientes variables de entorno:
BUILD_DIR=/tmp/rrdbuild
INSTALL_DIR=/usr/local/rrdtool-1.2.15 (o la versión correspondiente)
Crear el directorio BUILD_DIR, y posicionarse en él,
Como el usuario con el cual se hará el configure y el make:
mkdir -p $BUILD_DIR
cd $BUILD_DIR
Instalar las librerías accesorias en el directorio temporal, compilándolas en forma estática:
cd $BUILD_DIR wget http://oss.oetiker.ch/rrdtool/pub/libs/zlib-1.2.3.tar.gz tar zxf zlib-1.2.3.tar.gz cd zlib-1.2.3 env CFLAGS="-O3 -fPIC" ./configure --prefix=$BUILD_DIR/lb make make install cd $BUILD_DIR wget http://oss.oetiker.ch/rrdtool/pub/libs/libpng-1.2.10.tar.gz tar zxvf libpng-1.2.10.tar.gz cd libpng-1.2.10 env CPPFLAGS="-I$BUILD_DIR/lb/include" LDFLAGS="-L$BUILD_DIR/lb/lib" CFLAGS="-O3 -fPIC" ./configure --disable-shared --prefix=$BUILD_DIR/lb make make install cd $BUILD_DIR wget http://oss.oetiker.ch/rrdtool/pub/libs/freetype-2.1.10.tar.bz2 tar jxvf freetype-2.1.10.tar.bz2 cd freetype-2.1.10 env CPPFLAGS="-I$BUILD_DIR/lb/include" LDFLAGS="-L$BUILD_DIR/lb/lib" CFLAGS="-O3 -fPIC" ./configure --disable-shared --prefix=$BUILD_DIR/lb make make install cd $BUILD_DIR wget http://oss.oetiker.ch/rrdtool/pub/libs/libart_lgpl-2.3.17.tar.gz tar zxvf libart_lgpl-2.3.17.tar.gz cd libart_lgpl-2.3.17 env CFLAGS="-O3 -fPIC" ./configure --disable-shared --prefix=$BUILD_DIR/lb make make installFinalmente, antes de ejecutar nuevamente el configure, exportar las siguientes variables de entorno:
IR=-I$BUILD_DIR/lb/include
CPPFLAGS="$IR $IR/libart-2.0 $IR/freetype2 $IR/libpng"
LDFLAGS="-L$BUILD_DIR/lb/lib"
CFLAGS=-O3
export CPPFLAGS LDFLAGS CFLAGS (para exportarlas)
Ejecutar el configure de rrdtool-1.2.5 (donde se extrajo el .tar.gz), hacerlo sin los bindings de phyton y tcl:
./configure --prefix=$INSTALL_DIR --disable-python --disable-tcl
make clean
make
Y como root:
make install
3.2.5 Instalación de Ganglia con gmetad
Para instalar Ganglia, obtener en primer lugar el archivo tar correspondiente al core del monitor Ganglia de http://ganglia.sourceforge.net/downloads.php .
Descomprimir dicho archivo en un directorio en el host que contiene el portal y ejecutar configure, make y make install como se indica. Para que se incluya gmetad, debe utilizarse el switch --with-gmetad al realizar el configure. También se agregan modificadores adicionales para indicar que el archivo rrd.h se encuentra en /usr/local/rrdtool-1.2.5/include y que el archivo librrd.a se encuentra en /usr/local/rrdtool-1.2.5/lib. En caso de tener dichos archivos en otras ubicaciones, indicar los modificadores CFLAGS, CPPFLAGS y LDFLAGS de manera acorde. Las ubicaciones default son /usr/include para rrd.h y /usr/lib para librrd.a.
Como un usuario con permisos sobre el directorio en que se descomprimirá el tar:
$ tar -zxvf ganglia-3.0.3.tar.gz
ganglia-3.0.3 $ ./configure CFLAGS="-I/usr/local/rrdtool-1.2.15/include" CPPFLAGS="-I/usr/local/rrdtool-1.2.15/include" LDFLAGS="-L/usr/local/rrdtool-1.2.15/lib" --with-gmetad
ganglia-3.0.3 $ make
Como root:
ganglia-3.0.3 # make install
Los pasos realizados instalan los siguientes archivos:
/usr/bin/gstat
/usr/bin/gmetric
/usr/sbin/gmond
/usr/sbin/gmetad
/usr/lib/libiganglia.a
/usr/lib/libiganglia.la
/usr/lib/libiganglia.so
3.2.6 Instalación del PHP Web Frontend
El PHP Web Frontend provisto por Ganglia se instala por simple copia. Los archivos a copiar se encuentran en el subdirectorio web del directorio en que se ha descomprimido el .tar.gz de Ganglia y deben copiarse dentro del directorio raíz de documentos del web server, en este caso se hará dentro de un subdirectorio llamado ganglia.
Como un usuario con permisos sobre el directorio raíz de documentos del web server:
$ mkdir ganglia
ganglia-3..0.3/web$ cp -R * ./ganglia/
El PHP Web Frontend requiere que gmetad esté instalado en la máquina que contiene el web server.
3.2.7 Configuración del PHP Web Frontend
La configuración del frontend se realiza mediante el archivo conf.php del subdirectorio correspondiente al frontend en el directorio raíz de documentos del webserver.
En particular, será necesario definir la variable RRDTOOL de acuerdo al directorio en que se haya instalado dicha herramienta. Para el caso ejemplificado en esta guía, será /usr/local/rrdtool-1.2.15/bin/rrdtool.
3.2.8 Configuración de gmetad
Gmetad utiliza un archivo de configuración ubicado en /etc/gmetad.conf. A continuación se presenta un archivo de referencia.
# This is an example of a Ganglia Meta Daemon configuration file
# http://ganglia.sourceforge.net/
#
#-------------------------------------------------------------------------------
# Setting the debug_level to 1 will keep daemon in the forground and
# show only error messages. Setting this value higher than 1 will make
# gmetad output debugging information and stay in the foreground.
# default: 0
# debug_level 10
#
#-------------------------------------------------------------------------------
# What to monitor. The most important section of this file.
#
# The data_source tag specifies either a cluster or a grid to
# monitor. If we detect the source is a cluster, we will maintain a complete
# set of RRD databases for it, which can be used to create historical
# graphs of the metrics. If the source is a grid (it comes from another gmetad),
# we will only maintain summary RRDs for it.
#
# Format:
# data_source "my cluster" [polling interval] address1:port addreses2:port ...
#
# The keyword 'data_source' must immediately be followed by a unique
# string which identifies the source, then an optional polling interval in
# seconds. The source will be polled at this interval on average.
# If the polling interval is omitted, 15sec is asssumed.
#
# A list of machines which service the data source follows, in the
# format ip:port, or name:port. If a port is not specified then 8649
# (the default gmond port) is assumed.
# default: There is no default value
#
# 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
data_source "Hexacta Grid" localhost
#
#-------------------------------------------------------------------------------
# Scalability mode. If on, we summarize over downstream grids, and respect
# authority tags. If off, we take on 2.5.0-era behavior: we do not wrap our output
# in <GRID></GRID> tags, we ignore all <GRID> tags we see, and always assume
# we are the "authority" on data source feeds. This approach does not scale to
# large groups of clusters, but is provided for backwards compatibility.
# default: on
# scalable off
#
#-------------------------------------------------------------------------------
# The name of this Grid. All the data sources above will be wrapped in a GRID
# tag with this name.
# default: Unspecified
gridname "Nodos Hexacta"
#
#-------------------------------------------------------------------------------
# The authority URL for this grid. Used by other gmetads to locate graphs
# for our data sources. Generally points to a ganglia/
# website on this machine.
# default: "http://hostname/ganglia/";,
# where hostname is the name of this machine, as defined by gethostname().
# authority "http://mycluster.org/newprefix/";
#
#-------------------------------------------------------------------------------
# List of machines this gmetad will share XML with. Localhost
# is always trusted.
# default: There is no default value
# trusted_hosts 127.0.0.1 169.229.50.165 my.gmetad.org
#
#-------------------------------------------------------------------------------
# If you want any host which connects to the gmetad XML to receive
# data, then set this value to "on"
# default: off
# all_trusted on
#
#-------------------------------------------------------------------------------
# If you don't want gmetad to setuid then set this to off
# default: on
# setuid off
#
#-------------------------------------------------------------------------------
# User gmetad will setuid to (defaults to "nobody")
# default: "nobody"
# setuid_username "nobody"
#
#-------------------------------------------------------------------------------
# The port gmetad will answer requests for XML
# default: 8651
# xml_port 8651
#
#-------------------------------------------------------------------------------
# The port gmetad will answer queries for XML. This facility allows
# simple subtree and summation views of the XML tree.
# default: 8652
# interactive_port 8652
#
#-------------------------------------------------------------------------------
# The number of threads answering XML requests
# default: 4
# server_threads 10
#
#-------------------------------------------------------------------------------
# Where gmetad stores its round-robin databases
# default: "/var/lib/ganglia/rrds"
# rrd_rootdir "/usr/local/rrdtool-1.2.15"
3.2.9 Configuración de gmetad para que se ejecute al iniciar el sistema
Crear el archivo de inicio /etc/init.d/gmetad con el contenido que se lista a continuación.
#!/bin/sh
#
# update-rc.d: 2345 20 80
# description: gmond startup script
#
case "$1" in
start)
echo -n "Starting GANGLIA gmetad: "
gmetad
;;
stop)
echo -n "Shutting down GANGLIA gmetad: "
pkill gmetad
;;
restart|reload)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0
Para que el script sea invocado en el inicio, utilizar la utilidad update-rc.d para indicar que el daemon se active en los niveles 2,3,4 y 5 (defaults) con prioridad 20 para encendido, y que su prioridad de apagado sea 80.
Como root:
update-rc.d gmetad defaults 20 80
3.2.10 Cambios de permisos en directorios
Para que gmetad funcione adecuadamente, el usuario al que setea el uid (por default "nobody") debe ser el dueño de determinados directorios.
Para ello:
Como root:
chown nobody /usr/local/rrdtool-1.2.15
chown nobody /var/lib/ganglia/rrds