Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
COLLECTD(1)			   collectd			   COLLECTD(1)

       collectd	- System statistics collection daemon

       collectd	[options]

       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.

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

       -B  If set, collectd will not try to create its base directory. If the
	   base	directory does not exist, it will exit rather than trying to
	   create the directory.

       -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. If using upstart or systemd though, starting with version
	   5.5.0 collectd is able to notify these two init replacements, and
	   does	require	forking	to the background for process supervision. The
	   contrib/ directory has sample upstart and systemd configuration

       -h  Output usage	information and	exit.

       As noted	above, the real	power of collectd lies within its 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:

       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

       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

       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 <>		  2020-07-20			   COLLECTD(1)


Want to link to this manual page? Use this URL:

home | help