Provided by: collectd-core_4.8.2-1_i386
collectd - System statistics collection daemon
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"
Most of collectd’s configuration is done using using a configfile. See
collectd.conf(5) for an in-depth description of all options.
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
-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.
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
-h Output usage information and exit.
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
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
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
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
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)
collectd accepts the following signals:
These signals cause collectd to shut down all plugins and
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".
collectd.conf(5), collectd-email(5), collectd-exec(5),
collectd-perl(5), collectd-snmp(5), collectd-unixsock(5), types.db(5),
Florian Forster <email@example.com>