3 collectd-exec - Documentation of collectd's C<exec plugin>
11 Exec "myuser:mygroup" "myprog"
12 Exec "otheruser" "/path/to/another/binary" "arg0" "arg1"
13 NotificationExec "user" "/usr/lib/collectd/exec/handle_notification"
18 The C<exec plugin> forks of an executable either to receive values or to
19 dispatch notifications to the outside world. The syntax of the configuration is
20 explained in L<collectd.conf(5)> but summarized in the above synopsis.
22 If you want/need better performance or more functionality you should take a
23 long look at the C<perl plugin>, L<collectd-perl(5)>.
25 =head1 EXECUTABLE TYPES
27 There are currently two types of executables that can be executed by the
34 These programs are forked and values that it writes to C<STDOUT> are read back.
35 The executable is forked in a fashion similar to L<init>: It is forked once and
36 not again until it exits. If it exited, it will be forked again after at most
37 I<Interval> seconds. It is perfectly legal for the executable to run for a long
38 time and continuously write values to C<STDOUT>.
40 See L<EXEC DATA FORMAT> below for a description of the output format expected
43 B<Warning:> If the executable only writes one value and then exits I will be
44 executed every I<Interval> seconds. If I<Interval> is short (the default is 10
45 seconds) this may result in serious system load.
47 =item C<NotificationExec>
49 The program is forked once for each notification that is handled by the daemon.
50 The notification is passed to the program on C<STDIN> in a fashion similar to
51 HTTP-headers. In contrast to programs specified with C<Exec> the execution of
52 this program is not serialized, so that several instances of this program may
53 run at once if multiple notifications are received.
55 See L<NOTIFICATION DATA FORMAT> below for a description of the data passed to
62 The executable is treated as a Nagios plugin. That means that the first line
63 printed to C<STDOUT> by this program is used as the text of a notification and
64 the severity of the notification depends on the exit status of the executable
67 For information on how to write Nagios plugins please refer to the Nagios
68 documentation. If a plugin works with Nagios but not with collectd please
69 complain on the collectd mailing list instead.
75 =head1 EXEC DATA FORMAT
77 The forked executable is expected to print values to C<STDOUT>. The expected
84 Each line beginning with a C<#> (hash mark) is ignored.
86 =item B<PUTVAL> I<Identifier> [I<OptionList>] I<Valuelist>
88 Submits one or more values (identified by I<Identifier>, see below) to the
89 daemon which will dispatch it to all it's write-plugins.
91 An I<Identifier> is of the form
92 C<I<host>B</>I<plugin>B<->I<instance>B</>I<type>B<->I<instance>> with both
93 I<instance>-parts being optional. If they're omitted the hyphen must be
94 omitted, too. I<plugin> and each I<instance>-part may be chosen freely as long
95 as the tuple (plugin, plugin instance, type instance) uniquely identifies the
96 plugin within collectd. I<type> identifies the type and number of values
97 (i.E<nbsp>e. data-set) passed to collectd. A large list of predefined
98 data-sets is available in the B<types.db> file. See L<types.db(5)> for a
99 description of the format of this file.
101 The I<OptionList> is an optional list of I<Options>, where each option if a
102 key-value-pair. A list of currently understood options can be found below, all
103 other options will be ignored.
105 I<Valuelist> is a colon-separated list of the time and the values, each either
106 an integer if the data-source is a counter, of a double if the data-source if
107 of type "gauge". You can submit an undefined gauge-value by using B<U>. When
108 submitting B<U> to a counter the behavior is undefined. The time is given as
109 epoch (i.E<nbsp>e. standard UNIX time).
111 You can mix options and values, but the order is important: Options only
112 effect following values, so specifying an option as last field is allowed, but
113 useless. Also, an option applies to B<all> following values, so you don't need
114 to re-set an option over and over again.
116 The currently defined B<Options> are:
120 =item B<interval=>I<seconds>
122 Gives the interval in which the data identified by I<Identifier> is being
127 Please note that this is the same format as used in the B<unixsock plugin>, see
128 L<collectd-unixsock(5)>. There's also a bit more information on identifiers in
129 case you're confused.
131 Since examples usually let one understand a lot better, here are some:
133 leeloo/cpu-0/cpu-idle N:2299366
134 alice/interface/if_octets-eth0 interval=10 1180647081:421465:479194
136 Since this action was the only one supported with older versions of the C<exec
137 plugin> all lines were treated as if they were prefixed with B<PUTVAL>. This is
138 still the case to maintain backwards compatibility but deprecated.
140 =item B<PUTNOTIF> [I<OptionList>] B<message=>I<Message>
142 Submits a notification to the daemon which will then dispatch it to all plugins
143 which have registered for receiving notifications.
145 The B<PUTNOTIF> if followed by a list of options which further describe the
146 notification. The B<message> option is special in that it will consume the rest
147 of the line as its value. The B<message>, B<severity>, and B<time> options are
154 =item B<message=>I<Message> (B<REQUIRED>)
156 Sets the message of the notification. This is the message that will be made
157 accessible to the user, so it should contain some useful information. This
158 option must be the last option because the rest of the line will be its value,
159 even if there are spaces and equal-signs following it! This option is
162 =item B<severity=failure>|B<warning>|B<okay> (B<REQUIRED>)
164 Sets the severity of the notification. This option is mandatory.
166 =item B<time=>I<Time> (B<REQUIRED>)
168 Sets the time of the notification. The time is given as "epoch", i.E<nbsp>e. as
169 seconds since January 1st, 1970, 00:00:00. This option is mandatory.
171 =item B<host=>I<Hostname>
173 =item B<plugin=>I<Plugin>
175 =item B<plugin_instance=>I<Plugin-Instance>
177 =item B<type=>I<Type>
179 =item B<type_instance=>I<Type-Instance>
181 These "associative" options establish a relation between this notification and
182 collected performance data. This connection is purely informal, i.E<nbsp>e. the
183 daemon itself doesn't do anything with this information. However, websites or
184 GUIs may use this information to place notifications near the affected graph or
185 table. All the options are optional, but B<plugin_instance> without B<plugin>
186 or B<type_instance> without B<type> doesn't make much sense and should be
189 Please note that this is the same format as used in the B<unixsock plugin>, see
190 L<collectd-unixsock(5)>.
194 When collectd exits it sends a B<SIGTERM> to all still running
195 child-processes upon which they have to quit.
197 =head1 NOTIFICATION DATA FORMAT
199 The notification executables receive values rather than providing them. In
200 fact, after the program is started C<STDOUT> is connected to C</dev/null>.
202 The data is passed to the executables over C<STDIN> in a format very similar to
203 HTTP: At first there is a "header" with one line per field. Every line consists
204 of a field name, ended by a colon, and the associated value until end-of-line.
205 The "header" is ended by two newlines immediately following another,
206 i.E<nbsp>e. an empty line. The rest, basically the "body", is the message of
209 The following is an example notification passed to a program:
213 Host: myhost.mydomain.org
215 This is a test notification to demonstrate the format
217 The following header files are currently used. Please note, however, that you
218 should ignore unknown header files to be as forward-compatible as possible.
224 Severity of the notification. May either be B<FAILURE>, B<WARNING>, or B<OKAY>.
228 The time in epoch, i.E<nbsp>e. as seconds since 1970-01-01 00:00:00 UTC.
234 =item B<PluginInstance>
238 =item B<TypeInstance>
240 Identification of the performance data this notification is associated with.
241 All of these fields are optional because notifications do not B<need> to be
242 associated with a certain value.
252 The user, the binary is executed as, may not have root privileges, i.E<nbsp>e.
253 must have an UID that is non-zero. This is for your own good.
262 L<collectd-unixsock(5)>,
263 L<fork(2)>, L<exec(3)>
267 Florian Forster E<lt>octo@verplant.orgE<gt>