Difference between revisions of "Plain text protocol"
(→collectd-unixsock.py: Use the "GitFile" template.)
(→Description: Add wikilink to "Identifier".)
|Line 32:||Line 32:|
==== Description ====
==== Description ====
If the value identified by
If the value identified by Identifieris found the complete <em>value-list</em> is returned. If the <em>Identifier</em> contains any spaces, it <em>must</em> be enclosed in double quotes. The response is a list of name-value-pairs, each pair on its own line (the number of lines is indicated by the status line — see above). Each name-value-pair is of the form <code>name=value</code>. Counter-values are converted to a rate, e. g. bytes per second. Undefined values are returned as "NaN".
==== Example ====
==== Example ====
Revision as of 16:09, 15 July 2009
- 1 Description
- 2 Replies
- 3 Requests
- 3.1 GETVAL
- 3.2 LISTVAL
- 3.3 PUTVAL
- 3.4 PUTNOTIF
- 3.5 FLUSH
- 4 Abstraction layers
This page described the plain text protocol used by some plugins to provide communication channels to the outside world. Using this protocol it is possible to submit statistics and notifications to the daemon as well as query the current value of collected statistics. Plugins currently using this protocol are Exec (partially) and UnixSock. A client-side implementation of this protocol is available as the collectdclient library starting with version 4.6.
Let's start with the replies, because they are simple and generic: Upon each request, the server answers with a one-line status message and possibly additional lines. The status message consists of a numeric status code, a space and a informative message.
42 Answer to Life, the Universe, and Everything.
The status code is less than zero to signal failure and greater than or equal to zero to signal success. If the value is greater than or equal to zero, it indicates the number of lines that are following the initial status message.
3 Success foo bar baz
Note that these status messages are never actually passed to the Exec plugin. If you write a script or program to be used with the Exec plugin, you don't have to worry about return values at all.
Now that we know how the daemon will answer, let's see what we can ask it.
If the value identified by Identifier is found the complete value-list is returned. If the Identifier contains any spaces, it must be enclosed in double quotes. The response is a list of name-value-pairs, each pair on its own line (the number of lines is indicated by the status line — see above). Each name-value-pair is of the form
name=value. Counter-values are converted to a rate, e. g. bytes per second. Undefined values are returned as "NaN".
-> | GETVAL "myhost/cpu-0/cpu-user" <- | 1 Value found <- | value=1.260000e+00
- UnixSock plugin
Returns a list of the values available in the value cache together with the time of their last update, so that querying applications can issue a
GETVAL command for the values that have changed. Each return value consists of the update time as an epoch value and the identifier, separated by a space. The update time is the time of the last value, as provided by the collecting instance and may be very different from the time the server considers to be "now".
-> | LISTVAL <- | 69 Values found <- | 1182204284 myhost/cpu-0/cpu-idle <- | 1182204284 myhost/cpu-0/cpu-nice <- | 1182204284 myhost/cpu-0/cpu-system <- | 1182204284 myhost/cpu-0/cpu-user ...
- UnixSock plugin
PUTVAL Identifier [OptionList] Valuelist
Submits one or more values (identified by Identifier) to the daemon which will dispatch it to all it’s write plugins.
The OptionList is an optional list of Options, where each option is a key-value-pair. A list of currently understood options can be found below, all other options will be ignored. Values that contain spaces must be quoted with double quotes.
Valuelist is a colon-separated list of the time and the values, each either an integer if the data-source is a counter, or a double if the data-source is of type "gauge". You can submit an undefined gauge-value by using "U". When submitting "U" to a counter the behavior is undefined. The time is given as epoch (i. e. standard UNIX time).
You can mix options and values, but the order is important: Options only effect following values, so specifying an option as last field is allowed, but useless. Also, an option applies to all following values, so you don’t need to re-set an option over and over again.
The currently defined Options are:
Gives the interval in which the data identified by Identifier is being collected.
-> | PUTVAL "testhost/interface/if_octets-test0" interval=10 1179574444:123:456 <- | 0 Success
PUTNOTIF [OptionList] message=Message
Submits a notification to the daemon which will then dispatch it to all plugins which have registered for receiving notifications.
PUTNOTIF command is followed by a list of options which further describe the notification. The message option is special in that it will consume the rest of the line as its value. The message, severity, and time options are mandatory.
Valid options are:
- message=Message (Required)
Sets the message of the notification. This is the message that will be made accessible to the user, so it should contain some useful information. As with all options: If the message includes spaces, it must be quoted with double quotes. This option is mandatory.
- severity=failure|warning|okay (Required)
Sets the severity of the notification. This option is mandatory.
- time=Time (Required)
Sets the time of the notification. The time is given as "epoch", i. e. as seconds since January 1st, 1970, 00:00:00. This option is mandatory.
These "associative" options establish a relation between this notification and collected performance data. This connection is purely informal, i. e. the daemon itself doesn't do anything with this information. However, websites or GUIs may use this information to place notifications near the affected graph or table. All the options are optional, but plugin_instance without plugin or type_instance without type doesn't make much sense and should be avoided.
-> | PUTNOTIF type=temperature severity=warning time=1201094702 message="The roof is on fire!" <- | 0 Success
FLUSH [timeout=Timeout] [plugin=Plugin [...]] [identifier=Ident [...]]
Flushes all cached data older than Timeout seconds. If no timeout has been specified, it defaults to "-1" which causes all data to be flushed.
If the plugin option has been specified, only the Plugin plugin will be flushed. You can have multiple plugin options to flush multiple plugins in one go. If the plugin option is not given all plugins providing a flush callback will be flushed.
If the identifier option is given only the specified values will be flushed. This is meant to be used by graphing or displaying front-ends which want to have the latest values for a specific graph. Again, you can specify the identifier option multiple times to flush several values. If this option is not specified at all, all values will be flushed.
-> | FLUSH plugin=rrdtool identifier="localhost/df/df-root" identifier="localhost/df/df-var" <- | 0 Done: 2 successful, 0 errors
- UnixSock plugin
There are currently three libraries available which implement this protocol and provide a high level interface to the daemon.
The collectdclient library was added in collectd 4.6 and is installed automatically. It provides access to the daemon via this plain text protocol for C and C++ programs. Its main header file is
collectd/client.h, which is hopefully straight forward.
This Perl module provides a pure-Perl implementation of the above protocol. It is used for example by the contributed collection3 script to flush values just before creating the graph. Documentation is available as inline-POD, which you can access using:
This Python module provides a pure-Python interface for the
GETVAL commands. The other commands should be easy to add to this module, too. This file can be found at contrib/collectd-unixsock.py.