inet localhost port 8053;
};
+The configuration follows the grouping that can be seen when looking at the
+data with an XSLT compatible viewer, such as a modern web browser. It's
+probably a good idea to make yourself familiar with the provided values, so you
+can understand what the collected statistics actually mean.
+
+Synopsis:
+
+ <Plugin "bind">
+ URL "http://localhost:8053/"
+ OpCodes true
+ QTypes true
+
+ ServerStats true
+ ZoneMaintStats true
+ ResolverStats false
+ MemoryStats true
+
+ <View "_default">
+ QTypes true
+ ResolverStats true
+ CacheRRSets true
+
+ Zone "127.in-addr.arpa/IN"
+ </View>
+ </Plugin>
+
The bind plugin accepts the following configuration options:
=over 4
URL from which to retrieve the XML data. If not specified,
C<http://localhost:8053/> will be used.
-=item B<DNSSEC> I<true>|I<false>
-
=item B<OpCodes> I<true>|I<false>
-=item B<Queries> I<true>|I<false>
+When enabled, statistics about the I<"OpCodes">, for example the number of
+C<QUERY> packets, are collected.
+
+Default: Enabled.
-=item B<QueryResults> I<true>|I<false>
+=item B<QTypes> I<true>|I<false>
-=item B<RCode> I<true>|I<false>
+When enabled, the number of I<incoming> queries by query types (for example
+C<A>, C<MX>, C<AAAA>) is collected.
-=item B<Rejects> I<true>|I<false>
+Default: Enabled.
-=item B<Requests> I<true>|I<false>
+=item B<ServerStats> I<true>|I<false>
-=item B<Resolver> I<true>|I<false>
+Collect global server statistics, such as requests received over IPv4 and IPv6,
+successful queries, and failed updates.
-=item B<Responses> I<true>|I<false>
+Default: Enabled.
-=item B<RRQueriesIn> I<true>|I<false>
+=item B<ZoneMaintStats> I<true>|I<false>
-=item B<Updates> I<true>|I<false>
+Collect zone maintenance statistics, mostly information about notifications
+(zone updates) and zone transfers.
-=item B<ZoneMaintenance> I<true>|I<false>
+Default: Enabled.
-=item B<ZoneStats> I<true>|I<false>
+=item B<ResolverStats> I<true>|I<false>
-Enables or disables collection of specific counters.
-TODO: Options must be described in detail!
+Collect resolver statistics, i.E<nbsp>e. statistics about outgoing requests
+(e.E<nbsp>g. queries over IPv4, lame servers). Since the global resolver
+counters apparently were removed in BIND 9.5.1 and 9.6.0, this is disabled by
+default. Use the B<ResolverStats> option within a B<View "_default"> block
+instead for the same functionality.
+
+Default: Disabled.
+
+=item B<MemoryStats>
+
+Collect global memory statistics.
+
+Default: Enabled.
+
+=item B<View> I<Name>
+
+Collect statistics about a specific I<"view">. BIND can behave different,
+mostly depending on the source IP-address of the request. These different
+configurations are called "views". If you don't use this feature, you most
+likely are only interested in the C<_default> view.
+
+Within a E<lt>B<View>E<nbsp>I<name>E<gt> block, you can specify which
+information you want to collect about a view. If no B<View> block is
+configured, no detailed view statistics will be collected.
+
+=over 4
+
+=item B<QTypes> I<true>|I<false>
+
+If enabled, the number of I<outgoing> queries by query type (e.E<nbsp>g. C<A>,
+C<MX>) is collected.
+
+Default: Enabled.
+
+=item B<ResolverStats> I<true>|I<false>
+
+Collect resolver statistics, i.E<nbsp>e. statistics about outgoing requests
+(e.E<nbsp>g. queries over IPv4, lame servers).
+
+Default: Enabled.
+
+=item B<CacheRRSets> I<true>|I<false>
+
+If enabled, the number of entries (I<"RR sets">) in the view's cache by query
+type is collected. Negative entries (queries which resulted in an error, for
+example names that do not exist) are reported with a leading exclamation mark,
+e.E<nbsp>g. "!A".
+
+Default: Enabled.
+
+=item B<Zone> I<Name>
+
+When given, collect detailed information about the given zone in the view. The
+information collected if very similar to the global B<ServerStats> information
+(see above).
+
+You can repeat this option to collect detailed information about multiple
+zones.
+
+By default no detailed zone information is collected.
+
+=back
=back
=back
+=head2 Plugin C<curl>
+
+The curl plugin uses the B<libcurl> (L<http://curl.haxx.se/>) to read web pages
+and the match infrastructure (the same code used by the tail plugin) to use
+regular expressions with the received data.
+
+The following example will read the current value of AMD stock from google's
+finance page and dispatch the value to collectd.
+
+ <Plugin curl>
+ <Page "stock_quotes">
+ URL "http://finance.google.com/finance?q=NYSE%3AAMD"
+ User "foo"
+ Password "bar"
+ <Match>
+ Regex "<span +class=\"pr\"[^>]*> *([0-9]*\\.[0-9]+) *</span>"
+ DSType "GaugeAverage"
+ # Note: `stock_value' is not a standard type.
+ Type "stock_value"
+ Instance "AMD"
+ </Match>
+ </Page>
+ </Plugin>
+
+In the B<Plugin> block, there may be one or more B<Page> blocks, each defining
+a web page and one or more "matches" to be performed on the returned data. The
+string argument to the B<Page> block is used as plugin instance.
+
+The following options are valid within B<Page> blocks:
+
+=over 4
+
+=item B<URL> I<URL>
+
+URL of the web site to retrieve. Since a regular expression will be used to
+extract information from this data, non-binary data is a big plus here ;)
+
+=item B<User> I<Name>
+
+Username to use if authorization is required to read the page.
+
+=item B<Password> I<Password>
+
+Password to use if authorization is required to read the page.
+
+=item B<VerifyPeer> B<true>|B<false>
+
+Enable or disable peer SSL certificate verification. See
+L<http://curl.haxx.se/docs/sslcerts.html> for details. Enabled by default.
+
+=item B<VerifyHost> B<true>|B<false>
+
+Enable or disable peer host name verification. If enabled, the plugin checks if
+the C<Common Name> or a C<Subject Alternate Name> field of the SSL certificate
+matches the host name provided by the B<URL> option. If this identity check
+fails, the connection is aborted. Obviously, only works when connecting to a
+SSL enabled server. Enabled by default.
+
+=item B<CACert> I<file>
+
+File that holds one or more SSL certificates. If you want to use HTTPS you will
+possibly need this option. What CA certificates come bundled with C<libcurl>
+and are checked by default depends on the distribution you use.
+
+=item B<E<lt>MatchE<gt>>
+
+One or more B<Match> blocks that define how to match information in the data
+returned by C<libcurl>. The C<curl> plugin uses the same infrastructure that's
+used by the C<tail> plugin, so please see the documentation of the C<tail>
+plugin below on how matches are defined.
+
+=back
+
=head2 Plugin C<dbi>
This plugin uses the B<dbi> library (L<http://libdbi.sourceforge.net/>) to
MinVersion 50000
<Result>
Type "gauge"
- InstancePrefix "out_of_stock"
+ InstancePrefix "out_of_stock"
InstancesFrom "category"
ValuesFrom "value"
</Result>
=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> ...]
-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
-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> ...]
=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),
=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
=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
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
=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>
-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)>.
=head1 FILTER CONFIGURATION
-TODO: Update this entire section once development is done.
-
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
-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
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
-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>
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
-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
! 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:
- PostCacheChain "main"
- <Chain "main">
+ PostCacheChain "PostCache"
+ <Chain "PostCache">
<Rule "ignore_mysql_show">
<Match "regex">
Plugin "^mysql$"
: 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
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
=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.
=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.
=item B<write>
-Sends the value to write plugins.
+Sends the value to "write" plugins.
Available options:
=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:
Plugin "^foobar$"
</Match>
+=item B<timediff>
+
+Matches values that have a time which differs from the time on the server.
+
+This match is mainly intended for servers that receive values over the
+C<network> plugin and write them to disk using the C<rrdtool> plugin. RRDtool
+is very sensitive to the timestamp used when updating the RRD files. In
+particular, the time must be ever increasing. If a misbehaving client sends one
+packet with a timestamp far in the future, all further packets with a correct
+time will be ignored because of that one packet. What's worse, such corrupted
+RRD files are hard to fix.
+
+This match lets one match all values B<outside> a specified time range
+(relative to the server's time), so you can use the B<stop> target (see below)
+to ignore the value, for example.
+
+Available options:
+
+=over 4
+
+=item B<Future> I<Seconds>
+
+Matches all values that are I<ahead> of the server's time by I<Seconds> or more
+seconds. Set to zero for no limit. Either B<Future> or B<Past> must be
+non-zero.
+
+=item B<Past> I<Seconds>
+
+Matches all values that are I<behind> of the server's time by I<Seconds> or
+more seconds. Set to zero for no limit. Either B<Future> or B<Past> must be
+non-zero.
+
+=back
+
+Example:
+
+ <Match "timediff">
+ Future 300
+ Past 3600
+ </Match>
+
+This example matches all values that are five minutes or more ahead of the
+server or one hour (or more) lagging behind.
+
=item B<value>
Matches the actual value of data sources against given minimumE<nbsp>/ maximum
B<Chain> block, it will behave as it used to. This is equivalent to the
following configuration:
- <Chain "main">
+ <Chain "PostCache">
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
-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.
- <Chain "main">
+ <Chain "PreCache">
<Rule "no_fqdn">
<Match "regex">
Host "^[^\.]*$"
L<iptables(8)>,
L<kstat(3KSTAT)>,
L<mbmon(1)>,
-L<pcre(3)>,
L<psql(1)>,
L<regex(7)>,
L<rrdtool(1)>,
projects / collectd.git / blobdiff