collectd(1)

1COLLECTD(1)                        collectd                        COLLECTD(1)
2
3
4

NAME

6       collectd - System statistics collection daemon
7

SYNOPSIS

9       collectd [options]
10

DESCRIPTION

12       collectd is a daemon that receives system statistics and makes them
13       available in a number of ways. The main daemon itself doesn't have any
14       real functionality apart from loading, querying and submitting to
15       plugins. For a description of available plugins please see "PLUGINS"
16       below.
17

OPTIONS

19       Most of collectd's configuration is done using using a configfile. See
20       collectd.conf(5) for an in-depth description of all options.
21
22       -C <config-file>
23           Specify an alternative config file. This is the place to go when
24           you wish to change collectd's behavior. The path may be relative to
25           the current working directory.
26
27       -t  Test the configuration only. The program immediately exits after
28           parsing the config file. A return code not equal to zero indicates
29           an error.
30
31       -T  Test the plugin read callbacks only. The program immediately exits
32           after invoking the read callbacks once. A return code not equal to
33           zero indicates an error.
34
35       -P <pid-file>
36           Specify an alternative pid file. This overwrites any settings in
37           the config file. This is thought for init-scripts that require the
38           PID-file in a certain directory to work correctly. For everyday-
39           usage use the PIDFile config-option.
40
41       -B  If set, collectd will not try to create its base directory. If the
42           base directory does not exist, it will exit rather than trying to
43           create the directory.
44
45       -f  Don't fork to the background. collectd will also not close standard
46           file descriptors, detach from the session nor write a pid file.
47           This is mainly thought for 'supervising' init replacements such as
48           runit. If using upstart or systemd though, starting with version
49           5.5.0 collectd is able to notify these two init replacements, and
50           does require forking to the background for process supervision. The
51           contrib/ directory has sample upstart and systemd configuration
52           files.
53
54       -h  Output usage information and exit.
55

PLUGINS

57       As noted above, the real power of collectd lies within it's plugins. A
58       (hopefully complete) list of plugins and short descriptions can be
59       found in the README file that is distributed with the sourcecode. If
60       you're using a package it's a good bet to search somewhere near
61       /usr/share/doc/collectd.
62
63       There are two big groups of plugins, input and output plugins:
64
65       ·   Input plugins are queried periodically. They somehow acquire the
66           current value of whatever they where designed to work with and
67           submit these values back to the daemon, i. e. they "dispatch" the
68           values. As an example, the "cpu plugin" reads the current cpu-
69           counters of time spent in the various modes (user, system, nice,
70           ...) and dispatches these counters to the daemon.
71
72       ·   Output plugins get the dispatched values from the daemon and does
73           something with them. Common applications are writing to RRD-files,
74           CSV-files or sending the data over a network link to a remote box.
75
76       Of course not all plugins fit neatly into one of the two above
77       categories. The "network plugin", for example, is able to send (i. e.
78       "write") and receive (i. e. "dispatch") values. Also, it opens a socket
79       upon initialization and dispatches the values when it receives them and
80       isn't triggered at the same time the input plugins are being read. You
81       can think of the network receive part as working asynchronous if it
82       helps.
83
84       In addition to the above, there are "logging plugins". Right now those
85       are the "logfile plugin" and the "syslog plugin". With these plugins
86       collectd can provide information about issues and significant
87       situations to the user.  Several loglevels let you suppress
88       uninteresting messages.
89
90       Starting with version 4.3.0 collectd has support for monitoring. This
91       is done by checking thresholds defined by the user. If a value is out
92       of range, a notification will be dispatched to "notification plugins".
93       See collectd.conf(5) for more detailed information about threshold
94       checking.
95
96       Please note that some plugins, that provide other means of
97       communicating with the daemon, have manpages of their own to describe
98       their functionality in more detail. In particular those are
99       collectd-email(5), collectd-exec(5), collectd-perl(5),
100       collectd-snmp(5), and collectd-unixsock(5)
101

SIGNALS

103       collectd accepts the following signals:
104
105       SIGINT, SIGTERM
106           These signals cause collectd to shut down all plugins and
107           terminate.
108
109       SIGUSR1
110           This signal causes collectd to signal all plugins to flush data
111           from internal caches. E. g. the "rrdtool plugin" will write all
112           pending data to the RRD files. This is the same as using the "FLUSH
113           -1" command of the "unixsock plugin".
114

AUTHOR

121       Florian Forster <octo@collectd.org>
122
123
124
1255.8.0.145.gca1cb27                2018-10-23                       COLLECTD(1)