Merge branch 'master' into ff/java
[collectd.git] / src / collectd.conf.pod
index 605ba14..48b75bc 100644 (file)
@@ -529,7 +529,7 @@ than those of other plugins. It usually looks something like this:
       MinVersion 50000
       <Result>
         Type "gauge"
       MinVersion 50000
       <Result>
         Type "gauge"
-       InstancePrefix "out_of_stock"
+        InstancePrefix "out_of_stock"
         InstancesFrom "category"
         ValuesFrom "value"
       </Result>
         InstancesFrom "category"
         ValuesFrom "value"
       </Result>
@@ -653,20 +653,24 @@ There must be exactly one B<Type> option inside each B<Result> block.
 
 =item B<InstancePrefix> I<prefix>
 
 
 =item B<InstancePrefix> I<prefix>
 
-Prepends I<prefix> followed by a dash I<("-")> to the type instance. See
-B<InstancesFrom> on how the rest of the type instance is built.
+Prepends I<prefix> to the type instance. If B<InstancesFrom> (see below) is not
+given, the string is simply copied. If B<InstancesFrom> is given, I<prefix> and
+all strings returned in the appropriate columns are concatenated together,
+separated by dashes I<("-")>.
 
 =item B<InstancesFrom> I<column0> [I<column1> ...]
 
 
 =item B<InstancesFrom> I<column0> [I<column1> ...]
 
-Specifies the columns whose values will be used to create the "TypeInstance"
-for each row. You need to specify at least one column for each query. If you
-specify more than one column, the value of all columns will be join together
-with the hyphen as separation character.
+Specifies the columns whose values will be used to create the "type-instance"
+for each row. If you specify more than one column, the value of all columns
+will be joined together with dashes I<("-")> as separation characters.
 
 The plugin itself does not check whether or not all built instances are
 
 The plugin itself does not check whether or not all built instances are
-different. It's your responsibility to assure that each is unique.
+different. It's your responsibility to assure that each is unique. This is
+especially true, if you do not specify B<InstancesFrom>: B<You> have to make
+sure that only one row is returned in this case.
 
 
-There must be at least one B<InstancesFrom> option inside each B<Result> block.
+If neither B<InstancePrefix> nor B<InstancesFrom> is given, the type-instance
+will be empty.
 
 =item B<ValuesFrom> I<column0> [I<column1> ...]
 
 
 =item B<ValuesFrom> I<column0> [I<column1> ...]
 
@@ -955,97 +959,6 @@ Controls whether or not to recurse into subdirectories. Enabled by default.
 
 =back
 
 
 =back
 
-=head2 Plugin C<filter_pcre>
-
-This plugin allows you to filter and rewrite value lists based on
-Perl-compatible regular expressions whose syntax and semantics are as close as
-possible to those of the Perl 5 language. See L<pcre(3)> for details.
-
-  <Plugin filter_pcre>
-    <RegEx>
-      Host "^mail\d+$"
-      Plugin "^tcpconns$"
-      TypeInstance "^SYN_"
-
-      Action NoWrite
-    </RegEx>
-
-    <RegEx>
-      Plugin "^sensors$"
-      PluginInstance "^Some Weird Sensor Chip Name Prefix"
-
-      SubstitutePluginInstance "foo"
-    </RegEx>
-  </Plugin>
-
-The configuration consists of one or more C<RegEx> blocks, each of which
-specifies a regular expression identifying a set of value lists and how to
-handle successful matches. A value list keeps the values of a single data-set
-and is identified by the tuple (host, plugin, plugin instance, type, type
-instance). The plugin and type instances are optional components. If they are
-missing they are treated as empty strings. Within those blocks, the following
-options are recognized:
-
-=over 4
-
-=item B<Host> I<regex>
-
-=item B<Plugin> I<regex>
-
-=item B<PluginInstance> I<regex>
-
-=item B<Type> I<regex>
-
-=item B<TypeInstance> I<regex>
-
-Specifies the regular expression for each component of the identifier. If any
-of these options is missing it is interpreted as a pattern which matches any
-string. All five components of a value list have to match the appropriate
-regular expression to trigger the specified action.
-
-=item B<Action> I<NoWrite>|I<NoThresholdCheck>|I<Ignore>
-
-Specify how to handle successful matches:
-
-=over 4
-
-=item B<NoWrite>
-
-Do not send the value list to any output (a.k.a. write) plugins.
-
-=item B<NoThresholdCheck>
-
-Skip threshold checking for this value list.
-
-=item B<Ignore>
-
-Completely ignore this value list.
-
-=back
-
-Two or more actions may be combined by specifying multiple B<Action> options.
-
-=item B<SubstituteHost> I<replacement>
-
-=item B<SubstitutePlugin> I<replacement>
-
-=item B<SubstitutePluginInstance> I<replacement>
-
-=item B<SubstituteType> I<replacement>
-
-=item B<SubstituteTypeInstance> I<replacement>
-
-Upon a successful match, the matching substring will be replaced by the
-specified I<replacement> text. These options require that an appropriate regex
-has been specified before, e.E<nbsp>g. B<SubstituteHost> requires that the
-B<Host> option has been specified before.
-
-B<Note>: It is not recommended to modify the type unless you really know what
-you are doing. The type is used to identify the data-set definition of the
-dispatched values.
-
-=back
-
 =head2 Plugin C<hddtemp>
 
 To get values from B<hddtemp> collectd connects to B<localhost> (127.0.0.1),
 =head2 Plugin C<hddtemp>
 
 To get values from B<hddtemp> collectd connects to B<localhost> (127.0.0.1),
@@ -1170,6 +1083,65 @@ and all other interrupts are collected.
 
 =back
 
 
 =back
 
+=head2 Plugin C<java>
+
+Synopsis:
+
+ <Plugin "java">
+   JVMArg "-verbose:jni"
+   JVMArg "-Djava.class.path=/opt/collectd/lib/collectd/bindings/java"
+   LoadPlugin "org.collectd.java.Foobar"
+   <Plugin "org.collectd.java.Foobar">
+     # To be parsed by the plugin
+   </Plugin>
+ </Plugin>
+
+Available config options:
+
+=over 4
+
+=item B<JVMArg> I<Argument>
+
+Argument that is to be passed to the I<Java Virtual Machine> (JVM). This works
+exactly the way the arguments to the I<java> binary on the command line work.
+Execute C<javaE<nbsp>--help> for details.
+
+=item B<LoadPlugin> I<JavaClass>
+
+Instantiates a new I<JavaClass> object. The following methods of this class are
+used when available:
+
+=over 4
+
+=item *
+
+public int B<Config> (org.collectd.api.OConfigItem ci)
+
+=item *
+
+public int B<Init> ()
+
+=item *
+
+public int B<Read> ()
+
+=item *
+
+public int B<Write> (org.collectd.protocol.ValueList vl)
+
+=item *
+
+public int B<Shutdown> ()
+
+=back
+
+=item B<Plugin> I<JavaClass>
+
+The entrie block is passed to the Java plugin as an
+I<org.collectd.api.OConfigItem> object.
+
+=back
+
 =head2 Plugin C<libvirt>
 
 This plugin allows CPU, disk and network load to be collected for virtualized
 =head2 Plugin C<libvirt>
 
 This plugin allows CPU, disk and network load to be collected for virtualized
@@ -1581,6 +1553,61 @@ has been specified, the default is used as well.
 
 =back
 
 
 =back
 
+=head2 Plugin C<notify_email>
+
+The I<notify_email> plugin uses the I<ESMTP> library to send notifications to a
+configured email address.
+
+I<libESMTP> is available from L<http://www.stafford.uklinux.net/libesmtp/>.
+
+Available configuration options:
+
+=over 4
+
+=item B<From> I<Address>
+
+Email address from which the emails should appear to come from.
+
+Default: C<root@localhost>
+
+=item B<Recipient> I<Address>
+
+Configures the email address(es) to which the notifications should be mailed.
+May be repeated to send notifications to multiple addresses.
+
+At least one B<Recipient> must be present for the plugin to work correctly.
+
+=item B<SMTPServer> I<Hostname>
+
+Hostname of the SMTP server to connect to.
+
+Default: C<localhost>
+
+=item B<SMTPPort> I<Port>
+
+TCP port to connect to.
+
+Default: C<25>
+
+=item B<SMTPUser> I<Username>
+
+Username for ASMTP authentication. Optional.
+
+=item B<SMTPPassword> I<Password>
+
+Password for ASMTP authentication. Optional.
+
+=item B<Subject> I<Subject>
+
+Subject-template to use when sending emails. There must be exactly two
+string-placeholders in the subject, given in the standard I<printf(3)> syntax,
+i.E<nbsp>e. C<%s>. The first will be replaced with the severity, the second
+with the hostname.
+
+Default: C<Collectd notify: %s@%s>
+
+=back
+
 =head2 Plugin C<ntpd>
 
 =over 4
 =head2 Plugin C<ntpd>
 
 =over 4
@@ -2390,7 +2417,7 @@ reduces IO-operations and thus lessens the load produced by updating the files.
 The trade off is that the graphs kind of "drag behind" and that more memory is
 used.
 
 The trade off is that the graphs kind of "drag behind" and that more memory is
 used.
 
-=item B<WritesPerSecond> B<Updates>
+=item B<WritesPerSecond> I<Updates>
 
 When collecting many statistics with collectd and the C<rrdtool> plugin, you
 will run serious performance problems. The B<CacheFlush> setting and the
 
 When collecting many statistics with collectd and the C<rrdtool> plugin, you
 will run serious performance problems. The B<CacheFlush> setting and the
@@ -2468,9 +2495,109 @@ debugging support.
 
 =back
 
 
 =back
 
+=head2 Plugin C<table>
+
+The C<table plugin> provides generic means to parse tabular data and dispatch
+user specified values. Values are selected based on column numbers. For
+example, this plugin may be used to get values from the Linux L<proc(5)>
+filesystem or CSV (comma separated values) files.
+
+  <Plugin table>
+    <Table "/proc/slabinfo">
+      Instance "slabinfo"
+      Separator " "
+      <Result>
+        Type gauge
+        InstancePrefix "active_objs"
+        InstancesFrom 0
+        ValuesFrom 1
+      </Result>
+      <Result>
+        Type gauge
+        InstancePrefix "objperslab"
+        InstancesFrom 0
+        ValuesFrom 4
+      </Result>
+    </Table>
+  </Plugin>
+
+The configuration consists of one or more B<Table> blocks, each of which
+configures one file to parse. Within each B<Table> block, there are one or
+more B<Result> blocks, which configure which data to select and how to
+interpret it.
+
+The following options are available inside a B<Table> block:
+
+=over 4
+
+=item B<Instance> I<instance>
+
+If specified, I<instance> is used as the plugin instance. So, in the above
+example, the plugin name C<table-slabinfo> would be used. If omitted, the
+filename of the table is used instead, with all special characters replaced
+with an underscore (C<_>).
+
+=item B<Separator> I<string>
+
+Any character of I<string> is interpreted as a delimiter between the different
+columns of the table. A sequence of two or more contiguous delimiters in the
+table is considered to be a single delimiter, i.E<nbsp>e. there cannot be any
+empty columns. The plugin uses the L<strtok_r(3)> function to parse the lines
+of a table - see its documentation for more details. This option is mandatory.
+
+A horizontal tab, newline and carriage return may be specified by C<\\t>,
+C<\\n> and C<\\r> respectively. Please note that the double backslashes are
+required because of collectd's config parsing.
+
+=back
+
+The following options are available inside a B<Result> block:
+
+=over 4
+
+=item B<Type> I<type>
+
+Sets the type used to dispatch the values to the daemon. Detailed information
+about types and their configuration can be found in L<types.db(5)>. This
+option is mandatory.
+
+=item B<InstancePrefix> I<prefix>
+
+If specified, prepend I<prefix> to the type instance. If omitted, only the
+B<InstancesFrom> option is considered for the type instance.
+
+=item B<InstancesFrom> I<column0> [I<column1> ...]
+
+If specified, the content of the given columns (identified by the column
+number starting at zero) will be used to create the type instance for each
+row. Multiple values (and the instance prefix) will be joined together with
+dashes (I<->) as separation character. If omitted, only the B<InstancePrefix>
+option is considered for the type instance.
+
+The plugin itself does not check whether or not all built instances are
+different. It’s your responsibility to assure that each is unique. This is
+especially true, if you do not specify B<InstancesFrom>: B<You> have to make
+sure that the table only contains one row.
+
+If neither B<InstancePrefix> nor B<InstancesFrom> is given, the type instance
+will be empty.
+
+=item B<ValuesFrom> I<column0> [I<column1> ...]
+
+Specifies the columns (identified by the column numbers starting at zero)
+whose content is used as the actual data for the data sets that are dispatched
+to the daemon. How many such columns you need is determined by the B<Type>
+setting above. If you specify too many or not enough columns, the plugin will
+complain about that and no data will be submitted to the daemon. The plugin
+uses L<strtoll(3)> and L<strtod(3)> to parse counter and gauge values
+respectively, so anything supported by those functions is supported by the
+plugin as well. This option is mandatory.
+
+=back
+
 =head2 Plugin C<tail>
 
 =head2 Plugin C<tail>
 
-The C<tail plugin> plugins follows logfiles, just like L<tail(1)> does, parses
+The C<tail plugin> follows logfiles, just like L<tail(1)> does, parses
 each line and dispatches found values. What is matched can be configured by the
 user using (extended) regular expressions, as described in L<regex(7)>.
 
 each line and dispatches found values. What is matched can be configured by the
 user using (extended) regular expressions, as described in L<regex(7)>.
 
@@ -2896,16 +3023,16 @@ only one such notification is generated until the value appears again.
 
 =head1 FILTER CONFIGURATION
 
 
 =head1 FILTER CONFIGURATION
 
-TODO: Update this entire section once development is done.
-
 Starting with collectd 4.6 there is a powerful filtering infrastructure
 Starting with collectd 4.6 there is a powerful filtering infrastructure
-implemented in the daemon. The concept has mostly been copied from I<iptables>,
-the packet filter infrastructure for Linux. We'll use a similar terminology, so
-that users that are familiar with iptables feel right at home.
+implemented in the daemon. The concept has mostly been copied from
+I<ip_tables>, the packet filter infrastructure for Linux. We'll use a similar
+terminology, so that users that are familiar with iptables feel right at home.
 
 =head2 Terminology
 
 
 =head2 Terminology
 
-The most important terms are:
+The following are the terms used in the remainder of the filter configuration
+documentation. For an ASCII-art schema of the mechanism, see
+L<"General structure"> below.
 
 =over 4
 
 
 =over 4
 
@@ -2914,15 +3041,18 @@ The most important terms are:
 A I<match> is a criteria to select specific values. Examples are, of course, the
 name of the value or it's current value.
 
 A I<match> is a criteria to select specific values. Examples are, of course, the
 name of the value or it's current value.
 
+Matches are implemented in plugins which you have to load prior to using the
+match. The name of such plugins starts with the "match_" prefix.
+
 =item B<Target>
 
 A I<target> is some action that is to be performed with data. Such actions
 could, for example, be to change part of the value's identifier or to ignore
 =item B<Target>
 
 A I<target> is some action that is to be performed with data. Such actions
 could, for example, be to change part of the value's identifier or to ignore
-the value completely. Built-in functions are B<write> and B<stop>, see below.
+the value completely.
 
 
-Some targets, for example the built-in B<stop> target, signal that processing
-of a value should be stopped. In that case processing of the current chain will
-be aborted.
+Some of these targets are built into the daemon, see L<"Built-in targets">
+below. Other targets are implemented in plugins which you have to load prior to
+using the target. The name of such plugins starts with the "target_" prefix.
 
 =item B<Rule>
 
 
 =item B<Rule>
 
@@ -2931,18 +3061,14 @@ I<rule>. The target actions will be performed for all values for which B<all>
 matches apply. If the rule does not have any matches associated with it, the
 target action will be performed for all values.
 
 matches apply. If the rule does not have any matches associated with it, the
 target action will be performed for all values.
 
-If any target returns the stop condition, the processing will stop right away.
-This means that any targets following the current one will not be called after
-the stop condition has been returned.
-
 =item B<Chain>
 
 A I<chain> is a list of rules and possibly default targets. The rules are tried
 in order and if one matches, the associated target will be called. If a value
 is handled by a rule, it depends on the target whether or not any subsequent
 =item B<Chain>
 
 A I<chain> is a list of rules and possibly default targets. The rules are tried
 in order and if one matches, the associated target will be called. If a value
 is handled by a rule, it depends on the target whether or not any subsequent
-rules are considered or if traversal of the chain is aborted. After all rules
-have been checked and no target returned the stop condition, the default
-targets will be executed.
+rules are considered or if traversal of the chain is aborted, see
+L<"Flow control"> below. After all rules have been checked, the default targets
+will be executed.
 
 =back
 
 
 =back
 
@@ -2979,12 +3105,46 @@ The following shows the resulting structure:
  ! Target  !
  +---------+
 
  ! Target  !
  +---------+
 
+=head2 Flow control
+
+There are four ways to control which way a value takes through the filter
+mechanism:
+
+=over 4
+
+=item B<jump>
+
+The built-in B<jump> target can be used to "call" another chain, i.E<nbsp>e.
+process the value with another chain. When the called chain finishes, usually
+the next target or rule after the jump is executed.
+
+=item B<stop>
+
+The stop condition, signaled for example by the built-in target B<stop>, causes
+all processing of the value to be stopped immediately.
+
+=item B<return>
+
+Causes processing in the current chain to be aborted, but processing of the
+value generally will continue. This means that if the chain was called via
+B<Jump>, the next target or rule after the jump will be executed. If the chain
+was not called by another chain, control will be returned to the daemon and it
+may pass the value to another chain.
+
+=item B<continue>
+
+Most targets will signal the B<continue> condition, meaning that processing
+should continue normally. There is no special built-in target for this
+condition.
+
+=back
+
 =head2 Synopsis
 
 The configuration reflects this structure directly:
 
 =head2 Synopsis
 
 The configuration reflects this structure directly:
 
- PostCacheChain "main"
- <Chain "main">
+ PostCacheChain "PostCache"
+ <Chain "PostCache">
    <Rule "ignore_mysql_show">
      <Match "regex">
        Plugin "^mysql$"
    <Rule "ignore_mysql_show">
      <Match "regex">
        Plugin "^mysql$"
@@ -3047,7 +3207,7 @@ read-plugins to the write-plugins:
  :  dispatch values  :
  + - - - - - - - - - +
 
  :  dispatch values  :
  + - - - - - - - - - +
 
-After the values are passed from the read-plugins to the dispatch functions,
+After the values are passed from the "read" plugins to the dispatch functions,
 the pre-cache chain is run first. The values are added to the internal cache
 afterwards. The post-cache chain is run after the values have been added to the
 cache. So why is it such a huge deal if chains are run before or after the
 the pre-cache chain is run first. The values are added to the internal cache
 afterwards. The post-cache chain is run after the values have been added to the
 cache. So why is it such a huge deal if chains are run before or after the
@@ -3055,10 +3215,10 @@ values have been added to this cache?
 
 Targets that change the identifier of a value list should be executed before
 the values are added to the cache, so that the name in the cache matches the
 
 Targets that change the identifier of a value list should be executed before
 the values are added to the cache, so that the name in the cache matches the
-name that is used in the write-plugins. The C<unixsock> plugin, too, uses this
-cache to receive a list of all available values. If you change the identifier
-after the value list has been added to the cache, this may easily lead to
-confusion, but it's not forbidden of course.
+name that is used in the "write" plugins. The C<unixsock> plugin, too, uses
+this cache to receive a list of all available values. If you change the
+identifier after the value list has been added to the cache, this may easily
+lead to confusion, but it's not forbidden of course.
 
 The cache is also used to convert counter values to rates. These rates are, for
 example, used by the C<value> match (see below). If you use the rate stored in
 
 The cache is also used to convert counter values to rates. These rates are, for
 example, used by the C<value> match (see below). If you use the rate stored in
@@ -3132,11 +3292,11 @@ plugins to be loaded:
 
 =item B<return>
 
 
 =item B<return>
 
-Signals the "return" condition. This causes the current chain to stop
-processing the value and returns control to the calling chain. The calling
-chain will continue processing targets and rules just after the B<jump> target
-(see below). This is very similar to the B<RETURN> target of iptables, see
-L<iptables(8)>.
+Signals the "return" condition, see the L<"Flow control"> section above. This
+causes the current chain to stop processing the value and returns control to
+the calling chain. The calling chain will continue processing targets and rules
+just after the B<jump> target (see below). This is very similar to the
+B<RETURN> target of iptables, see L<iptables(8)>.
 
 This target does not have any options.
 
 
 This target does not have any options.
 
@@ -3146,9 +3306,9 @@ Example:
 
 =item B<stop>
 
 
 =item B<stop>
 
-Signals the "stop" condition, causing processing of the value to be aborted
-immediately. This is similar to the B<DROP> target of iptables, see
-L<iptables(8)>.
+Signals the "stop" condition, see the L<"Flow control"> section above. This
+causes processing of the value to be aborted immediately. This is similar to
+the B<DROP> target of iptables, see L<iptables(8)>.
 
 This target does not have any options.
 
 
 This target does not have any options.
 
@@ -3158,7 +3318,7 @@ Example:
 
 =item B<write>
 
 
 =item B<write>
 
-Sends the value to write plugins.
+Sends the value to "write" plugins.
 
 Available options:
 
 
 Available options:
 
@@ -3182,11 +3342,11 @@ Example:
 
 =item B<jump>
 
 
 =item B<jump>
 
-Starts processing the rules of another chain. If the end of that chain is
-reached, or a stop condition is encountered, processing will continue right
-after the B<jump> target, i.E<nbsp>e. with the next target or the next rule.
-This is similar to the B<-j> command line option of iptables, see
-L<iptables(8)>.
+Starts processing the rules of another chain, see L<"Flow control"> above. If
+the end of that chain is reached, or a stop condition is encountered,
+processing will continue right after the B<jump> target, i.E<nbsp>e. with the
+next target or the next rule. This is similar to the B<-j> command line option
+of iptables, see L<iptables(8)>.
 
 Available options:
 
 
 Available options:
 
@@ -3483,22 +3643,20 @@ If you use collectd with an old configuration, i.E<nbsp>e. one without a
 B<Chain> block, it will behave as it used to. This is equivalent to the
 following configuration:
 
 B<Chain> block, it will behave as it used to. This is equivalent to the
 following configuration:
 
- <Chain "main">
+ <Chain "PostCache">
    Target "write"
  </Chain>
 
    Target "write"
  </Chain>
 
-If you specify a B<Chain> block anywhere, the B<write> target will not be added
+If you specify a B<PostCacheChain>, the B<write> target will not be added
 anywhere and you will have to make sure that it is called where appropriate. We
 anywhere and you will have to make sure that it is called where appropriate. We
-suggest to add the above snippet as default target to your main chain.
-
-TODO: Notifications will be implemented using chains, too. Describe that here!
+suggest to add the above snippet as default target to your "PostCache" chain.
 
 =head2 Examples
 
 Ignore all values, where the hostname does not contain a dot, i.E<nbsp>e. can't
 be an FQDN.
 
 
 =head2 Examples
 
 Ignore all values, where the hostname does not contain a dot, i.E<nbsp>e. can't
 be an FQDN.
 
- <Chain "main">
+ <Chain "PreCache">
    <Rule "no_fqdn">
      <Match "regex">
        Host "^[^\.]*$"
    <Rule "no_fqdn">
      <Match "regex">
        Host "^[^\.]*$"
@@ -3519,7 +3677,6 @@ L<hddtemp(8)>,
 L<iptables(8)>,
 L<kstat(3KSTAT)>,
 L<mbmon(1)>,
 L<iptables(8)>,
 L<kstat(3KSTAT)>,
 L<mbmon(1)>,
-L<pcre(3)>,
 L<psql(1)>,
 L<regex(7)>,
 L<rrdtool(1)>,
 L<psql(1)>,
 L<regex(7)>,
 L<rrdtool(1)>,