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>
F<README> file shipped with the sourcecode and hopefully binary packets as
well.
+=head2 Plugin C<amqp>
+
+The I<AMQMP plugin> can be used to communicate with other instances of
+I<collectd> or third party applications using an AMQP message broker. Values
+are sent to or received from the broker, which handles routing, queueing and
+possibly filtering or messages.
+
+ <Plugin "amqp">
+ # Send values to an AMQP broker
+ <Publish "some_name">
+ Host "localhost"
+ Port "5672"
+ VHost "/"
+ User "guest"
+ Password "guest"
+ Exchange "amq.fanout"
+ # ExchangeType "fanout"
+ # RoutingKey "collectd"
+ # Persistent false
+ # Format "command"
+ # StoreRates false
+ </Publish>
+
+ # Receive values from an AMQP broker
+ <Subscribe "some_name">
+ Host "localhost"
+ Port "5672"
+ VHost "/"
+ User "guest"
+ Password "guest"
+ Exchange "amq.fanout"
+ # ExchangeType "fanout"
+ # Queue "queue_name"
+ # RoutingKey "collectd.#"
+ </Subscribe>
+ </Plugin>
+
+The plugin's configuration consists of a number of I<Publish> and I<Subscribe>
+blocks, which configure sending and receiving of values respectively. The two
+blocks are very similar, so unless otherwise noted, an option can be used in
+either block. The name given in the blocks starting tag is only used for
+reporting messages, but may be used to support I<flushing> of certain
+I<Publish> blocks in the future.
+
+=over 4
+
+=item B<Host> I<Host>
+
+Hostname or IP-address of the AMQP broker. Defaults to the default behavior of
+the underlying communications library, I<rabbitmq-c>, which is "localhost".
+
+=item B<Port> I<Port>
+
+Service name or port number on which the AMQP broker accepts connections. This
+argument must be a string, even if the numeric form is used. Defaults to
+"5672".
+
+=item B<VHost> I<VHost>
+
+Name of the I<virtual host> on the AMQP broker to use. Defaults to "/".
+
+=item B<User> I<User>
+
+=item B<Password> I<Password>
+
+Credentials used to authenticate to the AMQP broker. By default "guest"/"guest"
+is used.
+
+=item B<Exchange> I<Exchange>
+
+In I<Publish> blocks, this option specifies the I<exchange> to send values to.
+By default, "amq.fanout" will be used.
+
+In I<Subscribe> blocks this option is optional. If given, a I<binding> between
+the given exchange and the I<queue> is created, using the I<routing key> if
+configured. See the B<Queue> and B<RoutingKey> options below.
+
+=item B<ExchangeType> I<Type>
+
+If given, the plugin will try to create the configured I<exchange> with this
+I<type> after connecting. When in a I<Subscribe> block, the I<queue> will then
+be bound to this exchange.
+
+=item B<Queue> I<Queue> (Subscribe only)
+
+Configures the I<queue> name to subscribe to. If no queue name was configures
+explicitly, a unique queue name will be created by the broker.
+
+=item B<RoutingKey> I<Key>
+
+In I<Publish> blocks, this configures the routing key to set on all outgoing
+messages. If not given, the routing key will be computed from the I<identifier>
+of the value. The host, plugin, type and the two instances are concatenated
+together using dots as the separator and all containing dots replaced with
+slashes. For example "collectd.host/example/com.cpu.0.cpu.user". This makes it
+possible to receive only specific values using a "topic" exchange.
+
+In I<Subscribe> blocks, configures the I<routing key> used when creating a
+I<binding> between an I<exchange> and the I<queue>. The usual wildcards can be
+used to filter messages when using a "topic" exchange. If you're only
+interested in CPU statistics, you could use the routing key "collectd.*.cpu.#"
+for example.
+
+=item B<Persistent> B<true>|B<false> (Publish only)
+
+Selects the I<delivery method> to use. If set to B<true>, the I<persistent>
+mode will be used, i.e. delivery is guaranteed. If set to B<false> (the
+default), the I<transient> delivery mode will be used, i.e. messages may be
+lost due to high load, overflowing queues or similar issues.
+
+=item B<Format> B<Command>|B<JSON> (Publish only)
+
+Selects the format in which messages are sent to the broker. If set to
+B<Command> (the default), values are sent as C<PUTVAL> commands which are
+identical to the syntax used by the I<Exec> and I<UnixSock plugins>. In this
+case, the C<Content-Type> header field will be set to C<text/collectd>.
+
+If set to B<JSON>, the values are encoded in the I<JavaScript Object Notation>,
+an easy and straight forward exchange format. The C<Content-Type> header field
+will be set to C<application/json>.
+
+A subscribing client I<should> use the C<Content-Type> header field to
+determine how to decode the values. Currently, the I<AMQP plugin> itself can
+only decode the B<Command> format.
+
+=item B<StoreRates> B<true>|B<false> (Publish only)
+
+Determines whether or not C<COUNTER>, C<DERIVE> and C<ABSOLUTE> data sources
+are converted to a I<rate> (i.e. a C<GAUGE> value). If set to B<false> (the
+default), no conversion is performed. Otherwise the conversion is performed
+using the internal value cache.
+
+Please note that currently this option is only used if the B<Format> option has
+been set to B<JSON>.
+
+=back
+
=head2 Plugin C<apache>
To configure the C<apache>-plugin you first need to configure the Apache
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:
+The configuration of the I<Apache> plugin consists of one or more
+C<E<lt>InstanceE<nbsp>/E<gt>> blocks. Each block requires one string argument
+as the instance name. For example:
+
+ <Plugin "apache">
+ <Instance "www1">
+ URL "http://www1.example.com/mod_status?auto"
+ </Instance>
+ <Instance "www2">
+ URL "http://www2.example.com/mod_status?auto"
+ </Instance>
+ </Plugin>
+
+The instance name will be used as the I<plugin instance>. To emulate the old
+(versionE<nbsp>4) behavior, you can use an empty string (""). In order for the
+plugin to work correctly, each instance name must be unique. This is not
+enforced by the plugin and it is your responsibility to ensure it.
+
+The following options are accepted within each I<Instance> block:
=over 4
Sets the URL of the C<mod_status> output. This needs to be the output generated
by C<ExtendedStatus on> and it needs to be the machine readable output
-generated by appending the C<?auto> argument.
+generated by appending the C<?auto> argument. This option is I<mandatory>.
=item B<User> I<Username>
</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
=item B<MaxPacketSize> I<1024-65535>
Set the maximum size for datagrams received over the network. Packets larger
-than this will be truncated.
+than this will be truncated. Defaults to 1452E<nbsp>bytes.
=item B<Forward> I<true|false>
=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