X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=src%2Fcollectd.conf.pod;h=f85c7e799291354756f04ce53c022cfd386fb147;hb=4371ef7f98f6f51ea3df34d5e26e175d6b44a328;hp=e7913ac9631527f96c93dadf3ec19442f200b097;hpb=454587041ce66b416536b45aaa3b4aa956ba9554;p=collectd.git diff --git a/src/collectd.conf.pod b/src/collectd.conf.pod index e7913ac9..f85c7e79 100644 --- a/src/collectd.conf.pod +++ b/src/collectd.conf.pod @@ -1,17 +1,26 @@ +=encoding UTF-8 + =head1 NAME collectd.conf - Configuration for the system statistics collection daemon B =head1 SYNOPSIS - BaseDir "/path/to/data/" - PIDFile "/path/to/pidfile/collectd.pid" - Server "123.123.123.123" 12345 - + BaseDir "/var/lib/collectd" + PIDFile "/run/collectd.pid" + Interval 10.0 + LoadPlugin cpu LoadPlugin load + + + Interval 3600 + + + ValuesPercentage true + + LoadPlugin ping - Host "example.org" Host "provider.net" @@ -22,7 +31,9 @@ collectd.conf - Configuration for the system statistics collection daemon B behaves. The most significant option is B, which controls which plugins to load. These plugins ultimately define collectd's -behavior. +behavior. If the B option has been enabled, the explicit +B lines may be omitted for all plugins with a configuration block, +i.e. a CPluginE...E> block. The syntax of this config file is similar to the config file of the famous I webserver. Each line contains either an option (a key and a list of @@ -49,8 +60,9 @@ indenting the wrapped lines. The configuration is read and processed in order, i.e. from top to bottom. So the plugins are loaded in the order listed in this config file. It is a good idea to load any logging plugins first in order to catch messages from plugins -during configuration. Also, the C option B occur B -the appropriate CPlugin ...E> block. +during configuration. Also, unless B is enabled, the +B option I occur I the appropriate +CB ...E> block. =head1 GLOBAL OPTIONS @@ -64,16 +76,32 @@ directory for the daemon. =item B I -Loads the plugin I. There must be at least one such line or B -will be mostly useless. +Loads the plugin I. This is required to load plugins, unless the +B option is enabled (see below). Without any loaded plugins, +I will be mostly useless. -Starting with collectd 4.9, this may also be a block in which further options -affecting the behavior of B may be specified. The following -options are allowed inside a B block: +Only the first B statement or block for a given plugin name has any +effect. This is useful when you want to split up the configuration into smaller +files and want each file to be "self contained", i.e. it contains a B +block I then appropriate B statement. The downside is that if +you have multiple conflicting B blocks, e.g. when they specify +different intervals, only one of them (the first one encountered) will take +effect and all others will be silently ignored. - - Globals true - +B may either be a simple configuration I or a I +with additional options, affecting the behavior of B. A simple +statement looks like this: + + LoadPlugin "cpu" + +Options inside a B block can override default settings and +influence the way plugins are loaded, e.g.: + + + Interval 60 + + +The following options are valid inside B blocks: =over 4 @@ -82,19 +110,42 @@ options are allowed inside a B block: If enabled, collectd will export all global symbols of the plugin (and of all libraries loaded as dependencies of the plugin) and, thus, makes those symbols available for resolving unresolved symbols in subsequently loaded plugins if -that is supported by your system. By default, this is disabled. +that is supported by your system. -This is useful (or possibly even required), e.Eg., when loading a plugin -that embeds some scripting language into the daemon (e.Eg. the C -or C plugins). Scripting languages usually provide means to load +This is useful (or possibly even required), e.g., when loading a plugin that +embeds some scripting language into the daemon (e.g. the I and +I). Scripting languages usually provide means to load extensions written in C. Those extensions require symbols provided by the -interpreter, which is loaded as a dependency of the respective collectd -plugin. See the documentation of those plugins (e.Eg., -L or L) for details. +interpreter, which is loaded as a dependency of the respective collectd plugin. +See the documentation of those plugins (e.g., L or +L) for details. + +By default, this is disabled. As a special exception, if the plugin name is +either C or C, the default is changed to enabled in order to keep +the average user from ever having to deal with this low level linking stuff. + +=item B I + +Sets a plugin-specific interval for collecting metrics. This overrides the +global B setting. If a plugin provides own support for specifying an +interval, that setting will take precedence. =back -=item B I +=item B B|B + +When set to B (the default), each plugin needs to be loaded explicitly, +using the B statement documented above. If a +BPluginE...E> block is encountered and no configuration +handling callback for this plugin has been registered, a warning is logged and +the block is ignored. + +When set to B, explicit B statements are not required. Each +BPluginE...E> block acts as if it was immediately preceded by a +B statement. B statements are still required for +plugins that don't provide any configuration, e.g. the I. + +=item B I [I] If I points to a file, includes that file. If I points to a directory, recursively includes all files within that directory and its @@ -104,6 +155,27 @@ use statements like the following: Include "/etc/collectd.d/*.conf" +Starting with version 5.3, this may also be a block in which further options +affecting the behavior of B may be specified. The following option is +currently allowed: + + + Filter "*.conf" + + +=over 4 + +=item B I + +If the C function is available on your system, a shell-like wildcard +I may be specified to filter which files to include. This may be used +in combination with recursively including a directory to easily be able to +arbitrarily mix configuration files and other documents (e.g. README files). +The given example is similar to the first example above but includes all files +matching C<*.conf> in any subdirectory of C. + +=back + If more than one files are included by a single B option, the files will be included in lexicographical order (as defined by the C function). Thus, you can e.Eg. use numbered prefixes to specify the @@ -151,14 +223,50 @@ missing when no update has been received for twice the update interval. Since this setting uses iterations, the maximum allowed time without update depends on the I information contained in each value list. This is used in the I configuration to dispatch notifications about missing values, -see L<"THRESHOLD CONFIGURATION"> below. +see L for details. =item B I Number of threads to start for reading plugins. The default value is B<5>, but you may want to increase this if you have more than five plugins that take a -long time to read. Mostly those are plugin that do network-IO. Setting this to -a value higher than the number of plugins you've loaded is totally useless. +long time to read. Mostly those are plugins that do network-IO. Setting this to +a value higher than the number of registered read callbacks is not recommended. + +=item B I + +Number of threads to start for dispatching value lists to write plugins. The +default value is B<5>, but you may want to increase this if you have more than +five plugins that may take relatively long to write to. + +=item B I + +=item B I + +Metrics are read by the I and then put into a queue to be handled +by the I. If one of the I is slow (e.g. network +timeouts, I/O saturation of the disk) this queue will grow. In order to avoid +running into memory issues in such a case, you can limit the size of this +queue. + +By default, there is no limit and memory may grow indefinitely. This is most +likely not an issue for clients, i.e. instances that only handle the local +metrics. For servers it is recommended to set this to a non-zero value, though. + +You can set the limits using B and B. +Each of them takes a numerical argument which is the number of metrics in the +queue. If there are I metrics in the queue, any new metrics I be +dropped. If there are less than I metrics in the queue, all new metrics +I be enqueued. If the number of metrics currently in the queue is between +I and I, the metric is dropped with a probability that is +proportional to the number of metrics in the queue (i.e. it increases linearly +until it reaches 100%.) + +If B is set to non-zero and B is +unset, the latter will default to half of B. + +If you do not want to randomly drop values when the queue size is between +I and I, set If B and +B to same value. =item B I @@ -169,13 +277,8 @@ hostname will be determined using the L system call. If B is determined automatically this setting controls whether or not the daemon should try to figure out the "fully qualified domain name", FQDN. -This is done using a lookup of the name returned by C. - -Using this feature (i.Ee. setting this option to B) is recommended. -However, to preserve backwards compatibility the default is set to B. -The sample config file that is installed with Cinstall> includes a -line which sets this option, though, so that default installations will have -this setting enabled. +This is done using a lookup of the name returned by C. This option +is enabled by default. =item B I @@ -194,12 +297,360 @@ C-Section. Which options exist depends on the plugin used. Some plugins require external configuration, too. The C, for example, required C to be configured in the webserver you're going to collect data from. These plugins are listed below as well, even if they don't -require any configuration within collectd's configfile. +require any configuration within collectd's configuration file. A list of all plugins and a short summary for each plugin can be found in the F file shipped with the sourcecode and hopefully binary packets as well. +=head2 Plugin C + +The I makes it possible to aggregate several values into +one using aggregation functions such as I, I, I and I. +This can be put to a wide variety of uses, e.g. average and total CPU +statistics for your entire fleet. + +The grouping is powerful but, as with many powerful tools, may be a bit +difficult to wrap your head around. The grouping will therefore be +demonstrated using an example: The average and sum of the CPU usage across +all CPUs of each host is to be calculated. + +To select all the affected values for our example, set C and +C. The other values are left unspecified, meaning "all values". The +I, I, I, I and I options +work as if they were specified in the C clause of an C