<Match>
Regex "<span +class=\"pr\"[^>]*> *([0-9]*\\.[0-9]+) *</span>"
DSType "GaugeAverage"
- # Note: `stock_value' is not a standard type.
+ # Note: `stock_value' is not a standard type.
Type "stock_value"
Instance "AMD"
</Match>
MinVersion 50000
<Result>
Type "gauge"
- InstancePrefix "out_of_stock"
+ InstancePrefix "out_of_stock"
InstancesFrom "category"
ValuesFrom "value"
</Result>
use a more strict database server, you may have to select from a dummy table or
something.)
+Please note that some databases, for example B<Oracle>, will fail if you
+include a semicolon at the end of the statement.
+
=item B<MinVersion> I<Version>
=item B<MaxVersion> I<Value>
=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 join together with the dashes I<("-")> as separation character.
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),
The B<Query> block defines one database query which may later be used by a
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<MinPGVersion> and B<MaxPGVersion> options below for an exception to this
+B<MinVersion> and B<MaxVersion> options below for an exception to this
rule). The following configuration options are available to define the query:
In each B<Query> block, there is one or more B<Result> blocks. B<Result>
should be used. The first option specifies the data found in the first column,
the second option that of the second column, and so on.
-=item B<MinPGVersion> I<version>
+=item B<MinVersion> I<version>
-=item B<MaxPGVersion> 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
and patch-level versions, each represented as two-decimal-digit numbers. For
example, version 8.2.3 will become 80203.
+=item B<MinPGVersion> I<version>
+
+=item B<MaxPGVersion> I<version>
+
+These are deprecated synonyms for B<MinVersion> and B<MaxVersion>
+respectively. They will be removed in version 5 of collectd.
+
=back
The following predefined queries are available (the definitions can be found
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<teamspeak2>
-
-The C<teamspeak2 plugin> connects to the query port of a teamspeak2 server and
-polls interesting global and virtual server data. The plugin can query only one
-physical server but unlimited virtual servers. You can use the following
-options to configure it:
-
-=over 4
-
-=item B<Host> I<hostname/ip>
-
-The hostname or ip which identifies the physical server.
-Default: 127.0.0.1
-
-=item B<Port> I<port>
-
-The query port of the physical server. This needs to be a string.
-Default: "51234"
-
-=item B<Server> I<port>
-
-This option has to be added once for every virtual server the plugin should
-query. If you want to query the virtual server on port 8767 this is what the
-option would look like:
-
- Server "8767"
-
-This option, although numeric, needs to be a string, i.E<nbsp>e. you B<must>
-use quotes around it! If no such statement is given only global information
-will be collected.
-
-=back
-
=head2 Plugin C<tcpconns>
The C<tcpconns plugin> counts the number of currently established TCP
=back
+=head2 Plugin C<teamspeak2>
+
+The C<teamspeak2 plugin> connects to the query port of a teamspeak2 server and
+polls interesting global and virtual server data. The plugin can query only one
+physical server but unlimited virtual servers. You can use the following
+options to configure it:
+
+=over 4
+
+=item B<Host> I<hostname/ip>
+
+The hostname or ip which identifies the physical server.
+Default: 127.0.0.1
+
+=item B<Port> I<port>
+
+The query port of the physical server. This needs to be a string.
+Default: "51234"
+
+=item B<Server> I<port>
+
+This option has to be added once for every virtual server the plugin should
+query. If you want to query the virtual server on port 8767 this is what the
+option would look like:
+
+ Server "8767"
+
+This option, although numeric, needs to be a string, i.E<nbsp>e. you B<must>
+use quotes around it! If no such statement is given only global information
+will be collected.
+
+=back
+
=head2 Plugin C<thermal>
=over 4
=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:
: 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:
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