X-Git-Url: https://git.octo.it/?a=blobdiff_plain;ds=sidebyside;f=src%2Fcollectd.conf.pod;h=1c0f4f07055942703f1e00e007db315f6ecadc76;hb=483e801902bca3c779793224eddf3bb2749d7288;hp=1b0c2fd991e81962853e30d6590a52342fd21624;hpb=8991abf98de418b8464aa0f3251b024c9292da96;p=collectd.git diff --git a/src/collectd.conf.pod b/src/collectd.conf.pod index 1b0c2fd9..1c0f4f07 100644 --- a/src/collectd.conf.pod +++ b/src/collectd.conf.pod @@ -2654,10 +2654,18 @@ The default IPv6 multicast group is C. The default IPv4 multicast group is C<239.192.74.66>. The default I port is B<25826>. Both, B and B can be used as single option or as block. When -used as block, given options are valid for this socket only. For example: +used as block, given options are valid for this socket only. The following +example will export the metrics twice: Once to an "internal" server (without +encryption and signing) and one to an external server (with cryptographic +signature): + # Export to an internal server + # (demonstrates usage without additional options) Server "collectd.internal.tld" + + # Export to an external server + # (demonstrates usage with signature options) SecurityLevel "sign" Username "myhostname" @@ -4831,6 +4839,170 @@ number. =back +=head1 THRESHOLD CONFIGURATION + +Starting with version C<4.3.0> collectd has support for B. 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 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 iterations. The B configuration option is +explained in section L<"GLOBAL OPTIONS">. If, for example, B 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 +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. + + + + WarningMin 0.00 + WarningMax 1000.00 + FailureMin 0.00 + FailureMax 1200.00 + Invert false + Instance "bar" + + + + Instance "eth0" + + FailureMax 10000000 + DataSource "rx" + + + + + + Instance "idle" + FailureMin 10 + + + + + Instance "cached" + WarningMin 100000000 + + + + + +There are basically two types of configuration statements: The C, +C, and C blocks select the value for which a threshold should be +configured. The C and C blocks may be specified further using the +C option. You can combine the block by nesting the blocks, though +they must be nested in the above order, i.Ee. C may contain either +C and C blocks, C may only contain C blocks and +C 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 be +included in a C block. Currently the following statements are recognized: + +=over 4 + +=item B I + +=item B I + +Sets the upper bound of acceptable values. If unset defaults to positive +infinity. If a value is greater than B a B notification +will be created. If the value is greater than B but less than (or +equal to) B a B notification will be created. + +=item B I + +=item B I + +Sets the lower bound of acceptable values. If unset defaults to negative +infinity. If a value is less than B a B notification will +be created. If the value is less than B but greater than (or equal +to) B a B notification will be created. + +=item B I + +Some data sets have more than one "data source". Interesting examples are the +C data set, which has received (C) and sent (C) bytes and +the C data set, which holds C and C operations. The +system load data set, C, even has three data sources: C, +C, and C. + +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 option to have a threshold apply only to +one data source. + +=item B B|B + +If set to B the range of acceptable values is inverted, i.Ee. +values between B and B (B and +B) are not okay. Defaults to B. + +=item B B|B + +Sets how often notifications are generated. If set to B one notification +will be generated for each value that is out of the acceptable range. If set to +B (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 a notification about a +missing value is generated once every B seconds. If set to B +only one such notification is generated until the value appears again. + +=item B B|B + +If set to B, 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% of the total space is available. Defaults to B. + +=item B I + +Delay creating the notification until the threshold has been passed I +times. When a notification has been generated, or when a subsequent value is +inside the threshold, the counter is reset. If, for example, a value is +collected once every 10Eseconds and B is set to 3, a notification +will be dispatched at most once every 30Eseconds. + +This is useful when short bursts are not a problem. If, for example, 100% CPU +usage for up to a minute is normal (and data is collected every +10Eseconds), you could set B to B<6> to account for this. + +=item B I + +When set to non-zero, a hysteresis value is applied when checking minimum and +maximum bounds. This is useful for values that increase slowly and fluctuate a +bit while doing so. When these values come close to the threshold, they may +"flap", i.e. switch between failure / warning case and okay case repeatedly. + +If, for example, the threshold is configures as + + WarningMax 100.0 + Hysteresis 1.0 + +then a I notification is created when the value exceeds I<101> and the +corresponding I notification is only created once the value falls below +I<99>, thus avoiding the "flapping". + +=back + =head1 FILTER CONFIGURATION Starting with collectd 4.6 there is a powerful filtering infrastructure