collectd.conf(5): Documented the `iptables', `logfile', `processes', `syslog', and...
[collectd.git] / src / collectd.conf.pod
index 5cedace..6d42f07 100644 (file)
@@ -6,7 +6,6 @@ collectd.conf - Configuration for the system statistics collection daemon B<coll
 
   BaseDir "/path/to/data/"
   PIDFile "/path/to/pidfile/collectd.pid"
-  LogFile "/path/to/logfile/collectd.log"
   Server  "123.123.123.123" 12345
 
   LoadPlugin cpu
@@ -54,10 +53,11 @@ Sets where to write the PID file to. This file is overwritten when it exists
 and deleted when the program ist stopped. Some init-scripts might override this
 setting using the B<-P> commandline option.
 
-=item B<LogFile> I<File>
+=item B<Interval> I<Seconds>
 
-Sets the file to write debugging output to. This is only used if compiled with
-debugging enabled. It's ignored otherwise.
+Configures the interval in which to query the read plugins. Obviously smaller
+values lead to a higher system load produces by collectd, while higher values
+lead to more coarse statistics.
 
 =back
 
@@ -80,6 +80,10 @@ the following snipped to base your Apache config upon:
     </Location>
   </IfModule>
 
+Since it's C<mod_status> module is very similar to Apache's, B<lighttpd> is
+also supported. It introduces a new field, called C<BusyServers>, to count the
+number of currently connected clients. This field is also supported.
+
 The following options are accepted by the C<apache>-plugin:
 
 =over 4
@@ -122,6 +126,17 @@ TCP-Port to connect to. Defaults to B<3551>.
 
 =back
 
+=head2 Plugin C<csv>
+
+=over 4
+
+=item B<DataDir> I<Directory>
+
+Set the directory to store RRD-files under. Per default RRD-files are generated
+beneath the daemon's working directory, i.E<nbsp>e. the B<BaseDir>.
+
+=back
+
 =head2 Plugin C<df>
 
 =over 4
@@ -202,6 +217,86 @@ TCP-Port to connect to. Defaults to B<7634>.
 
 =back
 
+=head2 Plugin C<interface>
+
+=over 4
+
+=item B<Interface> I<Interface>
+
+Select this interface. By default these interfaces will then be collected. For
+a more detailed description see B<IgnoreSelected> below.
+
+=item B<IgnoreSelected> I<true>|I<false>
+
+If no configuration if given, the B<traffic>-plugin will collect data from
+all interfaces. This may not be practical, especially for loopback- and
+similar interfaces. Thus, you can use the B<Interface>-option to pick the
+interfaces you're interested in. Sometimes, however, it's easier/prefered
+to collect all interfaces I<except> a few ones. This option enables you to
+do that: By setting B<IgnoreSelected> to I<true> the effect of
+B<Interface> is inversed: All selected interfaces are ignored and all
+other interfaces are collected.
+
+=back
+
+=head2 Plugin C<iptables>
+
+=over 4
+
+=item B<Chain> I<Table> I<Chain> [I<Comment|Number> [I<Name>]]
+
+Select the rules to count. If only I<Table> and I<Chain> are given, this plugin
+will collect the counters of all rules which have a comment-match. The comment
+is then used as type-instance.
+
+If I<Comment> or I<Number> is given, only the rule with the matching comment or
+the I<n>th rule will be collected. Again, the comment (or the number) will be
+used as the type-instance.
+
+If I<Name> is supplied, it will be used as the type-instance instead of the
+comment or the number.
+
+=back
+
+=head2 Plugin C<irq>
+
+=over 4
+
+=item B<Irq> I<Irq>
+
+Select this irq. By default these irqs will then be collected. For a more
+detailed description see B<IgnoreSelected> below.
+
+=item B<IgnoreSelected> I<true>|I<false>
+
+If no configuration if given, the B<irq>-plugin will collect data from all
+irqs. This may not be practical, especially if no interrupts happen. Thus, you
+can use the B<Irq>-option to pick the interupt you're interested in.
+Sometimes, however, it's easier/prefered to collect all interupts I<except> a
+few ones. This option enables you to do that: By setting B<IgnoreSelected> to
+I<true> the effect of B<Irq> is inversed: All selected interupts are ignored
+and all other interupts are collected.
+
+=back
+
+=head2 Plugin C<logfile>
+
+=over 4
+
+=item B<LogLevel> B<debug|info|notice|warning|err>
+
+Sets the log-level. If, for example, set to B<notice>, then all events with
+severity B<notice>, B<warning>, or B<err> will be written to the logfile.
+
+=item B<File> I<File>
+
+Sets the file to write log messages to. The special strings B<stdout> and
+B<stderr> can be used to write to the standard output and standard error
+channels, respectively. This, of course, only makes much sense when collectd is
+running in foreground- or non-daemon-mode.
+
+=back
+
 =head2 Plugin C<mbmon>
 
 =over 4
@@ -306,23 +401,85 @@ Sets the Time-To-Live of generated ICMP packets.
 
 =back
 
-=head2 Plugin C<rrdtool>
+=head2 Plugin C<processes>
 
 =over 4
 
-=item B<CacheTimeout> I<Seconds>
+=item B<Process> I<Name>
+
+Select more detailed statistics of processes matching this name. The statistics
+collected for these selected processes are size of the resident segment size
+(RSS), user- and system-time used, number of processes and number of threads,
+and minor and major pagefaults.
 
-If this option is set to a value greater than zero, the C<rrdtool>-plugin will
-write values every I<Seconds> seconds to the RRD-files. Writing multiple values
-at once reduces IO-operations and thus lessens the load produced by updating
-the files. The tradeoff is that the graphs kind of "drag behind" and that more
-memory is used.
+=back
+
+=head2 Plugin C<rrdtool>
+
+You can use the settings B<StepSize>, B<HeartBeat>, B<RRARows>, and B<XFF> to
+finetune your RRD-files. Please read L<rrdcreate(1)> if you encounter problems
+using these settings. If you don't want to dive into the depths of RRDTool, you
+can savely ignore these settings.
+
+=over 4
 
 =item B<DataDir> I<Directory>
 
-Set the directory to store RRD-files under. Per default RRD-files are generated
+Set the directory to store CSV-files under. Per default CSV-files are generated
 beneath the daemon's working directory, i.E<nbsp>e. the B<BaseDir>.
 
+=item B<StepSize> I<Seconds>
+
+Sets the stepsize of newly created RRD-files. Ideally (and per default) this
+setting is identical to the global B<Interval>-option and should not be
+smaller. If unsure, don't set this option.
+
+=item B<HeartBeat> I<Seconds>
+
+Sets the heartbeat of newly created RRD-files. Ideally this setting is bigger
+than the B<Interval>-setting, by default it's twice the B<Interval>-setting. If
+unsure, don't set this option.
+
+=item B<RRARows> I<NumRows>
+
+The C<rrdtool plugin> calculates the number of PDPs per CDP based on the
+B<StepSize>, this setting and a timespan. This plugin creates RRD-files with
+three times five RRAs, i. e. five RRAs with the CFs B<MIN>, B<AVERAGE>, and
+B<MAX>. The five RRAs are optimized for graphs covering one hour, one day, one
+week, one month, and one year.
+
+So for each timespan, it calculates how many PDPs need to be consolidated into
+one CDP by calculating:
+  number of PDPs = timespan / (stepsize * rrarows)
+
+Bottom line is, set this no smaller than the width of you graphs in pixels. The
+default is 1200.
+
+=item B<XFF> I<Factor>
+
+Set the "XFiles Factor". The default is 0.1. If unsure, don't set this option.
+
+=item B<CacheFlush> I<Seconds>
+
+When the C<rrdtool plugin> uses a cache (by setting B<CacheTimeout>, see below)
+it writes all values for a certain RRD-file if the oldest value is older than
+(or equal to) the number of seconds specified. If some RRD-file is not updated
+anymore for some reason (the computer was shut down, the network is broken,
+etc.) some values may still be in the cache. If B<CacheFlush> is set, then the
+entire cache is searched for entries older than B<CacheTimeout> seconds and
+written to disk every I<Seconds> seconds. Since this is kind of expensive and
+does nothing under normal circumstances, this value should not be too small.
+900 seconds might be a good value, though setting this to 7200 seconds doesn't
+normally do much harm either.
+
+=item B<CacheTimeout> I<Seconds>
+
+If this option is set to a value greater than zero, the C<rrdtool plugin> will
+save values in a cache, as described above. Writing multiple values at once
+reduces IO-operations and thus lessens the load produced by updating the files.
+The tradeoff is that the graphs kind of "drag behind" and that more memory is
+used.
+
 =back
 
 =head2 Plugin C<sensors>
@@ -348,24 +505,36 @@ and all other sensors are collected.
 
 =back
 
-=head2 Plugin C<traffic>
+=head2 Plugin C<syslog>
 
 =over 4
 
-=item B<Interface> I<Interface>
+=item B<LogLevel> B<debug|info|notice|warning|err>
 
-Select this interface. By default these interfaces will then be collected. For a more detailed description see B<IgnoreSelected> below.
+Sets the log-level. If, for example, set to B<notice>, then all events with
+severity B<notice>, B<warning>, or B<err> will be submitted to the
+syslog-daemon.
 
-=item B<IgnoreSelected> I<true>|I<false>
+=back
 
-If no configuration if given, the B<traffic>-plugin will collect data from
-all interfaces. This may not be practical, especially for loopback- and
-similar interfaces. Thus, you can use the B<Interface>-option to pick the
-interfaces you're interested in. Sometimes, however, it's easier/prefered
-to collect all interfaces I<except> a few ones. This option enables you to
-do that: By setting B<IgnoreSelected> to I<true> the effect of
-B<Interface> is inversed: All selected interfaces are ignored and all
-other interfaces are collected.
+=head2 Plugin C<unixsock>
+
+=over 4
+
+=item B<SocketFile> I<Path>
+
+Sets the socket-file which is to be created.
+
+=item B<SocketGroup> I<Group>
+
+If running as root change the group of the UNIX-socket after it has been 
+created. Defaults to B<collectd>.
+
+=item B<SocketPerms> I<Permissions>
+
+Change the file permissions of the UNIX-socket after it has been created. The
+permissions must be given as a numeric, octal value as you would pass to
+L<chmod(1)>. Defaults to B<0770>.
 
 =back