solaris-fixes branch: Applied the swap-patch by Christophe Kalt.
[collectd.git] / src / collectd.pod
index 4df62fa..488fbe2 100644 (file)
@@ -16,10 +16,26 @@ settings. The following features may be available:
 
 =item
 
+Apache server stats (I<apache>)
+
+=item
+
+Apple hardware sensors (I<apple_sensors>, Darwin only)
+
+=item
+
+Battery status (I<battery>)
+
+=item
+
 CPU utilization (I<cpu>)
 
 =item
 
+Mountpoint usage (I<df>)
+
+=item
+
 Disk and partition usage/throughput (I<disk>)
 
 =item
@@ -36,6 +52,10 @@ Memory usage (I<memory>)
 
 =item
 
+MySQL statistics (I<mysql>)
+
+=item
+
 NFS utilization (I<nfs>, Linux only)
 
 =item
@@ -70,27 +90,25 @@ Network traffic (I<traffic>)
 
 Number of users logged into the system (I<users>)
 
-=back
+=item
 
-=head1 OPTIONS
+System ressources used by VServers (I<vserver>)
 
-=over 4
+=item
 
-=item B<-l>
+Wireless network stats (I<wireless>)
 
-Start in local mode. This is the default. No data will be sent or read to/from
-the network. Information will be read and written by the same process. See
-L<"MODES">.
+=back
 
-=item B<-c>
+=head1 OPTIONS
 
-Start in client (transmitter) mode. Data will be sent to the multicast group.
-See L<"MODES">.
+=over 4
 
-=item B<-s>
+=item B<-C> I<E<lt>config-fileE<gt>>
 
-Start in server (receiver) mode. Data sent to the multicast group will be read
-and stored in RRD files. See L<"MODES">.
+Specify an alternative config file. This is the place to go when you wish to
+change B<collectd>'s behavior. The path may be relative to the current working
+directory.
 
 =item B<-f>
 
@@ -98,59 +116,154 @@ Don't fork to the background. I<collectd> will also B<not> close standard file
 descriptors, detach from the session nor write a pid file. This is mainly
 thought for 'supervisioning' init replacements such as I<runit>.
 
-=item B<-D> I<E<lt>directoryE<gt>>
+=item B<-h>
+
+Output usage information and exit.
+
+=back
 
-Sets the directory collectd should work in. All F<.rrd>-files are created in
-this directory. Per default this is F</var/lib/collectd/>.
+=head1 MODES
 
-=item B<-M> I<E<lt>directoryE<gt>>
+collectd can operate in three different operating modes. The modes are
+described below.
 
-Sets the directory collectd should look for plugins in. Per default this is
-F</usr/lib/collectd>.
+The simplest mode is the so called B<local mode>. Data is collected locally and
+written in RRD files that reside in I<DataDir>. This is the default mode when
+collectd is linked against C<librrd>.
 
-=item B<-P> I<E<lt>fileE<gt>>
+The other modes, B<client mode> and B<server mode>, are used to send data over
+a network and receive it again.
 
-Sets the PID-file.
+In B<client mode> the daemon collects the data locally and sends its results
+to one or more network addresses. No RRD files are written in this case. This
+is the only mode available if collectd is not linked against C<librrd>.
 
-=item B<-h>
+If started in B<server mode> the daemon will listen on one or more interfaces
+and write the data it receives to RRD files. No data is collected locally.
 
-Output usage information and exit.
+In the last mode, B<log mode>, data is collected locally and written in
+text files that reside in I<DataDir>.
 
-=item B<-p> I<E<lt>hostE<gt>>
+Please refer to L<collectd.conf(5)> for the configuration options and default
+values.
 
-Sets the host to ping periodically. This option may be given more than once to
-ping multiple hosts. If this option is not given at least once no host will be
-pinged.
+=head1 SPECIAL PLUGINS
 
-=back
+=head2 apache
 
-=head1 RRD FILES
+This module connects to an Apache webserver and expects the output produced by
+B<mod_status.c>. If requires B<libcurl> to set up the HTTP connection and issue
+the request(s). The following is a sample config for the Apache webserver. The
+use of C<ExtendedStatus on> is mandatory.
+
+  ExtendedStatus on
+  <IfModule mod_status.c>
+    <Location /mod_status>
+      SetHandler server-status
+    </Location>
+  </IfModule>
+
+This plugin requires further configuration. Please read L<collectd.conf(5)>.
+
+=head2 cpufreq
+
+This module reads F</sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq> (for
+the first CPU installed) to get the current CPU frequency. If this file does
+not exist make sure B<cpufreqd> (L<http://cpufreqd.sourceforge.net/>) or a
+similar tool is installed and an "cpu governor" (that's kernel module) is
+loaded.
+
+=head2 mysql
+
+Requires B<mysqlclient> to be installed. It connects to the database when
+started and keeps the connection up as long as possible. When the connection is
+interrupted for whatever reason it will try to re-connect. The syslog will
+contain loud complaints in case anything goes wrong.
+
+This plugin issues C<SHOW STATUS> and evaluates C<Bytes_{received,sent}>,
+C<Com_*> and C<Handler_*> which correspond to F<traffic-mysql.rrd>,
+F<mysql_commands-*.rrd> and F<mysql_handler-*.rrd>. Also, the values of
+C<Qcache_*> are put in F<mysql_qcache.rrd> and values of C<Threads_*> are put
+in F<mysql_threads.rrd>. Please refer to the B<MySQL reference manual>,
+I<5.2.4. Server Status Variables> for an explanation of these values.
+
+=head2 sensors
+
+The B<sensors> module uses lm_sensors to retrieve sensor-values. This means
+that all the needed modules have to be loaded and lm_sensors has to be
+configured (most likely by editing F</etc/sensors.conf>. Read
+L<sensors.conf(5)> for details.
+
+The B<lm_sensors> homepage can be found at
+L<http://secure.netroedge.com/~lm78/>.
+
+=head2 hddtemp
 
-The RRD files are created automatically with the following RRAs:
+To get values from B<hddtemp> collectd connects to B<localhost> (127.0.0.1),
+port B<7634/tcp>. The B<Host> and B<Port> options can be used to change these
+default values. See L<collectd.conf(5)> for details. C<hddtemp> has to be
+running to work correctly. If C<hddtemp> is not running timeouts may appear
+which may interfere with other statistics..
+
+The B<hddtemp> homepage can be found at
+L<http://www.guzu.net/linux/hddtemp.php>.
 
-  RRA:AVERAGE:0.2:6:1500
-  RRA:AVERAGE:0.1:180:1680
-  RRA:AVERAGE:0.1:2160:1520
-  RRA:MIN:0.2:6:1500
-  RRA:MIN:0.1:180:1680
-  RRA:MIN:0.1:2160:1520
-  RRA:MAX:0.2:6:1500
-  RRA:MAX:0.1:180:1680
-  RRA:MAX:0.1:2160:1520
+=head2 vserver
 
-Since collectd uses a 10 second I<step> the RRAs contain the following
-timespans:
+B<VServer> support is only available for Linux. It cannot yet be found in a 
+vanilla kernel, though. To make use of this plugin you need a kernel that has 
+B<VServer> support built in, i.e. you need to apply the patches and compile 
+your own kernel, which will then provide the /proc/virtual filesystem that is
+required by this plugin.
 
-  Resolution | Data points |  Timespan
-  -----------+-------------+----------
-  60 seconds |        1500 |  25 hours
-  30 minutes |        1680 |  35 days
-   6 hours   |        1520 | 380 days
+The B<VServer> homepage can be found at L<http://linux-vserver.org/>.
+
+=head1 RRD FILES
+
+The RRD files are created automatically. The size of the RRAs depend on the
+compile time settings of I<step> and I<width>. With the default values (I<step>
+= B<10>, I<width> = B<1200>) the following RRAs are created:
+
+  RRA:AVERAGE:0.1:1:8640
+  RRA:AVERAGE:0.1:50:1210
+  RRA:AVERAGE:0.1:223:1202
+  RRA:AVERAGE:0.1:2635:1201
+  RRA:MIN:0.1:1:8640
+  RRA:MIN:0.1:50:1210
+  RRA:MIN:0.1:223:1202
+  RRA:MIN:0.1:2635:1201
+  RRA:MAX:0.1:1:8640
+  RRA:MAX:0.1:50:1210
+  RRA:MAX:0.1:223:1202
+  RRA:MAX:0.1:2635:1201
+
+By default collectd uses a 10 second I<step>. Thus the RRAs contain the
+following timespans. If you've changed the I<step> at compile time you will
+have calculate resolution and timespan yourself.
+
+  PDP per CDP |  Resolution  | Data points | Timespan
+  ------------+--------------+-------------+---------
+            1 | 10.0 seconds !        8640 ! 1 day
+           50 |  8.3 minutes |        1210 | 1 week
+          223 | 37.2 minutes |        1202 | 1 month
+         2635 |  7.3 hours   |        1201 | 1 year
 
 The DS'es depend on the module creating the RRD files:
 
 =over 4
 
+=item Battery charge (F<battery-I<E<lt>nameE<gt>>/charge.rrd>)
+
+  DS:charge:GAUGE:25:0:U
+
+=item Battery current (F<battery-I<E<lt>nameE<gt>>/current.rrd>)
+
+  DS:current:GAUGE:25:U:U
+
+=item Battery voltage (F<battery-I<E<lt>nameE<gt>>/voltage.rrd>)
+
+  DS:voltage:GAUGE:25:U:U
+
 =item CPU (F<cpu-I<E<lt>numE<gt>>.rrd>)
 
   DS:user:COUNTER:25:0:100
@@ -159,6 +272,11 @@ The DS'es depend on the module creating the RRD files:
   DS:idle:COUNTER:25:0:100
   DS:wait:COUNTER:25:0:100
 
+=item Mountpoints (F<df-I<E<lt>pathE<gt>>.rrd>)
+
+  DS:used:GAUGE:25:0:U
+  DS:free:GAUGE:25:0:U
+
 =item Diskstats (F<disk-I<E<lt>majorE<gt>>-I<E<lt>minorE<gt>>.rrd>)
 
   DS:rcount:COUNTER:25:0:U
@@ -194,6 +312,25 @@ The DS'es depend on the module creating the RRD files:
   DS:buffers:GAUGE:25:0:9223372036854775807
   DS:cached:GAUGE:25:0:9223372036854775807
 
+=item MySQL commands and handlers (F<mysql_commands-I<E<lt>commandE<gt>>.rrd> and F<mysql_handler-I<E<lt>handlerE<gt>>.rrd>)
+
+  DS:value:COUNTER:25:0:U
+
+=item MySQL query cache (F<mysql_qcache.rrd>)
+
+  DS:hits:COUNTER:25:0:U
+  DS:inserts:COUNTER:25:0:U
+  DS:not_cached:COUNTER:25:0:U
+  DS:lowmem_prunes:COUNTER:25:0:U
+  DS:queries_in_cache:GAUGE:25:0:U
+
+=item MySQL threads (F<mysql_threads.rrd>)
+
+  DS:running:GAUGE:25:0:U
+  DS:connected:GAUGE:25:0:U
+  DS:cached:GAUGE:25:0:U
+  DS:created:COUNTER:25:0:U
+
 =item NFSv2 Procedures (F<nfs2_procedures-I<(client|server)>.rrd>)
 
   DS:null:COUNTER:25:0:U
@@ -289,72 +426,37 @@ The DS'es depend on the module creating the RRD files:
 
   DS:users:GAUGE:25:0:65535
 
-=back
-
-=head1 MODES
-
-By default collectd starts in the so called I<local mode> which is not very
-interesting. It collects data and writes it into RRD files in
-F</var/lib/collectd>. There's nothing special so I won't discuss that in more
-detail..
-
-Please be aware that B<client-, local- and server-mode are mutual exclusive>. A
-later declaration overrides earlier ones. I<collectd -l -c -s> will start in
-server-mode. If you want statistics of the server too you will have to start a
-client process as well.
-
-Starting with version 3 collectd may send data over a network. As common with
-network stuff there are two modes: A I<sender> and a I<listener>. Since one
-usually has many senders and only a few listeners the sender is also called
-I<client> (using the option B<-c>) and the listener is called I<server> (using
-the option B<-s>).
-
-Communication happends using the (IPv4) multicast group B<239.192.74.66> and
-packets sent to the port B<25826/udp>. Every ten seconds the I<client> queries
-all the modules and sends the collected data to the multicast group. The
-I<server> subscribes to the multicast group upon startup and then waits for
-incoming packets. As it receives the packets it checks wether it has the
-neccessary module and, if found, writes the data to an RRD file, creating
-directories and files as needed.
-
-The multicast group used is within the I<Organization Local Scope> as defined
-by L<RFC2365>. Addresses within that space are meant to be routed within an AS
-but not to the outside. However collectd cannot control this and won't try. So
-it's totally up to you to secure your net.
-
-The UDP port used has been checked to not be assigned by the IANA.
+=item VServer load (F<vserver-I<E<lt>xidE<gt>>/load.rrd>)
 
-On multi-homed machines you may need to add a route to the multicast net
-(B<224.0.0.0/4>) if multicast packages take the wrong interface. The listener
-on the other hand listens on B<all> interfaces.
+  DS:shortterm:GAUGE:25:0:100
+  DS:midterm:GAUGE:25:0:100
+  DS:longterm:GAUGE:25:0:100
 
-=head1 SPECIAL MODULES
+=item VServer threads (F<vserver-I<E<lt>xidE<gt>>/threads.rrd>)
 
-=head2 cpufreq
+  DS:total:GAUGE:25:0:65535
+  DS:running:GAUGE:25:0:65535
+  DS:uninterruptible:GAUGE:25:0:65535
+  DS:onhold:GAUGE:25:0:65535
 
-This module reads F</sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq> (for
-the first CPU installed) to get the current CPU frequency. If this file does
-not exist make sure B<cpufreqd> (L<http://cpufreqd.sourceforge.net/>) or a
-similar tool is installed.
+=item VServer network traffic (F<vserver-I<E<lt>xidE<gt>>/traffic-I<E<lt>nameE<gt>>.rrd>)
 
-=head2 sensors
+  DS:incoming:COUNTER:25:0:9223372036854775807
+  DS:outgoing:COUNTER:25:0:9223372036854775807
+  DS:failed:COUNTER:25:0:9223372036854775807
 
-The B<sensors> module uses lm_sensors to retrieve sensor-values. This means
-that all the needed modules have to be loaded and lm_sensors has to be
-configured (most likely by editing F</etc/sensors.conf>. Read
-L<sensors.conf(5)> for details.
+=item VServer processes (F<vserver-I<E<lt>xidE<gt>>/vs_processes.rrd>)
 
-The B<lm_sensors> homepage can be found at
-L<http://secure.netroedge.com/~lm78/>.
+  DS:total:GAUGE:25:0:65535
 
-=head2 hddtemp
+=item VServer memory usage (F<vserver-I<E<lt>xidE<gt>>/vs_memory.rrd>)
 
-To get values from B<hddtemp> collectd connects to B<localhost> (127.0.0.1),
-port B<7634/tcp>. hddtemp has to be running to work correctly. If hddtemp is
-not running timeouts may appear which may interfere with other statistics..
+  DS:vm:GAUGE:25:0:9223372036854775807
+  DS:vml:GAUGE:25:0:9223372036854775807
+  DS:rss:GAUGE:25:0:9223372036854775807
+  DS:anon:GAUGE:25:0:9223372036854775807
 
-The B<hddtemp> homepage can be found at
-L<http://www.guzu.net/linux/hddtemp.php>.
+=back
 
 =head1 SEE ALSO