X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=src%2Fcollectd.conf.pod;h=1c0f4f07055942703f1e00e007db315f6ecadc76;hb=483e801902bca3c779793224eddf3bb2749d7288;hp=589e1694c080a3944486020dcd471b9a5df16823;hpb=d26335bfea97b4bd49f6f964b8bd7239386e2b88;p=collectd.git diff --git a/src/collectd.conf.pod b/src/collectd.conf.pod index 589e1694..1c0f4f07 100644 --- a/src/collectd.conf.pod +++ b/src/collectd.conf.pod @@ -823,7 +823,7 @@ The B uses B (L) and B In the B block, there may be one or more B blocks, each defining a -URL to be fetched via HTTP (using libcurl). Within each B block there are +URL to be fetched using libcurl. Within each B block there are options which specify the connection parameters, for example authentication information, and one or more B blocks. @@ -2063,8 +2063,10 @@ Hostname of the database server. Defaults to B. =item B I Username to use when connecting to the database. The user does not have to be -granted any privileges (which is synonym to granting the C privilege). -Any existing MySQL user will do. +granted any privileges (which is synonym to granting the C privilege), +unless you want to collectd replication statistics (see B and +B below). In this case, the user needs the C +(or C) privileges. Else, any existing MySQL user will do. =item B I @@ -2096,7 +2098,9 @@ C function for details. =item B I -Enable the collection of master / slave statistics in a replication setup. +Enable the collection of master / slave statistics in a replication setup. In +order to be able to get access to these statistics, the user needs special +privileges. See the B documentation above. =item B I @@ -2650,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" @@ -2782,7 +2794,18 @@ operating systems. =item B I<1024-65535> Set the maximum size for datagrams received over the network. Packets larger -than this will be truncated. Defaults to 1452Ebytes. +than this will be truncated. Defaults to 1452Ebytes, which is the maximum +payload size that can be transmitted in one Ethernet frame using IPv6E/ +UDP. + +On the server side, this limit should be set to the largest value used on +I client. Likewise, the value on the client must not be larger than the +value on the server, or data will be lost. + +B Versions prior to I4.8> used a fixed sized +buffer of 1024Ebytes. Versions I<4.8>, I<4.9> and I<4.10> used a default +value of 1024Ebytes to avoid problems when sending data to an older +server. =item B I @@ -2854,7 +2877,8 @@ and are checked by default depends on the distribution you use. This plugin sends a desktop notification to a notification daemon, as defined in the Desktop Notification Specification. To actually display the notifications, B is required and B has to be -able to access the X server. +able to access the X server (i.Ee., the C and C +environment variables have to be set correctly) and the D-Bus message bus. The Desktop Notification Specification can be found at L. @@ -4172,34 +4196,20 @@ L. Please see there for details. =head2 Plugin C The I collects information about used and available swap space. On -Solaris, it is possible to collect information on physical swap devices and the -view of the virtual memory subsystem on the matter. On I, the -following options are available: +I, the following options are available: =over 4 -=item B B|B|B +=item B B|B -Configures how to report physical swap devices. If B is used (the +Configures how to report physical swap devices. If set to B 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 is configured, the -used and available space of each device will be reported separately. B -deactivates collection of physical swap information (only valid if collection -via L is available). +used and available space over all devices. If B is configured, the used +and available space of each device will be reported separately. This option is only available if the I can use the L mechanism under I. -=item B B|B - -Configures whether or not to report the view of the virtual memory subsystem on -swap space. This information is used under Solaris if L is not -available and was the default behavior under I in I4>. - -This option is only available if the I can use L and -L to collect swap statistics under I. It defaults to -B. - =back =head2 Plugin C @@ -4829,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