ganglia man page : gmond gmetad gmetad.py gmetric gstat gmond.conf

gmond
GMOND(1)                         User Commands                        GMOND(1)

NAME
       gmond - manual page for Ganglia Monitor Daemon

SYNOPSIS
       gmond [OPTIONS]...

DESCRIPTION
       The  Ganglia  Monitoring  Daemon  (gmond) listens to the cluster message channel, stores the data in-memory and
       when requested will output an XML description of the state of the cluster

       -h, --help
              Print help and exit

       -V, --version
              Print version and exit

       -c, --conf=STRING
              Location of gmond configuration file  (default= ‘/etc/ganglia/gmond.conf’)

       -l, --location=STRING
              Location of this host in the cluster ’rack,rank,plane’.  (default=‘0,0,0’)

       -d, --debug=INT
              Debug level. If greater than zero, daemon will stay in foreground.  (default=‘0’)

       -f, --foreground
              Run in foreground (don’t daemonize)  (default=off)

       -t, --default_config
              Print the default configuration to stdout and exit (default=off)

       -m, --metrics
              Print the list of metrics this gmond supports (default=off)

       -b, --bandwidth
              Calculate minimum bandwidth use for configuration (default=off)


       -r, --convert=STRING
              Convert a 2.5.x configuration file to the new 3.x format

       -p, --pid-file=STRING
              Write process-id to file

AUTHOR
       Matt Massie 

REPORTING BUGS
       Report all bugs to the Ganglia Bugzilla Page at

         http://bugzilla.ganglia.info/cgi-bin/bugzilla/index.cgi


gmond.conf
gmond.conf(5)              Ganglia Monitoring System             gmond.conf(5)

NAME
       gmond.conf - configuration file for ganglia monitoring daemon (gmond)

DESCRIPTION
       The gmond.conf file is used to configure the ganglia monitoring daemon (gmond) which is part of the Ganglia
       Distributed Monitoring System.

SECTIONS AND ATTRIBUTES
       All sections and attributes are case-insensitive.  For example, name or NAME or Name or NaMe are all
       equivalent.

       Some sections can be included in the configuration file multiple times and some sections are singular.  For
       example, you can have only one cluster section to define the attributes of the cluster being monitored;
       however, you can have multiple udp_recv_channel sections to allow gmond to receive message on multiple UDP
       channels.

   cluster
       There should only be one cluster section defined.  This section controls how gmond reports the attributes of
       the cluster that it is part of.

       The cluster section has four attributes: name, owner, latlong and url.

       For example,

         cluster {
           name = "Millennium Cluster"
           owner = "UC Berkeley CS Dept."
           latlong = "N37.37 W122.23"
           url = "http://www.millennium.berkeley.edu/"
         }

       The name attributes specifies the name of the cluster of machines.  The owner tag specifies the administrators
       of the cluster.  The pair name/owner should be unique to all clusters in the world.

       The latlong attribute is the latitude and longitude GPS coordinates of this cluster on earth.  Specified to 1
       mile accuracy with two decimal places per axis in decimal.

       The url for more information on the cluster.  Intended to give purpose, owner, administration, and account
       details for this cluster.

       There directives directly control the XML output of gmond.  For example, the cluster configuration example
       above would translate into the following XML.

         
         ...
         

   host
       The host section provides information about the host running this instance of gmond. Currently only the
       location string attribute is supported. Example:

        host {
          location = "1,2,3"
        }

       The numbers represent Rack, Rank and Plane respectively.

   globals
       The globals section controls general characteristics of gmond such as whether is should daemonize, what user it
       should run as, whether is should send/receive date and such.  The globals section has the following attributes:
       daemonize, setuid, user, debug_level, mute, deaf, allow_extra_data, host_dmax, host_tmax, cleanup_threshold,
       gexec, send_metadata_interval and module_dir.

       For example,

         globals {
           daemonize = true
           setuid = true
           user = nobody
           host_dmax = 3600
           host_tmax = 40
         }

       The daemonize attribute is a boolean.  When true, gmond will daemonize.  When false, gmond will run in the
       foreground.

       The setuid attribute is a boolean.  When true, gmond will set its effective UID to the uid of the user
       specified by the user attribute.  When false, gmond will not change its effective user.

       The debug_level is an integer value.  When set to zero (0), gmond will run normally.  A debug_level greater
       than zero will result in gmond running in the foreground and outputting debugging information.  The higher the
       debug_level the more verbose the output.

       The mute attribute is a boolean.  When true, gmond will not send data regardless of any other configuration
       directives.

       The deaf attribute is a boolean.  When true, gmond will not receive data regardless of any other configuration
       directives.

       The allow_extra_data attribute is a boolean.  When false, gmond will not send out the EXTRA_ELEMENT and
       EXTRA_DATA parts of the XML.  This might be useful if you are using your own frontend to the metric data and
       will like to save some bandwith.

       The host_dmax value is an integer with units in seconds.  When set to zero (0), gmond will never delete a host
       from its list even when a remote host has stopped reporting.  If host_dmax is set to a positive number then
       gmond will flush a host after it has not heard from it for host_dmax seconds.  By the way, dmax means "delete
       max".

       The host_tmax value is an integer with units in seconds. This value represents the maximum amount of time that
       gmond should wait between updates from a host. As messages may get lost in the network, gmond will consider the
       host as being down if it has not received any messages from it after 4 times this value. For example, if
       host_tmax is set to 20, the host will appear as down after 80 seconds with no messages from it. By the way,
       tmax means "timeout max".

       The cleanup_threshold is the minimum amount of time before gmond will cleanup any hosts or metrics where tn >
       dmax a.k.a. expired data.

       The gexec boolean allows you to specify whether gmond will announce the hosts availability to run gexec jobs.
       Note: this requires that gexecd is running on the host and the proper keys have been installed.

       The send_metadata_interval establishes an interval in which gmond will send or resend the metadata packets that
       describe each enabled metric. This directive by default is set to 0 which means that gmond will only send the
       metadata packets at startup and upon request from other gmond nodes running remotely. If a new machine running
       gmond is added to a cluster, it needs to announce itself and inform all other nodes of the metrics that it
       currently supports. In multicast mode, this isn’t a problem because any node can request the metadata of all
       other nodes in the cluster.  However in unicast mode, a resend interval must be established. The interval value
       is the minimum number of seconds between resends.

       The override_hostname and override_ip parameters allow an arbitrary hostname and/or IP (hostname can be
       optionally specified without IP) to use when identifying metrics coming from this host.

       The module_dir is an optional parameter indicating the directory where the DSO modules are to be located.  If
       absent, the value to use is set at configure time with the --with-moduledir option which will default if
       omitted to the a subdirectory named "ganglia" in the directory where libganglia will be installed.

       For example, in a 32-bit Intel compatible Linux host that is usually:

         /usr/lib/ganglia

   udp_send_channel
       You can define as many udp_send_channel sections as you like within the limitations of memory and file
       descriptors.  If gmond is configured as mute this section will be ignored.

       The udp_send_channel has a total of seven attributes: mcast_join, mcast_if, host, port, ttl, bind and
       bind_hostname.  bind and bind_hostname are mutually exclusive.

       For example, the 2.5.x version gmond would send on the following single channel by default...

         udp_send_channel {
           mcast_join = 239.2.11.71
           port       = 8649
         }

       The mcast_join and mcast_if attributes are optional.  When specified gmond will create the UDP socket and join
       the mcast_join multicast group and send data out the interface specified by mcast_if.

       You can use the bind attribute to bind to a particular local address to be used as the source for the multicast
       packets sent or let gmond resolve the default hostname if bind_hostname = yes.
       If only a host and port are specified then gmond will send unicast UDP messages to the hosts specified.

       You could specify multiple unicast hosts for redundancy as gmond will send UDP messages to all UDP channels.

       Be careful though not to mix multicast and unicast attributes in the same udp_send_channel definition.

       For example...

         udp_send_channel {
           host = host.foo.com
           port = 2389
         }
         udp_send_channel {
           host = 192.168.3.4
           port = 2344
         }

       would configure gmond to send messages to two hosts.  The host specification can be an IPv4/IPv6 address or a
       resolvable hostname.

       The ttl attribute lets you modify the Time-To-Live (TTL) of outgoing messages (unicast or multicast).

   udp_recv_channel
       You can specify as many udp_recv_channel sections as you like within the limits of memory and file descriptors.
       If gmond is configured deaf this attribute will be ignored.

       The udp_recv_channel section has following attributes: mcast_join, bind, port, mcast_if, family, retry_bind and
       buffer.  The udp_recv_channel can also have an acl definition (see ACCESS CONTROL LISTS below).

       For example, the 2.5.x gmond ran with a single udp receive channel...

         udp_recv_channel {
           mcast_join = 239.2.11.71
           bind       = 239.2.11.71
           port       = 8649
         }

       The mcast_join and mcast_if should only be used if you want to have this UDP channel receive multicast packets
       the multicast group mcast_join on interface mcast_if.  If you do not specify multicast attributes then gmond
       will simply create a UDP server on the specified port.

       You can use the bind attribute to bind to a particular local address.

       The family address is set to inet4 by default.  If you want to bind the port to an inet6 port, you need to
       specify that in the family attribute.  Ganglia will not allow IPV6=>IPV4 mapping (for portability and security
       reasons).  If you want to listen on both inet4 and inet6 for a particular port, explicitly state it with the
       following:

         udp_recv_channel {
           port = 8666
           family = inet4
         }
         udp_recv_channel {
           port = 8666
           family = inet6
         }

       If you specify a bind address, the family of that address takes precedence.  f your IPv6 stack doesn’t support
       IPV6_V6ONLY, a warning will be issued but gmond will continue working (this should rarely happen).

       Multicast Note: for multicast, specifying a bind address with the same value used for mcast_join will prevent
       unicast UDP messages to the same port from being processed.

       The sFlow protocol (see http://www.sflow.org) can be used to collect a standard set of performance metrics from
       servers. For servers that don’t include embedded sFlow agents, an open source sFlow agent is available on
       SourceForge (see http://host-sflow.sourceforge.net).

       To configure gmond to receive sFlow datagrams, simply add a udp_recv_channel with the port set to 6343 (the
       IANA registered port for sFlow):

         udp_recv_channel {
           port = 6343
         }

       Note: sFlow is unicast protocol, so don’t include mcast_join join.  Note: To use some other port for sFlow, set
       it here and then specify the port in an sflow section (see below).
       gmond will fail to run if it can’t bind to all defined udp_recv_channels.  Sometimes, on machines configured by
       DHCP, for example, the gmond daemon starts before a network address is assigned to the interface.
       Consequently, the bind fails and the gmond daemon does not run.  To assist in this situation, the boolean
       parameter retry_bind can be set to the value true and then the daemon will not abort on failure, it will enter
       a loop and repeat the bind attempt every 60 seconds:

         udp_recv_channel {
           port = 6343
           retry_bind = true
         }

       If you have a large system with lots of metrics, you might experience UDP drops. This happens when gmond is not
       able to process the UDP fast enough from the network. In this case you might consider changing your setup into
       a more distributed setup using aggregator gmond hosts.  Alternatively you can choose to create a bigger receive
       buffer:

         udp_recv_channel {
           port = 6343
           buffer = 10485760
         }
       B is specified in bytes, i.e.: 10485760 will allow 10MB UDP
       to be buffered in memory.

       Note: increasing buffer size will increase memory usage by gmond

   tcp_accept_channel
       You can specify as many tcp_accept_channel sections as you like within the limitations of memory and file
       descriptors.  If gmond is configured to be mute, then these sections are ignored.

       The tcp_accept_channel has the following attributes: bind, port, interface, family and timeout.  A
       tcp_accept_channel may also have an acl section specified (see ACCESS CONTROL LISTS below).

       For example, 2.5.x gmond would accept connections on a single TCP channel.

         tcp_accept_channel {
           port = 8649
         }
       The bind address is optional and allows you to specify which local address gmond will bind to for this channel.

       The port is an integer than specifies which port to answer requests for data.

       The family address is set to inet4 by default.  If you want to bind the port to an inet6 port, you need to
       specify that in the family attribute.  Ganglia will not allow IPV6=>IPV4 mapping (for portability and security
       reasons).  If you want to listen on both inet4 and inet6 for a particular port, explicitly state it with the
       following:

         tcp_accept_channel {
           port = 8666
           family = inet4
         }
         tcp_accept_channel {
           port = 8666
           family = inet6
         }

       If you specify a bind address, the family of that address takes precedence.  If your IPv6 stack doesn’t support
       IPV6_V6ONLY, a warning will be issued but gmond will continue working (this should rarely happen).

       The timeout attribute allows you to specify how many microseconds to block before closing a connection to a
       client.  The default is set to -1 (blocking IO) and will never abort a connection regardless of how slow the
       client is in fetching the report data.

       The interface is not implemented at this time (use bind).

   collection_group
       You can specify as many collection_group section as you like within the limitations of memory.  A
       collection_group has the following attributes: collect_once, collect_every and time_threshold.  A
       collection_group must also contain one or more metric sections.

       The metric section has the following attributes: (one of name or name_match; name_match is only permitted if
       pcre support is compiled in), value_threshold and title.  For a list of available metric names, run the
       following command:

         % gmond -m
       Here is an example of a collection group for a static metric...

         collection_group {
           collect_once   = yes
           time_threshold = 1800
           metric {
            name = "cpu_num"
            title = "Number of CPUs"
           }
         }

       This collection_group entry would cause gmond to collect the cpu_num metric once at startup (since the number
       of CPUs will not change between reboots).  The metric cpu_num would be send every 1/2 hour (1800 seconds).  The
       default value for the time_threshold is 3600 seconds if no time_threshold is specified.

       The time_threshold is the maximum amount of time that can pass before gmond sends all metrics specified in the
       collection_group to all configured udp_send_channels.  A metric may be sent before this time_threshold is met
       if during collection the value surpasses the value_threshold (explained below).

       Here is an example of a collection group for a volatile metric...

         collection_group {
           collect_every = 60
           time_threshold = 300
           metric {
             name = "cpu_user"
             value_threshold = 5.0
             title = "CPU User"
           }
           metric {
             name = "cpu_idle"
             value_threshold = 10.0
             title = "CPU Idle"
           }
         }

       This collection group would collect the cpu_user and cpu_idle metrics every 60 seconds (specified in
       collect_every).  If cpu_user varies by 5.0% or cpu_idle varies by 10.0%, then the entire collection_group is
       sent.  If no value_threshold is triggered within time_threshold seconds (in this case 300), the entire
       collection_group is sent.

       Each time the metric value is collected the new value is compared with the old value collected.  If the
       difference between the last value and the current value is greater than the value_threshold, the entire
       collection group is send to the udp_send_channels defined.

       It’s important to note that all metrics in a collection group are sent even when only a single value_threshold
       is surpassed.

       In addition a user friendly title can be substituted for the metric name by including a title within the metric
       section.

       By using the name_match parameter instead of name, it is possible to use a single definition to configure
       multiple metrics that match a regular expression.  The perl compatible regular expression (pcre) syntax is
       used.  This approach is particularly useful for a series of metrics that may vary in number between reboots
       (e.g. metric names that are generated for each individual NIC or CPU core).

       Here is an example of using the name_match directive to enable the multicpu metrics:

         metric {
           name_match = "multicpu_([a-z]+)([0-9]+)"
           value_threshold = 1.0
           title = "CPU-\\2 \\1"
         }

       Note that in the example above, there are two matches: the alphabetical match matches the variations of the
       metric name (e.g. idle, system) while the numeric match matches the CPU core number.  The second thing to note
       is the use of substitutions within the argument to title.

       If both name and name_match are specified, then name is ignored.

   Modules
       A modules section contains the parameters that are necessary to load a metric module. A metric module is a
       dynamically loadable module that extends the available metrics that gmond is able to collect. Each modules
       section contains at least one module section.  Within a module section are the directives name, language,
       enabled, path and params.  The module name is the name of the module as determined by the module structure if
       the module was developed in C/C++.  Alternatively, the name can be the name of the source file if the module
       has been implemented in a interpreted language such as python.  A language designation must be specified as a
       string value for each module.  The language directive must correspond to the source code language in which the
       module was implemented (ex. language = "python").  If a language directive does not exist for the module, the
       assumed language will be "C/C++". The enabled directive allows a metric module to be easily enabled or disabled
       through the configuration file. If the enabled directive is not included in the module configuration, the
       enabled state will default to "yes". One thing to note is that if a module has been disabled yet the metric
       which that module implements is still listed as part of a collection group, gmond will produce a warning
       message.  However gmond will continue to function normally by simply ignoring the metric. The path is the path
       from which gmond is expected to load the  module (C/C++ compiled dynamically loadable module only).  The params
       directive can be used to pass a single string parameter directly to the module initialization function (C/C++
       module only). Multiple parameters can be passed to the module’s initialization function by including one or
       more param sections. Each param section must be named and contain a value directive. Once a module has been
       loaded, the additional metrics can be discovered by invoking gmond -m.

          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
              }
            }
          }

   sFlow
       The sflow group is optional and has the following optional attributes: udp_port, accept_vm_metrics,
       accept_http_metrics, accept_memcache_metrics, accept_jvm_metrics,
       multiple_http_instances,multiple_memcache_instances, multiple_jvm_instances. By default, a udp_recv_channel on
       port 6343 (the IANA registered port for sFlow) is all that is required to accept and process sFlow datagrams.
       To receive sFlow on some other port requires both a udp_recv_channel for the other port and a udp_port setting
       here. For example:
          udp_recv_channel {
            port = 7343
          }

          sflow {
            udp_port = 7343
          }

       An sFlow agent running on a hypervisor may also be sending metrics for its local virtual machines.  By default
       these metrics are ignored, but the accept_vm_metrics flag can be used to accept those metrics too,  and prefix
       them with an identifier for each virtual machine.

          sflow {
            accept_vm_metrics = yes
          }

       The sFlow feed may also contain metrics sent from HTTP or memcached servers,  or from Java VMs.  Extra options
       can be used to ignore or accept these metrics,  and to indicate that there may be multiple instances per host.
       For example:

           sflow {
             accept_http_metrics = yes
             multiple_http_instances = yes
           }

       will allow the HTTP metrics, and also mark them with a distinguishing identifier so that each instance can be
       trended separately.  (If multiple instances are reporting and this flag is not set,  the results are likely to
       be garbled.)

   Include
       This directive allows the user to include additional configuration files rather than having to add all gmond
       configuration directives to the gmond.conf file.  The following example includes any file with the extension of
       .conf contained in the directory conf.d as if the contents of the included configuration files were part of the
       original gmond.conf file. This allows the user to modularize their configuration file.  One usage example might
       be to load individual metric modules by including module specific .conf files.

       include (’/etc/ganglia/conf.d/*.conf’)
ACCESS CONTROL
       The udp_recv_channel and tcp_accept_channel directives can contain an Access Control List (ACL).  This ACL
       allows you to specify exactly which hosts gmond process data from.

       An example of an acl entry looks like

         acl {
           default = "deny"
           access {
             ip = 192.168.0.4
             mask = 32
             action = "allow"
           }
         }

       This ACL will by default reject all traffic that is not specifically from host 192.168.0.4 (the mask size for
       an IPv4 address is 32, the mask size for an IPv6 address is 128 to represent a single host).

       Here is another example

         acl {
           default = "allow"
           access {
             ip = 192.168.0.0
             mask = 24
             action = "deny"
           }
           access {
             ip = ::ff:1.2.3.0
             mask = 120
             action = "deny"
           }
         }

       This ACL will by default allow all traffic unless it comes from the two subnets specified with action = "deny".

EXAMPLE
       The default behavior for a 2.5.x gmond would be specified as...

         udp_recv_channel {
           mcast_join = 239.2.11.71
           bind       = 239.2.11.71
           port       = 8649
         }
         udp_send_channel {
           mcast_join = 239.2.11.71
           port       = 8649
         }
         tcp_accept_channel {
           port       = 8649
         }

       To see the complete default configuration for gmond simply run:

         % gmond -t

       gmond will print out its default behavior in a configuration file and then exit.  Capturing this output to a
       file can serve as a useful starting point for creating your own custom configuration.

         % gmond -t > custom.conf

       edit custom.conf to taste and then

         % gmond -c ./custom.conf

SEE ALSO
       gmond(1).

NOTES
       The ganglia web site is at http://ganglia.info/.


gmetad
GMETAD(1)                        User Commands                       GMETAD(1)

NAME
       gmetad - manual page for Ganglia Meta Daemon

SYNOPSIS
       gmetad [OPTIONS]...

DESCRIPTION
       The  Ganglia  Meta  Daemon  (gmetad) collects information from multiple gmond or gmetad data sources, saves the
       information to local round-robin databases, and exports XML which is the concatentation of all data sources

       -h, --help
              Print help and exit

       -V, --version
              Print version and exit

       -c, --conf=STRING
              Location of gmetad configuration file (default=’/etc/ganglia/gmetad.conf’)

       -d, --debug=INT
              Debug level. If greater than zero, daemon will stay in foreground.  (default=’0’)

       -p, --pid-file=STRING
              Write process-id to file

AUTHOR
       Matt Massie 


gmetad.py
GMETAD.PY(1)                     User Commands                    GMETAD.PY(1)

NAME
       gmetad.py - Ganglia Meta Daemon in Python

SYNOPSIS
       gmetad.py [options]

OPTIONS
       --version
              show program’s version number and exit

       -h, --help
              show this help message and exit

       -d DEBUG, --debug=DEBUG
              Debug  level. If five (5) or greater, daemon will stay in foreground.  Values are:             0 - FATAL
              1 - CRITICAL             2 - ERROR (default) 3 - WARNING             4 - INFO             5 - DEBUG

       -p PID_FILE, --pid_file=PID_FILE
              Write process-id to file

       -c CONF, --conf=CONF
              Location of gmetad configuration file (default=’/etc/ganglia/gmetad-python.conf’)

       -l LOGFILE, --logfile=LOGFILE
              Log messages to this path in addition to syslog; overrides configuration

       -i INTERACTIVE_PORT, --interactive_port=INTERACTIVE_PORT
              Interactive port to listen on (default=8652)

       -x XML_PORT, --xml_port=XML_PORT
              XML port to listen on (default=8651)

gmetad.py                        January 2011                     GMETAD.PY(1)


gmetric
GMETRIC(1)                       User Commands                      GMETRIC(1)

NAME
       gmetric - manual page for Ganglia Custom Metric Utility

SYNOPSIS
       gmetric [OPTIONS]...

DESCRIPTION
       The  Ganglia  Metric Client (gmetric) announces a metric on the list of defined send channels defined in a con-
       figuration file

       -h, --help
              Print help and exit

       -V, --version
              Print version and exit

       -c, --conf=STRING
              The configuration file to use for finding send channels (default=‘/etc/ganglia/gmond.conf’)

       -n, --name=STRING
              Name of the metric

       -v, --value=STRING
              Value of the metric

       -t, --type=STRING
              Either string|int8|uint8|int16|uint16|int32|uint32|float|double

       -u, --units=STRING
              Unit of measure for the value e.g. Kilobytes, Celcius (default=‘’)

       -s, --slope=STRING
              Either zero|positive|negative|both  (default=‘both’)

       -x, --tmax=INT
              The maximum time in seconds between gmetric calls (default=‘60’)

       -d, --dmax=INT
              The lifetime in seconds of this metric  (default=‘0’)

       -g, --group=STRING
              Group of the metric

       -D, --desc=STRING
              Description of the metric

       -T, --title=STRING
              Title of the metric

       -S, --spoof=STRING
              IP address and name of host/device (colon separated) we are spoofing  (default=‘’)

       -H, --heartbeat
              spoof a heartbeat message (use with spoof option)

AUTHOR
       Matt Massie 


gstat
GSTAT(1)                         User Commands                        GSTAT(1)

NAME
       gstat - manual page for Ganglia Status Tool

SYNOPSIS
       gstat [OPTIONS]...

DESCRIPTION
       The Ganglia Status Client (gstat) connects with a Ganglia Monitoring Daemon (gmond) and outputs a load-balanced
       list of hosts

       -h, --help
              Print help and exit

       -V, --version
              Print version and exit

       -a, --all
              List all hosts.  Not just hosts running gexec (default=off)

       -d, --dead
              Print only the hosts which are dead  (default=off)

       -m, --mpifile
              Print a load-balanced mpifile  (default=off)

       -1, --single_line
              Print host and information all on one line  (default= off)

       -l, --list
              Print ONLY the host list  (default=off)

       -n, --numeric
              Print numeric addresses instead of hostnames (default=off)

       -i, --gmond_ip=STRING
              Specify the ip address of the gmond to query (default=‘localhost’)
       -p, --gmond_port=INT
              Specify the gmond port to query  (default=‘8649’)

AUTHOR
       Matt Massie 


gmetad.conf 
# 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. 
#
# If you choose to set the polling interval to something other than the default,
# note that the web frontend determines a host as down if its TN value is less
# than 4 * TMAX (20sec by default).  Therefore, if you set the polling interval
# to something around or greater than 80sec, this will cause the frontend to
# incorrectly display hosts as down even though they are not.
#
# 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 "my cluster" localhost

#
# Round-Robin Archives
# You can specify custom Round-Robin archives here (defaults are listed below)
#
# Old Default RRA: Keep 1 hour of metrics at 15 second resolution. 1 day at 6 minute
# RRAs "RRA:AVERAGE:0.5:1:244" "RRA:AVERAGE:0.5:24:244" "RRA:AVERAGE:0.5:168:244" "RRA:AVERAGE:0.5:672:244" \
#      "RRA:AVERAGE:0.5:5760:374"
# New Default RRA
# Keep 5856 data points at 15 second resolution assuming 15 second (default) polling. That's 1 day
# Two weeks of data points at 1 minute resolution (average)
#RRAs "RRA:AVERAGE:0.5:1:5856" "RRA:AVERAGE:0.5:4:20160" "RRA:AVERAGE:0.5:40:52704"

#
#-------------------------------------------------------------------------------
# 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  tags, we ignore all  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 "MyGrid"
#
#-------------------------------------------------------------------------------
# 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"
#
#-------------------------------------------------------------------------------
# Umask to apply to created rrd files and grid directory structure
# default: 0 (files are public)
# umask 022
#
#-------------------------------------------------------------------------------
# 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 "/some/other/place"
#
#-------------------------------------------------------------------------------
# List of metric prefixes this gmetad will not summarize at cluster or grid level.
# default: There is no default value
# unsummarized_metrics diskstat CPU
#
#-------------------------------------------------------------------------------
# In earlier versions of gmetad, hostnames were handled in a case
# sensitive manner
# If your hostname directories have been renamed to lower case,
# set this option to 0 to disable backward compatibility.
# From version 3.2, backwards compatibility will be disabled by default.
# default: 1   (for gmetad < 3.2)
# default: 0   (for gmetad >= 3.2)
case_sensitive_hostnames 0

#-------------------------------------------------------------------------------
# It is now possible to export all the metrics collected by gmetad directly to
# graphite by setting the following attributes. 
#
# The hostname or IP address of the Graphite server
# default: unspecified
# carbon_server "my.graphite.box"
#
# The port and protocol on which Graphite is listening
# default: 2003
# carbon_port 2003
#
# default: tcp
# carbon_protocol udp
#
# **Deprecated in favor of graphite_path** A prefix to prepend to the 
# metric names exported by gmetad. Graphite uses dot-
# separated paths to organize and refer to metrics. 
# default: unspecified
# graphite_prefix "datacenter1.gmetad"
#
# A user-definable graphite path. Graphite uses dot-
# separated paths to organize and refer to metrics. 
# For reverse compatibility graphite_prefix will be prepended to this
# path, but this behavior should be considered deprecated.
# This path may include 3 variables that will be replaced accordingly:
# %s -> source (cluster name)
# %h -> host (host name)
# %m -> metric (metric name)
# default: graphite_prefix.%s.%h.%m
# graphite_path "datacenter1.gmetad.%s.%h.%m

# Number of milliseconds gmetad will wait for a response from the graphite server 
# default: 500
# carbon_timeout 500

#-------------------------------------------------------------------------------
# Memcached configuration (if it has been compiled in)
# Format documentation at http://docs.libmemcached.org/libmemcached_configuration.html
# default: ""
# memcached_parameters "--SERVER=127.0.0.1"
#


[参考]
1. man 

你可能感兴趣的:(运维,python,memcached)