rrdtool plugin¶

See this section in the full configuration reference

You can use the settings StepSize, HeartBeat, RRARows, and XFF to fine-tune your RRD-files. Please read rrdcreate(1) if you encounter problems using these settings. If you don't want to dive into the depths of RRDtool, you can safely ignore these settings.

DataDir Directory

Set the directory to store RRD files under. By default RRD files are generated beneath the daemon's working directory, i.e. the BaseDir.

CreateFilesAsync false|true

When enabled, new RRD files are enabled asynchronously, using a separate thread that runs in the background. This prevents writes to block, which is a problem especially when many hundreds of files need to be created at once. However, since the purpose of creating the files asynchronously is not to block until the file is available, values before the file is available will be discarded. When disabled (the default) files are created synchronously, blocking for a short while, while the file is being written.

StepSize Seconds

Force the stepsize of newly created RRD-files. Ideally (and per default) this setting is unset and the stepsize is set to the interval in which the data is collected. Do not use this option unless you absolutely have to for some reason. Setting this option may cause problems with the snmp plugin, the exec plugin or when the daemon is set up to receive data from other hosts.

HeartBeat Seconds

Force the heartbeat of newly created RRD-files. This setting should be unset in which case the heartbeat is set to twice the StepSize which should equal the interval in which data is collected. Do not set this option unless you have a very good reason to do so.

RRARows NumRows

The rrdtool plugin calculates the number of PDPs per CDP based on the StepSize, this setting and a timespan. This plugin creates RRD-files with three times five RRAs, i.e. five RRAs with the CFs MIN, AVERAGE, and MAX. The five RRAs are optimized for graphs covering one hour, one day, one week, one month, and one year.

So for each timespan, it calculates how many PDPs need to be consolidated into one CDP by calculating: number of PDPs = timespan / (stepsize * rrarows)

Bottom line is, set this no smaller than the width of you graphs in pixels. The default is 1200.

RRATimespan Seconds

Adds an RRA-timespan, given in seconds. Use this option multiple times to have more then one RRA. If this option is never used, the built-in default of (3600, 86400, 604800, 2678400, 31622400) is used.

For more information on how RRA-sizes are calculated see RRARows above.

XFF Factor

Set the "XFiles Factor". The default is 0.1. If unsure, don't set this option. Factor must be in the range [0.0-1.0), i.e. between zero (inclusive) and one (exclusive).

CacheFlush Seconds

When the rrdtool plugin uses a cache (by setting CacheTimeout, see below) it writes all values for a certain RRD-file if the oldest value is older than (or equal to) the number of seconds specified by CacheTimeout. That check happens on new values arriwal. If some RRD-file is not updated anymore for some reason (the computer was shut down, the network is broken, etc.) some values may still be in the cache. If CacheFlush is set, then every Seconds seconds the entire cache is searched for entries older than CacheTimeout + RandomTimeout seconds. The entries found are written to disk. Since scanning the entire cache is kind of expensive and does nothing under normal circumstances, this value should not be too small. 900 seconds might be a good value, though setting this to 7200 seconds doesn't normally do much harm either.

Defaults to 10x CacheTimeout. CacheFlush must be larger than or equal to CacheTimeout, otherwise the above default is used.

CacheTimeout Seconds

If this option is set to a value greater than zero, the rrdtool plugin will save values in a cache, as described above. Writing multiple values at once reduces IO-operations and thus lessens the load produced by updating the files. The trade off is that the graphs kind of "drag behind" and that more memory is used.

WritesPerSecond Updates

When collecting many statistics with collectd and the rrdtool plugin, you will run serious performance problems. The CacheFlush setting and the internal update queue assert that collectd continues to work just fine even under heavy load, but the system may become very unresponsive and slow. This is a problem especially if you create graphs from the RRD files on the same machine, for example using the graph.cgi script included in the contrib/collection3/ directory.

This setting is designed for very large setups. Setting this option to a value between 25 and 80 updates per second, depending on your hardware, will leave the server responsive enough to draw graphs even while all the cached values are written to disk. Flushed values, i. e. values that are forced to disk by the FLUSH command, are not effected by this limit. They are still written as fast as possible, so that web frontends have up to date data when generating graphs.

For example: If you have 100,000 RRD files and set WritesPerSecond to 30 updates per second, writing all values to disk will take approximately 56E<nbsp>minutes. Together with the flushing ability that's integrated into "collection3" you'll end up with a responsive and fast system, up to date graphs and basically a "backup" of your values every hour.

RandomTimeout Seconds

When set, the actual timeout for each value is chosen randomly between CacheTimeout-RandomTimeout and CacheTimeout+RandomTimeout. The intention is to avoid high load situations that appear when many values timeout at the same time. This is especially a problem shortly after the daemon starts, because all values were added to the internal cache at roughly the same time.