src/collectd.pod

   1 =encoding UTF-8
   2
   3 =head1 NAME
   4
   5 collectd - System statistics collection daemon
   6
   7 =head1 SYNOPSIS
   8
   9 collectd I<[options]>
  10
  11 =head1 DESCRIPTION
  12
  13 collectd is a daemon that receives system statistics and makes them available
  14 in a number of ways. The main daemon itself doesn't have any real functionality
  15 apart from loading, querying and submitting to plugins. For a description of
  16 available plugins please see L</PLUGINS> below.
  17
  18 =head1 OPTIONS
  19
  20 Most of collectd's configuration is done using using a configfile. See
  21 L<collectd.conf(5)> for an in-depth description of all options.
  22
  23 =over 4
  24
  25 =item B<-C> I<E<lt>config-fileE<gt>>
  26
  27 Specify an alternative config file. This is the place to go when you wish to
  28 change B<collectd>'s behavior. The path may be relative to the current working
  29 directory.
  30
  31 =item B<-t>
  32
  33 Test the configuration only. The program immediately exits after parsing the
  34 config file. A return code not equal to zero indicates an error.
  35
  36 =item B<-T>
  37
  38 Test the plugin read callbacks only. The program immediately exits after invoking
  39 the read callbacks once. A return code not equal to zero indicates an error.
  40
  41 =item B<-P> I<E<lt>pid-fileE<gt>>
  42
  43 Specify an alternative pid file. This overwrites any settings in the config
  44 file. This is thought for init-scripts that require the PID-file in a certain
  45 directory to work correctly. For everyday-usage use the B<PIDFile>
  46 config-option.
  47
  48 =item B<-f>
  49
  50 Don't fork to the background. I<collectd> will also B<not> close standard file
  51 descriptors, detach from the session nor write a pid file. This is mainly
  52 thought for 'supervising' init replacements such as I<runit>. If using
  53 I<upstart> or I<systemd> though, starting with version 5.5.0 I<collectd> is
  54 able to notify these two init replacements, and B<does> require forking to the
  55 background for process supervision. The F<contrib/> directory has sample
  56 I<upstart> and I<systemd> configuration files.
  57
  58 =item B<-h>
  59
  60 Output usage information and exit.
  61
  62 =back
  63
  64 =head1 PLUGINS
  65
  66 As noted above, the real power of collectd lies within it's plugins. A
  67 (hopefully complete) list of plugins and short descriptions can be found in the
  68 F<README> file that is distributed with the sourcecode. If you're using a
  69 package it's a good bet to search somewhere near F</usr/share/doc/collectd>.
  70
  71 There are two big groups of plugins, B<input> and B<output> plugins:
  72
  73 =over 4
  74
  75 =item *
  76
  77 Input plugins are queried periodically. They somehow acquire the current value
  78 of whatever they where designed to work with and submit these values back to
  79 the daemon, i. e. they "dispatch" the values. As an example, the C<cpu plugin>
  80 reads the current cpu-counters of time spent in the various modes (user,
  81 system, nice, ...) and dispatches these counters to the daemon.
  82
  83 =item *
  84
  85 Output plugins get the dispatched values from the daemon and does something
  86 with them. Common applications are writing to RRD-files, CSV-files or sending
  87 the data over a network link to a remote box.
  88
  89 =back
  90
  91 Of course not all plugins fit neatly into one of the two above categories. The
  92 C<network plugin>, for example, is able to send (i.E<nbsp>e. "write") B<and>
  93 receive (i.E<nbsp>e. "dispatch") values. Also, it opens a socket upon
  94 initialization and dispatches the values when it receives them and isn't
  95 triggered at the same time the input plugins are being read. You can think of
  96 the network receive part as working asynchronous if it helps.
  97
  98 In addition to the above, there are "logging plugins". Right now those are the
  99 C<logfile plugin> and the C<syslog plugin>. With these plugins collectd can
 100 provide information about issues and significant situations to the user.
 101 Several loglevels let you suppress uninteresting messages.
 102
 103 Starting with version C<4.3.0> collectd has support for B<monitoring>. This is
 104 done by checking thresholds defined by the user. If a value is out of range, a
 105 notification will be dispatched to "notification plugins". See
 106 L<collectd.conf(5)> for more detailed information about threshold checking.
 107
 108 Please note that some plugins, that provide other means of communicating with
 109 the daemon, have manpages of their own to describe their functionality in more
 110 detail. In particular those are L<collectd-email(5)>, L<collectd-exec(5)>,
 111 L<collectd-perl(5)>, L<collectd-snmp(5)>, and L<collectd-unixsock(5)>
 112
 113 =head1 SIGNALS
 114
 115 B<collectd> accepts the following signals:
 116
 117 =over 4
 118
 119 =item B<SIGINT>, B<SIGTERM>
 120
 121 These signals cause B<collectd> to shut down all plugins and terminate.
 122
 123 =item B<SIGUSR1>
 124
 125 This signal causes B<collectd> to signal all plugins to flush data from
 126 internal caches. E.E<nbsp>g. the C<rrdtool plugin> will write all pending data
 127 to the RRD files. This is the same as using the C<FLUSH -1> command of the
 128 C<unixsock plugin>.
 129
 130 =back
 131
 132 =head1 SEE ALSO
 133
 134 L<collectd.conf(5)>,
 135 L<collectd-email(5)>,
 136 L<collectd-exec(5)>,
 137 L<collectd-perl(5)>,
 138 L<collectd-snmp(5)>,
 139 L<collectd-unixsock(5)>,
 140 L<types.db(5)>,
 141 L<http://collectd.org/>
 142
 143 =head1 AUTHOR
 144
 145 Florian Forster E<lt>octo@collectd.orgE<gt>
 146
 147 =cut