=head1 SYNOPSIS
- BaseDir "/path/to/data/"
- PIDFile "/path/to/pidfile/collectd.pid"
- Server "123.123.123.123" 12345
+ BaseDir "/var/lib/collectd"
+ PIDFile "/run/collectd.pid"
+ Interval 10.0
LoadPlugin cpu
LoadPlugin load
<LoadPlugin df>
Interval 3600
</LoadPlugin>
+ <Plugin df>
+ ValuesPercentage true
+ </Plugin>
LoadPlugin ping
<Plugin ping>
This config file controls how the system statistics collection daemon
B<collectd> behaves. The most significant option is B<LoadPlugin>, which
controls which plugins to load. These plugins ultimately define collectd's
-behavior.
+behavior. If the B<AutoLoadPlugin> option has been enabled, the explicit
+B<LoadPlugin> lines may be omitted for all plugins with a configuration block,
+i.e. a C<E<lt>PluginE<nbsp>...E<gt>> block.
The syntax of this config file is similar to the config file of the famous
I<Apache> webserver. Each line contains either an option (a key and a list of
The configuration is read and processed in order, i.e. from top to bottom. So
the plugins are loaded in the order listed in this config file. It is a good
idea to load any logging plugins first in order to catch messages from plugins
-during configuration. Also, the C<LoadPlugin> option B<must> occur B<before>
-the appropriate C<E<lt>Plugin ...E<gt>> block.
+during configuration. Also, unless B<AutoLoadPlugin> is enabled, the
+B<LoadPlugin> option I<must> occur I<before> the appropriate
+C<E<lt>B<Plugin> ...E<gt>> block.
=head1 GLOBAL OPTIONS
# StoreRates false
# GraphitePrefix "collectd."
# GraphiteEscapeChar "_"
+ # GraphiteSeparateInstances false
+ # GraphiteAlwaysAppendDS false
</Publish>
# Receive values from an AMQP broker
metric parts (host, plugin, type).
Default is "_" (I<Underscore>).
+=item B<GraphiteSeparateInstances> B<true>|B<false>
+
+If set to B<true>, the plugin instance and type instance will be in their own
+path component, for example C<host.cpu.0.cpu.idle>. If set to B<false> (the
+default), the plugin and plugin instance (and likewise the type and type
+instance) are put into one component, for example C<host.cpu-0.cpu-idle>.
+
+=item B<GraphiteAlwaysAppendDS> B<true>|B<false>
+
+If set to B<true>, append the name of the I<Data Source> (DS) to the "metric"
+identifier. If set to B<false> (the default), this is only done when there is
+more than one DS.
+
=back
=head2 Plugin C<apache>
=back
+=head2 Plugin C<aquaero>
+
+This plugin collects the value of the available sensors in an
+I<AquaeroE<nbsp>5> board. AquaeroE<nbsp>5 is a water-cooling controller board,
+manufactured by Aqua Computer GmbH L<http://www.aquacomputer.de/>, with a USB2
+connection for monitoring and configuration. The board can handle multiple
+temperature sensors, fans, water pumps and water level sensors and adjust the
+output settings such as fan voltage or power used by the water pump based on
+the available inputs using a configurable controller included in the board.
+This plugin collects all the available inputs as well as some of the output
+values chosen by this controller. The plugin is based on the I<libaquaero5>
+library provided by I<aquatools-ng>.
+
+=over 4
+
+=item B<Device> I<DevicePath>
+
+Device path of the AquaeroE<nbsp>5's USB HID (human interface device), usually
+in the form C</dev/usb/hiddevX>. If this option is no set the plugin will try
+to auto-detect the Aquaero 5 USB device based on vendor-ID and product-ID.
+
+=back
+
=head2 Plugin C<ascent>
This plugin collects information about an Ascent server, a free server for the
=head2 Plugin C<curl_json>
-The B<curl_json plugin> uses B<libcurl> (L<http://curl.haxx.se/>) and
-B<libyajl> (L<http://www.lloydforge.org/projects/yajl/>) to retrieve JSON data
-via cURL. This can be used to collect values from CouchDB documents (which are
-stored JSON notation), for example.
+The B<curl_json plugin> collects values from JSON data to be parsed by
+B<libyajl> (L<http://www.lloydforge.org/projects/yajl/>) retrieved via
+either B<libcurl> (L<http://curl.haxx.se/>) or read directly from a
+unix socket. The former can be used, for example, to collect values
+from CouchDB documents (which are stored JSON notation), and the
+latter to collect values from a uWSGI stats socket.
-The following example will collect several values from the built-in `_stats'
-runtime statistics module of CouchDB
+The following example will collect several values from the built-in
+C<_stats> runtime statistics module of I<CouchDB>
(L<http://wiki.apache.org/couchdb/Runtime_Statistics>).
<Plugin curl_json>
</URL>
</Plugin>
-In the B<Plugin> block, there may be one or more B<URL> blocks, each defining
-a URL to be fetched via HTTP (using libcurl) and one or more B<Key> blocks.
-The B<Key> string argument must be in a path format, which is used to collect a
-value from a JSON map object. If a path element of B<Key> is the
-I<*>E<nbsp>wildcard, the values for all keys will be collectd.
+This example will collect data directly from a I<uWSGI> "Stats Server" socket.
+
+ <Plugin curl_json>
+ <Sock "/var/run/uwsgi.stats.sock">
+ Instance "uwsgi"
+ <Key "workers/*/requests">
+ Type "http_requests"
+ </Key>
+
+ <Key "workers/*/apps/*/requests">
+ Type "http_requests"
+ </Key>
+ </Sock>
+ </Plugin>
+
+In the B<Plugin> block, there may be one or more B<URL> blocks, each
+defining a URL to be fetched via HTTP (using libcurl) or B<Sock>
+blocks defining a unix socket to read JSON from directly. Each of
+these blocks may have one or more B<Key> blocks.
+
+The B<Key> string argument must be in a path format. Each component is
+used to match the key from a JSON map or the index of an JSON
+array. If a path component of a B<Key> is a I<*>E<nbsp>wildcard, the
+values for all map keys or array indices will be collectd.
The following options are valid within B<URL> blocks:
other plugins, its documentation has been moved to an own manpage,
L<collectd-snmp(5)>. Please see there for details.
+=head2 Plugin C<statsd>
+
+The I<statsd plugin> listens to a UDP socket, reads "events" in the statsd
+protocol and dispatches rates or other aggregates of these numbers
+periodically.
+
+The plugin implements the I<Counter>, I<Timer>, I<Gauge> and I<Set> types which
+are dispatched as the I<collectd> types C<derive>, C<latency>, C<gauge> and
+C<objects> respectively.
+
+The following configuration options are valid:
+
+=over 4
+
+=item B<Host> I<Host>
+
+Bind to the hostname / address I<Host>. By default, the plugin will bind to the
+"any" address, i.e. accept packets sent to any of the hosts addresses.
+
+=item B<Port> I<Port>
+
+UDP port to listen to. This can be either a service name or a port number.
+Defaults to C<8125>.
+
+=item B<DeleteCounters> B<false>|B<true>
+
+=item B<DeleteTimers> B<false>|B<true>
+
+=item B<DeleteGauges> B<false>|B<true>
+
+=item B<DeleteSets> B<false>|B<true>
+
+These options control what happens if metrics are not updated in an interval.
+If set to B<False>, the default, metrics are dispatched unchanged, i.e. the
+rate of counters and size of sets will be zero, timers report C<NaN> and gauges
+are unchanged. If set to B<True>, the such metrics are not dispatched and
+removed from the internal cache.
+
+=item B<TimerPercentile> I<Percent>
+
+Calculate and dispatch the configured percentile, i.e. compute the latency, so
+that I<Percent> of all reported timers are smaller than or equal to the
+computed latency. This is useful for cutting off the long tail latency, as it's
+often done in I<Service Level Agreements> (SLAs).
+
+If not specified, no percentile is calculated / dispatched.
+
+=back
+
=head2 Plugin C<swap>
The I<Swap plugin> collects information about used and available swap space. On
<Node "example">
Host "localhost"
Port "2003"
- Protocol "udp"
+ Protocol "tcp"
LogSendErrors true
Prefix "collectd"
</Node>
=item B<AlwaysAppendDS> B<false>|B<true>
-If set the B<true>, append the name of the I<Data Source> (DS) to the "metric"
+If set to B<true>, append the name of the I<Data Source> (DS) to the "metric"
identifier. If set to B<false> (the default), this is only done when there is
more than one DS.
Here is a configuration example to get you started. Read below for more
information.
- <Threshold>
+ <Plugin threshold>
<Type "foo">
WarningMin 0.00
WarningMax 1000.00
</Type>
</Plugin>
</Host>
- </Threshold>
+ </Plugin>
There are basically two types of configuration statements: The C<Host>,
C<Plugin>, and C<Type> blocks select the value for which a threshold should be
=item B<Plugin> I<Name>
Name of the write plugin to which the data should be sent. This option may be
-given multiple times to send the data to more than one write plugin.
+given multiple times to send the data to more than one write plugin. If the
+plugin supports multiple instances, the plugin's instance(s) must also be
+specified.
=back
If no plugin is explicitly specified, the values will be sent to all available
write plugins.
-Example:
+Single-instance plugin example:
<Target "write">
Plugin "rrdtool"
</Target>
+Multi-instance plugin example:
+
+ <Plugin "write_graphite">
+ <Node "foo">
+ ...
+ </Node>
+ <Node "bar">
+ ...
+ </Node>
+ </Plugin>
+ ...
+ <Target "write">
+ Plugin "write_graphite/foo"
+ </Target>
+
=item B<jump>
Starts processing the rules of another chain, see L<"Flow control"> above. If
projects / collectd.git / blobdiff