=item B<PersistentConnection> B<true>|B<false>
-By default, the plugin will try to keep the connection to UPS open between
-reads. Since this appears to be somewhat brittle (I<apcupsd> appears to close
-the connection due to inactivity quite quickly), the plugin will try to detect
-this problem and switch to an open-read-close mode in such cases.
+The plugin is designed to keep the connection to I<apcupsd> open between reads.
+If plugin poll interval is greater than 15 seconds (hardcoded socket close
+timeout in I<apcupsd> NIS), then this option is B<false> by default.
You can instruct the plugin to close the connection after each read by setting
-this option to B<false>.
+this option to B<false> or force keeping the connection by setting it to B<true>.
+
+If I<apcupsd> appears to close the connection due to inactivity quite quickly,
+the plugin will try to detect this problem and switch to an open-read-close mode.
=back
=item B<Timeout> I<Seconds>
-Sets the timeout value for ldap operations. Defaults to B<-1> which results in
-an infinite timeout.
+Sets the timeout value for ldap operations, in seconds. By default, the
+configured B<Interval> is used to set the timeout. Use B<-1> to disable
+(infinite timeout).
=item B<Version> I<Version>
database definition. It accepts a single mandatory argument which specifies
the name of the query. The names of all queries have to be unique (see the
B<MinVersion> and B<MaxVersion> options below for an exception to this
-rule). The following configuration options are available to define the query:
+rule).
+
+In each B<Query> block, there is one or more B<Result> blocks. Multiple
+B<Result> blocks may be used to extract multiple values from a single query.
-In each B<Query> block, there is one or more B<Result> blocks. B<Result>
-blocks define how to handle the values returned from the query. They define
-which column holds which value and how to dispatch that value to the daemon.
-Multiple B<Result> blocks may be used to extract multiple values from a single
-query.
+The following configuration options are available to define the query:
=over 4
The returned lines will be handled separately one after another.
-=item B<Param> I<hostname>|I<database>|I<username>|I<interval>
+=item B<Param> I<hostname>|I<database>|I<instance>|I<username>|I<interval>
Specify the parameters which should be passed to the SQL query. The parameters
are referred to in the SQL query as B<$1>, B<$2>, etc. in the same order as
Please note that parameters are only supported by PostgreSQL's protocol
version 3 and above which was introduced in version 7.4 of PostgreSQL.
+=item B<MinVersion> I<version>
+
+=item B<MaxVersion> I<version>
+
+Specify the minimum or maximum version of PostgreSQL that this query should be
+used with. Some statistics might only be available with certain versions of
+PostgreSQL. This allows you to specify multiple queries with the same name but
+which apply to different versions, thus allowing you to use the same
+configuration in a heterogeneous environment.
+
+The I<version> has to be specified as the concatenation of the major, minor
+and patch-level versions, each represented as two-decimal-digit numbers. For
+example, version 8.2.3 will become 80203.
+
+=back
+
+The B<Result> block defines how to handle the values returned from the query.
+It defines which column holds which value and how to dispatch that value to
+the daemon.
+
+=over 4
+
=item B<Type> I<type>
The I<type> name to be used when dispatching the values. The type describes
details on types and their configuration. The number and type of values (as
selected by the B<ValuesFrom> option) has to match the type of the given name.
-This option is required inside a B<Result> block.
+This option is mandatory.
=item B<InstancePrefix> I<prefix>
times. If multiple B<ValuesFrom> options are specified, the columns are read
in the given order.
-=item B<MinVersion> I<version>
-
-=item B<MaxVersion> I<version>
-
-Specify the minimum or maximum version of PostgreSQL that this query should be
-used with. Some statistics might only be available with certain versions of
-PostgreSQL. This allows you to specify multiple queries with the same name but
-which apply to different versions, thus allowing you to use the same
-configuration in a heterogeneous environment.
-
-The I<version> has to be specified as the concatenation of the major, minor
-and patch-level versions, each represented as two-decimal-digit numbers. For
-example, version 8.2.3 will become 80203.
-
=back
The following predefined queries are available (the definitions can be found
(RSS), user- and system-time used, number of processes and number of threads,
io data (where available) and minor and major pagefaults.
+Some platforms have a limit on the length of process names. I<Name> must stay
+below this limit.
+
=item B<ProcessMatch> I<name> I<regex>
Similar to the B<Process> option this allows to select more detailed
I<true> the effect of B<Sensor> is inverted: All selected sensors are ignored
and all other sensors are collected.
+=item B<UseLabels> I<true>|I<false>
+
+Configures how sensor readings are reported. When set to I<true>, sensor
+readings are reported using their descriptive label (e.g. "VCore"). When set to
+I<false> (the default) the sensor name is used ("in0").
+
=back
=head2 Plugin C<sigrok>
=back
+=head2 Plugin C<xencpu>
+
+This plugin collects metrics of hardware CPU load for machine running Xen
+hypervisor. Load is calculated from 'idle time' value, provided by Xen.
+Result is reported using the C<percent> type, for each CPU (core).
+
+This plugin doesn't have any options (yet).
+
=head2 Plugin C<zookeeper>
The I<zookeeper plugin> will collect statistics from a I<Zookeeper> server
projects / collectd.git / blobdiff