Code

d5bd792f284877211977641069307e0db7a49b56
[collectd.git] / src / collectd.pod
1 =head1 NAME
3 collectd - System statistics collection daemon
5 =head1 SYNOPSIS
7 collectd I<[options]>
9 =head1 DESCRIPTION
11 collectd is a daemon that receives system statistics and makes them available
12 in a number of ways. The main daemon itself doesn't have any real functionality
13 apart from loading, querying and submitting to plugins. For a description of
14 available plugins please see L</PLUGINS> below.
16 =head1 OPTIONS
18 Most of collectd's configuration is done using using a configfile. See
19 L<collectd.conf(5)> for an in-depth description of all options.
21 =over 4
23 =item B<-C> I<E<lt>config-fileE<gt>>
25 Specify an alternative config file. This is the place to go when you wish to
26 change B<collectd>'s behavior. The path may be relative to the current working
27 directory.
29 =item B<-t>
31 Test the configuration only. The program immediately exits after parsing the
32 config file. A return code not equal to zero indicates an error.
34 =item B<-P> I<E<lt>pid-fileE<gt>>
36 Specify an alternative pid file. This overwrites any settings in the config 
37 file. This is thought for init-scripts that require the PID-file in a certain
38 directory to work correctly. For everyday-usage use the B<PIDFile>
39 config-option.
41 =item B<-f>
43 Don't fork to the background. I<collectd> will also B<not> close standard file
44 descriptors, detach from the session nor write a pid file. This is mainly
45 thought for 'supervisioning' init replacements such as I<runit>.
47 =item B<-h>
49 Output usage information and exit.
51 =back
53 =head1 PLUGINS
55 As noted above, the real power of collectd lies within it's plugins. A
56 (hopefully complete) list of plugins and short descriptions can be found in the
57 F<README> file that is distributed with the sourcecode. If you're using a
58 package it's a good bet to search somewhere near F</usr/share/doc/collectd>.
60 There are two big groups of plugins, B<input> and B<output> plugins:
62 =over 4
64 =item
66 Input plugins are queried periodically. They somehow aquire the current value
67 of whatever they where designed to work with and submit these values back to
68 the daemon, i. e. they "dispatch" the values. As an example, the C<cpu plugin>
69 reads the current cpu-counters of time spent in the various modes (user,
70 system, nice, ...) and dispatches these counters to the daemon.
72 =item
74 Output plugins get the dispatched values from the daemon and does something
75 with them. Common applications are writing to RRD-files, CSV-files or sending
76 the data over a network link to a remote box.
78 =back
80 Of course not all plugins fit neatly into one of the two above categories. The
81 C<network plugin>, for example, is able to send (i.E<nbsp>e. "write") B<and>
82 receive (i.E<nbsp>e. "dispatch") values. Also, it opens a socket upon
83 initialization and dispatches the values when it receives them and isn't
84 triggered at the same time the input plugins are being read. You can think of
85 the network receive part as working asynchronous if it helps.
87 In addition to the above, there are "logging plugins". Right now those are the
88 C<logfile plugin> and the C<syslog plugin>. With these plugins collectd can
89 provide information about issues and significant situations to the user.
90 Several loglevels let you suppress uninteresting messages.
92 Please note that some plugins, that provide other means of communicating with
93 the daemon, have manpages of their own to describe their functionality in more
94 detail. In particular those are L<collectd-email(5)>, L<collectd-exec(5)>,
95 L<collectd-perl(5)>, and L<collectd-unixsock(5)>
97 =head1 SEE ALSO
99 L<collectd.conf(5)>,
100 L<collectd-email(5)>,
101 L<collectd-exec(5)>,
102 L<collectd-perl(5)>,
103 L<collectd-unixsock(5)>,
104 L<http://collectd.org/>
106 =head1 AUTHOR
108 Florian Forster E<lt>octo@verplant.orgE<gt>
110 =cut