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

       ·   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.

       ·   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), 

AUTHOR
       Florian Forster 



5.4.0						    2013-08-18					       COLLECTD(1)

search for:
on the internet, or:
JohnMeister.com-fotos
LinuxMeister-Linux
BibleTech- Bible overview

johnmeister.com/jeep/sj

FULL SIZE JEEPS

JeepMeister
"Jeep is America's
only real sports car."
-Enzo Ferrari


MeisterTech
Diesels +

One Page Overview

Intro to Linux
FREE!

FREE!
AMSOIL product guide,
or, AMSOIL web, or 1-800-956-5695,
use customer #283461

Amsoil dealer since 1983
purchase AMSOIL
at Midway Auto on SR9 in Snohomish,
or at Northland Diesel in Bellingham, WA


SJ - 1962-1991

XJ - 1984-2001

WJ - 1999-2004

KJ - 2002-2007

WK - 2005-2010

Find the recommended
AMSOIL synthetics
for your Jeep

CJ-10A - 1984-1986

Jeepsters

MJ - 1984-1992

Willys - 1946-1965

Other Jeeps (FC)