If enabled, collectd will export all global symbols of the plugin (and of all
libraries loaded as dependencies of the plugin) and, thus, makes those symbols
available for resolving unresolved symbols in subsequently loaded plugins if
-that is supported by your system. By default, this is disabled.
+that is supported by your system.
-This is useful (or possibly even required), e.E<nbsp>g., when loading a plugin
-that embeds some scripting language into the daemon (e.E<nbsp>g. the C<perl>
-or C<python> plugins). Scripting languages usually provide means to load
+This is useful (or possibly even required), e.g., when loading a plugin that
+embeds some scripting language into the daemon (e.g. the I<Perl> and
+I<Python plugins>). Scripting languages usually provide means to load
extensions written in C. Those extensions require symbols provided by the
-interpreter, which is loaded as a dependency of the respective collectd
-plugin. See the documentation of those plugins (e.E<nbsp>g.,
-L<collectd-perl(5)> or L<collectd-python(5)>) for details.
+interpreter, which is loaded as a dependency of the respective collectd plugin.
+See the documentation of those plugins (e.g., L<collectd-perl(5)> or
+L<collectd-python(5)>) for details.
+
+By default, this is disabled. As a special exception, if the plugin name is
+either C<perl> or C<python>, the default is changed to enabled in order to keep
+the average user from ever having to deal with this low level linking stuff.
=back
values lead to a higher system load produced by collectd, while higher values
lead to more coarse statistics.
+B<Warning:> You should set this once and then never touch it again. If you do,
+I<you will have to delete all your RRD files> or know some serious RRDtool
+magic! (Assuming you're using the I<RRDtool> or I<RRDCacheD> plugin.)
+
=item B<Timeout> I<Iterations>
Consider a value list "missing" when no update has been read or received for
this setting uses iterations, the maximum allowed time without update depends
on the I<Interval> information contained in each value list. This is used in
the I<Threshold> configuration to dispatch notifications about missing values,
-see L<"THRESHOLD CONFIGURATION"> below.
+see L<collectd-threshold(5)> for details.
=item B<ReadThreads> I<Num>
</URL>
</Plugin>
-Another CouchDB example:
-The following example will collect the status values from each database:
-
- <URL "http://localhost:5984/_all_dbs">
- Instance "dbs"
- <Key "*/doc_count">
- Type "gauge"
- </Key>
- <Key "*/doc_del_count">
- Type "counter"
- </Key>
- <Key "*/disk_size">
- Type "bytes"
- </Key>
- </URL>
-
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
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.
+channels, respectively. This, of course, only makes much sense when I<collectd>
+is running in foreground- or non-daemon-mode.
=item B<Timestamp> B<true>|B<false>
log file (e.E<nbsp>g. when rotating the logs). The plugin reopens the file
for each line it writes.
+=head2 Plugin C<lpar>
+
+The I<LPAR plugin> reads CPU statistics of I<Logical Partitions>, a
+virtualization technique for IBM POWER processors. It takes into account CPU
+time stolen from or donated to a partition, in addition to the usual user,
+system, I/O statistics.
+
+The following configuration options are available:
+
+=over 4
+
+=item B<CpuPoolStats> B<false>|B<true>
+
+When enabled, statistics about the processor pool are read, too. The partition
+needs to have pool authority in order to be able to acquire this information.
+Defaults to false.
+
+=item B<ReportBySerial> B<false>|B<true>
+
+If enabled, the serial of the physical machine the partition is currently
+running on is reported as I<hostname> and the logical hostname of the machine
+is reported in the I<plugin instance>. Otherwise, the logical hostname will be
+used (just like other plugins) and the I<plugin instance> will be empty.
+Defaults to false.
+
+=back
+
=head2 Plugin C<mbmon>
The C<mbmon plugin> uses mbmon to retrieve temperature, voltage, etc.
Instance "input-2"
</Data>
+ <Datagroup "device-type-1"
+ Collect "voltage-input-1"
+ Collect "voltage-input-2"
+ </Datagroup>
+
<Host "modbus.example.com">
Address "192.168.0.42"
Port "502"
Collect "voltage-input-1"
Collect "voltage-input-2"
</Slave>
+
+ <Slave 2>
+ Instance "power-supply"
+ Datagroup "device-type-1"
+ </Slave>
</Host>
=over 4
=back
+=item E<lt>B<Datagroup> I<Name>E<gt> blocks
+
+Datagroup blocks define a group of B<Data>-definitions. Datagroups can be used
+to collect the same data from a number of similar devices.
+
+Within E<lt>DatagroupE<nbsp>/E<gt> blocks, the following options are allowed:
+
+=over 4
+
+=item B<Collect> I<DataName>
+
+Specifies which data to include in the datagroup. I<DataName> must be the same
+string as the I<Name> argument passed to a B<Data> block. You can specify this
+option multiple times to include more than one value in the datagroup. All
+values in the datagroup will be collected from the devices that use is. At
+least one B<Collect> option is mandatory.
+
+=back
+
=item E<lt>B<Host> I<Name>E<gt> blocks
Host blocks are used to specify to which hosts to connect and what data to read
Specifies which data to retrieve from the device. I<DataName> must be the same
string as the I<Name> argument passed to a B<Data> block. You can specify this
option multiple times to collect more than one value from a slave. At least one
-B<Collect> option is mandatory.
+B<Collect> or B<Datagroup> option is mandatory.
+
+=item B<Datagroup> I<DatagroupName>
+
+Specifies which data to retrieve from the device. I<DatagroupName> must be the
+same string as the I<Name> argument passed to a B<Datagroup> block. All data
+specified in the Datagroup definition will be retrieved from the device. You
+can specify this option multiple or combine it with the B<Collect> option. At
+least one B<Collect> or B<Datagroup> option is mandatory.
=back
=head2 Plugin C<sensors>
-The C<sensors plugin> uses B<lm_sensors> to retrieve sensor-values. This means
+The I<Sensors plugin> uses B<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.
other plugins, its documentation has been moved to an own manpage,
L<collectd-snmp(5)>. Please see there for details.
+=head2 Plugin C<swap>
+
+The I<Swap plugin> collects information about used and available swap space. On
+I<Solaris>, the following options are available:
+
+=over 4
+
+=item B<ReportByDevice> B<false>|B<true>
+
+Configures how to report physical swap devices. If set to B<false> is used (the
+default), the summary over all swap devices is reported only, i.e. the globally
+used and available space over all devices. If B<true> is configured, the used
+and available space of each device will be reported separately.
+
+This option is only available if the I<Swap plugin> can use the L<swapctl(2)>
+mechanism under I<Solaris>.
+
+=back
+
=head2 Plugin C<syslog>
=over 4
=item B<ForceUseProcfs> I<true>|I<false>
-By default, the C<thermal> plugin tries to read the statistics from the Linux
+By default, the I<Thermal plugin> tries to read the statistics from the Linux
C<sysfs> interface. If that is not available, the plugin falls back to the
C<procfs> interface. By setting this option to I<true>, you can force the
plugin to use the latter. This option defaults to I<false>.
=back
+=head2 Plugin C<threshold>
+
+The I<Threshold plugin> checks values collected or received by I<collectd>
+against a configurable I<threshold> and issues I<notifications> if values are
+out of bounds.
+
+Documentation for this plugin is available in the L<collectd-threshold(5)>
+manual page.
+
=head2 Plugin C<tokyotyrant>
-The C<tokyotyrant plugin> connects to a TokyoTyrant server and collects a
+The I<TokyoTyrant plugin> connects to a TokyoTyrant server and collects a
couple metrics: number of records, and database size on disk.
=over 4
permissions must be given as a numeric, octal value as you would pass to
L<chmod(1)>. Defaults to B<0770>.
+=item B<DeleteSocket> B<false>|B<true>
+
+If set to B<true>, delete the socket file before calling L<bind(2)>, if a file
+with the given name already exists. If I<collectd> crashes a socket file may be
+left over, preventing the daemon from opening a new socket when restarted.
+Since this is potentially dangerous, this defaults to B<false>.
+
=back
=head2 Plugin C<uuid>
=back
-=head1 THRESHOLD CONFIGURATION
-
-Starting with version C<4.3.0> collectd has support for B<monitoring>. By that
-we mean that the values are not only stored or sent somewhere, but that they
-are judged and, if a problem is recognized, acted upon. The only action
-collectd takes itself is to generate and dispatch a "notification". Plugins can
-register to receive notifications and perform appropriate further actions.
-
-Since systems and what you expect them to do differ a lot, you can configure
-B<thresholds> for your values freely. This gives you a lot of flexibility but
-also a lot of responsibility.
-
-Every time a value is out of range a notification is dispatched. This means
-that the idle percentage of your CPU needs to be less then the configured
-threshold only once for a notification to be generated. There's no such thing
-as a moving average or similar - at least not now.
-
-Also, all values that match a threshold are considered to be relevant or
-"interesting". As a consequence collectd will issue a notification if they are
-not received for B<Timeout> iterations. The B<Timeout> configuration option is
-explained in section L<"GLOBAL OPTIONS">. If, for example, B<Timeout> is set to
-"2" (the default) and some hosts sends it's CPU statistics to the server every
-60 seconds, a notification will be dispatched after about 120 seconds. It may
-take a little longer because the timeout is checked only once each B<Interval>
-on the server.
-
-When a value comes within range again or is received after it was missing, an
-"OKAY-notification" is dispatched.
-
-Here is a configuration example to get you started. Read below for more
-information.
-
- <Threshold>
- <Type "foo">
- WarningMin 0.00
- WarningMax 1000.00
- FailureMin 0.00
- FailureMax 1200.00
- Invert false
- Instance "bar"
- </Type>
-
- <Plugin "interface">
- Instance "eth0"
- <Type "if_octets">
- FailureMax 10000000
- DataSource "rx"
- </Type>
- </Plugin>
-
- <Host "hostname">
- <Type "cpu">
- Instance "idle"
- FailureMin 10
- </Type>
-
- <Plugin "memory">
- <Type "memory">
- Instance "cached"
- WarningMin 100000000
- </Type>
- </Plugin>
-
- <Type "load">
- DataSource "midterm"
- FailureMax 4
- Hits 3
- Hysteresis 3
- </Type>
- </Host>
- </Threshold>
-
-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
-configured. The C<Plugin> and C<Type> blocks may be specified further using the
-C<Instance> option. You can combine the block by nesting the blocks, though
-they must be nested in the above order, i.E<nbsp>e. C<Host> may contain either
-C<Plugin> and C<Type> blocks, C<Plugin> may only contain C<Type> blocks and
-C<Type> may not contain other blocks. If multiple blocks apply to the same
-value the most specific block is used.
-
-The other statements specify the threshold to configure. They B<must> be
-included in a C<Type> block. Currently the following statements are recognized:
-
-=over 4
-
-=item B<FailureMax> I<Value>
-
-=item B<WarningMax> I<Value>
-
-Sets the upper bound of acceptable values. If unset defaults to positive
-infinity. If a value is greater than B<FailureMax> a B<FAILURE> notification
-will be created. If the value is greater than B<WarningMax> but less than (or
-equal to) B<FailureMax> a B<WARNING> notification will be created.
-
-=item B<FailureMin> I<Value>
-
-=item B<WarningMin> I<Value>
-
-Sets the lower bound of acceptable values. If unset defaults to negative
-infinity. If a value is less than B<FailureMin> a B<FAILURE> notification will
-be created. If the value is less than B<WarningMin> but greater than (or equal
-to) B<FailureMin> a B<WARNING> notification will be created.
-
-=item B<DataSource> I<DSName>
-
-Some data sets have more than one "data source". Interesting examples are the
-C<if_octets> data set, which has received (C<rx>) and sent (C<tx>) bytes and
-the C<disk_ops> data set, which holds C<read> and C<write> operations. The
-system load data set, C<load>, even has three data sources: C<shortterm>,
-C<midterm>, and C<longterm>.
-
-Normally, all data sources are checked against a configured threshold. If this
-is undesirable, or if you want to specify different limits for each data
-source, you can use the B<DataSource> option to have a threshold apply only to
-one data source.
-
-=item B<Invert> B<true>|B<false>
-
-If set to B<true> the range of acceptable values is inverted, i.E<nbsp>e.
-values between B<FailureMin> and B<FailureMax> (B<WarningMin> and
-B<WarningMax>) are not okay. Defaults to B<false>.
-
-=item B<Persist> B<true>|B<false>
-
-Sets how often notifications are generated. If set to B<true> one notification
-will be generated for each value that is out of the acceptable range. If set to
-B<false> (the default) then a notification is only generated if a value is out
-of range but the previous value was okay.
-
-This applies to missing values, too: If set to B<true> a notification about a
-missing value is generated once every B<Interval> seconds. If set to B<false>
-only one such notification is generated until the value appears again.
-
-=item B<Percentage> B<true>|B<false>
-
-If set to B<true>, the minimum and maximum values given are interpreted as
-percentage value, relative to the other data sources. This is helpful for
-example for the "df" type, where you may want to issue a warning when less than
-5E<nbsp>% of the total space is available. Defaults to B<false>.
-
-=item B<Hits> I<Value>
-
-Sets the number of occurrences which the threshold must be arised before to
-dispatch any notification or, in other words, the number of B<Interval>s
-than the threshold must be match before dispatch any notification.
-
-=item B<Hysteresis> I<Value>
-
-Sets the hysteresis value for threshold. The hysteresis is a method to
-prevent flapping between states, until a new received value for
-a previously matched threshold down below the threshold condition
-(B<WarningMax>, B<FailureMin> or everthing else) minus the hysteresis value,
-the failure (respectively warning) state will be keep.
-
-=item B<Interesting> B<true>|B<false>
-
-If set to B<true> (the default), the threshold must be treated as
-interesting and, when a number of B<Timeout> values will lost, then
-a missing notification will be dispatched. On the other hand, if set to
-B<false>, the missing notification will never dispatched for this threshold.
-
-=back
-
=head1 FILTER CONFIGURATION
Starting with collectd 4.6 there is a powerful filtering infrastructure
projects / collectd.git / blobdiff