collectd-nagios(1) [debian man page]
COLLECTD-NAGIOS(1) collectd COLLECTD-NAGIOS(1) NAME
collectd-nagios - Nagios plugin for querying collectd SYNOPSIS
collectd-nagios -s socket -n value_spec -H hostname [options] DESCRIPTION
This small program is the glue between collectd and nagios. collectd collects various performance statistics which it provides via the "unixsock plugin", see collectd-unixsock(5). This program is called by Nagios, connects to the UNIX socket and reads the values from collectd. It then returns OKAY, WARNING or CRITICAL depending on the values and the ranges provided by Nagios. ARGUMENTS AND OPTIONS
The following arguments and options are required and understood by collectd-nagios. The order of the arguments generally doesn't matter, as long as no argument is passed more than once. -s socket Path of the UNIX socket opened by collectd's "unixsock plugin". -n value_spec The value to read from collectd. The argument is in the form "plugin[-instance]/type[-instance]". -H hostname Hostname to query the values for. -d data_source Each value_spec may be made of multiple "data sources". With this option you can select one or more data sources. To select multiple data sources simply specify this option again. If multiple data sources are examined they are handled according to the consolidation function given with the -g option. -g none|average|sum When multiple data sources are selected from a value spec, they can be handled differently depending on this option. The values of the following meaning: none No consolidation if done and the warning and critical regions are applied to each value independently. average The warning and critical ranges are applied to the average of all values. sum The warning and critical ranges are applied to the sum of all values. percentage The warning and critical ranges are applied to the ratio (in percent) of the first value and the sum of all values. A warning is returned if the first value is not defined or if all values sum up to zero. -c range -w range Set the critical (-c) and warning (-w) ranges. These options mostly follow the normal syntax of Nagios plugins. The general format is "min:max". If a value is smaller than min or bigger than max, a warning or critical status is returned, otherwise the status is success. The tilde sign (~) can be used to explicitly specify infinity. If ~ is used as a min value, negative infinity is used. In case of max, it is interpreted as positive infinity. If the first character of the range is the at sign (@), the meaning of the range will be inverted. I. e. all values within the range will yield a warning or critical status, while all values outside the range will result in a success status. min (and the colon) may be omitted, min is then assumed to be zero. If max (but not the trailing colon) is omitted, max is assumed to be positive infinity. -m If this option is given, "Not a Number" (NaN) is treated as critical. By default, the none consolidation reports NaNs as warning. Other consolidations simply ignore NaN values. RETURN VALUE
As usual for Nagios plugins, this program writes a short, one line status message to STDOUT and signals success or failure with it's return value. It exits with a return value of 0 for success, 1 for warning and 2 for critical. If the values are not available or some other error occurred, it returns 3 for unknown. SEE ALSO
collectd(1), collectd.conf(5), collectd-unixsock(5), <http://nagios.org/> AUTHOR
Florian Forster <octo at verplant.org> 5.1.0 2012-04-02 COLLECTD-NAGIOS(1)
Check Out this Related Man Page
COLLECTD(1) collectd COLLECTD(1) NAME
collectd - System statistics collection daemon SYNOPSIS
collectd [options] DESCRIPTION
collectd is a daemon that receives system statistics and makes them available in a number of ways. The main daemon itself doesn't have any real functionality apart from loading, querying and submitting to plugins. For a description of available plugins please see "PLUGINS" below. OPTIONS
Most of collectd's configuration is done using using a configfile. See collectd.conf(5) for an in-depth description of all options. -C <config-file> Specify an alternative config file. This is the place to go when you wish to change collectd's behavior. The path may be relative to the current working directory. -t Test the configuration only. The program immediately exits after parsing the config file. A return code not equal to zero indicates an error. -T Test the plugin read callbacks only. The program immediately exits after invoking the read callbacks once. A return code not equal to zero indicates an error. -P <pid-file> Specify an alternative pid file. This overwrites any settings in the config file. This is thought for init-scripts that require the PID-file in a certain directory to work correctly. For everyday-usage use the PIDFile config-option. -f Don't fork to the background. collectd will also not close standard file descriptors, detach from the session nor write a pid file. This is mainly thought for 'supervising' init replacements such as runit. -h Output usage information and exit. PLUGINS
As noted above, the real power of collectd lies within it's plugins. A (hopefully complete) list of plugins and short descriptions can be found in the README file that is distributed with the sourcecode. If you're using a package it's a good bet to search somewhere near /usr/share/doc/collectd. There are two big groups of plugins, input and output plugins: o Input plugins are queried periodically. They somehow acquire the current value of whatever they where designed to work with and submit these values back to the daemon, i. e. they "dispatch" the values. As an example, the "cpu plugin" reads the current cpu-counters of time spent in the various modes (user, system, nice, ...) and dispatches these counters to the daemon. o Output plugins get the dispatched values from the daemon and does something with them. Common applications are writing to RRD-files, CSV-files or sending the data over a network link to a remote box. Of course not all plugins fit neatly into one of the two above categories. The "network plugin", for example, is able to send (i. e. "write") and receive (i. e. "dispatch") values. Also, it opens a socket upon initialization and dispatches the values when it receives them and isn't triggered at the same time the input plugins are being read. You can think of the network receive part as working asynchronous if it helps. In addition to the above, there are "logging plugins". Right now those are the "logfile plugin" and the "syslog plugin". With these plugins collectd can provide information about issues and significant situations to the user. Several loglevels let you suppress uninteresting messages. Starting with version 4.3.0 collectd has support for monitoring. This is done by checking thresholds defined by the user. If a value is out of range, a notification will be dispatched to "notification plugins". See collectd.conf(5) for more detailed information about threshold checking. Please note that some plugins, that provide other means of communicating with the daemon, have manpages of their own to describe their functionality in more detail. In particular those are collectd-email(5), collectd-exec(5), collectd-perl(5), collectd-snmp(5), and collectd-unixsock(5) SIGNALS
collectd accepts the following signals: SIGINT, SIGTERM These signals cause collectd to shut down all plugins and terminate. SIGUSR1 This signal causes collectd to signal all plugins to flush data from internal caches. E. g. the "rrdtool plugin" will write all pending data to the RRD files. This is the same as using the "FLUSH -1" command of the "unixsock plugin". SEE ALSO
collectd.conf(5), collectd-email(5), collectd-exec(5), collectd-perl(5), collectd-snmp(5), collectd-unixsock(5), types.db(5), <http://collectd.org/> AUTHOR
Florian Forster <octo@verplant.org> 5.1.0 2012-04-02 COLLECTD(1)