src/collectd-exec.pod

   1 =head1 NAME
   2
   3 collectd-exec - Documentation of collectd's C<exec plugin>
   4
   5 =head1 SYNOPSIS
   6
   7   # See collectd.conf(5)
   8   LoadPlugin exec
   9   # ...
  10   <Plugin exec>
  11     Exec "myuser:mygroup" "myprog"
  12     Exec "otheruser" "/path/to/another/binary" "arg0" "arg1"
  13     NotificationExec "user" "/usr/lib/collectd/exec/handle_notification"
  14     NagiosExec "nagios:nagios" "/usr/lib/nagios/plugins/check_something"
  15   </Plugin>
  16
  17 =head1 DESCRIPTION
  18
  19 The C<exec plugin> forks of an executable either to receive values, to dispatch
  20 notifications to the outside world or to be able to use Nagios plugins. The
  21 syntax of the configuration is explained in L<collectd.conf(5)> but summarized
  22 in the above synopsis.
  23
  24 If you want/need better performance or more functionality you should take a
  25 long look at the C<perl plugin>, L<collectd-perl(5)>.
  26
  27 =head1 EXECUTABLE TYPES
  28
  29 There are currently three types of executables that can be executed by the
  30 C<exec plugin>:
  31
  32 =over 4
  33
  34 =item C<Exec>
  35
  36 These programs are forked and values that it writes to C<STDOUT> are read back.
  37 The executable is forked in a fashion similar to L<init>: It is forked once and
  38 not again until it exits. If it exited, it will be forked again after at most
  39 I<Interval> seconds. It is perfectly legal for the executable to run for a long
  40 time and continuously write values to C<STDOUT>.
  41
  42 See L<EXEC DATA FORMAT> below for a description of the output format expected
  43 from these programs.
  44
  45 B<Warning:> If the executable only writes one value and then exits I will be
  46 executed every I<Interval> seconds. If I<Interval> is short (the default is 10
  47 seconds) this may result in serious system load.
  48
  49 =item C<NotificationExec>
  50
  51 The program is forked once for each notification that is handled by the daemon.
  52 The notification is passed to the program on C<STDIN> in a fashion similar to
  53 HTTP-headers. In contrast to programs specified with C<Exec> the execution of
  54 this program is not serialized, so that several instances of this program may
  55 run at once if multiple notifications are received.
  56
  57 See L<NOTIFICATION DATA FORMAT> below for a description of the data passed to
  58 these programs.
  59
  60 =item C<NagiosExec>
  61
  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
  65 only.
  66
  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.
  70
  71 =back
  72
  73 =head1 EXEC DATA FORMAT
  74
  75 The forked executable is expected to print values to C<STDOUT>. The expected
  76 format is as follows:
  77
  78 =over 4
  79
  80 =item Comments
  81
  82 Each line beginning with a C<#> (hash mark) is ignored.
  83
  84 =item B<PUTVAL> I<Identifier> [I<OptionList>] I<Valuelist>
  85
  86 Submits one or more values (identified by I<Identifier>, see below) to the
  87 daemon which will dispatch it to all it's write-plugins.
  88
  89 An I<Identifier> is of the form
  90 C<I<host>B</>I<plugin>B<->I<instance>B</>I<type>B<->I<instance>> with both
  91 I<instance>-parts being optional. If they're omitted the hyphen must be
  92 omitted, too. I<plugin> and each I<instance>-part may be chosen freely as long
  93 as the tuple (plugin, plugin instance, type instance) uniquely identifies the
  94 plugin within collectd. I<type> identifies the type and number of values
  95 (i.E<nbsp>e. data-set) passed to collectd. A large list of predefined
  96 data-sets is available in the B<types.db> file. See L<types.db(5)> for a
  97 description of the format of this file.
  98
  99 The I<OptionList> is an optional list of I<Options>, where each option if a
 100 key-value-pair. A list of currently understood options can be found below, all
 101 other options will be ignored.
 102
 103 I<Valuelist> is a colon-separated list of the time and the values, each either
 104 an integer if the data-source is a counter, of a double if the data-source if
 105 of type "gauge". You can submit an undefined gauge-value by using B<U>. When
 106 submitting B<U> to a counter the behavior is undefined. The time is given as
 107 epoch (i.E<nbsp>e. standard UNIX time).
 108
 109 You can mix options and values, but the order is important: Options only
 110 effect following values, so specifying an option as last field is allowed, but
 111 useless. Also, an option applies to B<all> following values, so you don't need
 112 to re-set an option over and over again.
 113
 114 The currently defined B<Options> are:
 115
 116 =over 4
 117
 118 =item B<interval=>I<seconds>
 119
 120 Gives the interval in which the data identified by I<Identifier> is being
 121 collected.
 122
 123 =back
 124
 125 Please note that this is the same format as used in the B<unixsock plugin>, see
 126 L<collectd-unixsock(5)>. There's also a bit more information on identifiers in
 127 case you're confused.
 128
 129 Since examples usually let one understand a lot better, here are some:
 130
 131   leeloo/cpu-0/cpu-idle N:2299366
 132   alice/interface/if_octets-eth0 interval=10 1180647081:421465:479194
 133
 134 Since this action was the only one supported with older versions of the C<exec
 135 plugin> all lines were treated as if they were prefixed with B<PUTVAL>. This is
 136 still the case to maintain backwards compatibility but deprecated.
 137
 138 =item B<PUTNOTIF> [I<OptionList>] B<message=>I<Message>
 139
 140 Submits a notification to the daemon which will then dispatch it to all plugins
 141 which have registered for receiving notifications.
 142
 143 The B<PUTNOTIF> if followed by a list of options which further describe the
 144 notification. The B<message> option is special in that it will consume the rest
 145 of the line as its value. The B<message>, B<severity>, and B<time> options are
 146 mandatory.
 147
 148 Valid options are:
 149
 150 =over 4
 151
 152 =item B<message=>I<Message> (B<REQUIRED>)
 153
 154 Sets the message of the notification. This is the message that will be made
 155 accessible to the user, so it should contain some useful information. This
 156 option must be the last option because the rest of the line will be its value,
 157 even if there are spaces and equal-signs following it! This option is
 158 mandatory.
 159
 160 =item B<severity=failure>|B<warning>|B<okay> (B<REQUIRED>)
 161
 162 Sets the severity of the notification. This option is mandatory.
 163
 164 =item B<time=>I<Time> (B<REQUIRED>)
 165
 166 Sets the time of the notification. The time is given as "epoch", i.E<nbsp>e. as
 167 seconds since January 1st, 1970, 00:00:00. This option is mandatory.
 168
 169 =item B<host=>I<Hostname>
 170
 171 =item B<plugin=>I<Plugin>
 172
 173 =item B<plugin_instance=>I<Plugin-Instance>
 174
 175 =item B<type=>I<Type>
 176
 177 =item B<type_instance=>I<Type-Instance>
 178
 179 These "associative" options establish a relation between this notification and
 180 collected performance data. This connection is purely informal, i.E<nbsp>e. the
 181 daemon itself doesn't do anything with this information. However, websites or
 182 GUIs may use this information to place notifications near the affected graph or
 183 table. All the options are optional, but B<plugin_instance> without B<plugin>
 184 or B<type_instance> without B<type> doesn't make much sense and should be
 185 avoided.
 186
 187 Please note that this is the same format as used in the B<unixsock plugin>, see
 188 L<collectd-unixsock(5)>.
 189
 190 =back
 191
 192 When collectd exits it sends a B<SIGTERM> to all still running
 193 child-processes upon which they have to quit.
 194
 195 =head1 NOTIFICATION DATA FORMAT
 196
 197 The notification executables receive values rather than providing them. In
 198 fact, after the program is started C<STDOUT> is connected to C</dev/null>.
 199
 200 The data is passed to the executables over C<STDIN> in a format very similar to
 201 HTTP-headers: There is one line per field. Every line consists of a field name,
 202 ended by a colon, and the associated value until end-of-line. The input is
 203 ended by two newlines immediately following another.
 204
 205 The following is an example notification passed to a program:
 206
 207   Severity: FAILURE
 208   Time: 1200928930
 209   Host: myhost.mydomain.org
 210   Message: This is a test notification to demonstrate the format
 211   <newline>
 212
 213 The following header files are currently used. Please note, however, that you
 214 should ignore unknown header files to be as forward-compatible as possible.
 215
 216 =over 4
 217
 218 =item B<Severity>
 219
 220 Severity of the notification. May either be B<FAILURE>, B<WARNING>, or B<OKAY>.
 221
 222 =item B<Time>
 223
 224 The time in epoch, i.E<nbsp>e. as seconds since 1970-01-01 00:00:00 UTC.
 225
 226 =item B<Host>
 227
 228 Name of the host concerned.
 229
 230 =item B<Message>
 231
 232 Message of the notification. This message should be made accessible to the
 233 user somehow.
 234
 235 =back
 236
 237 =head1 CAVEATS
 238
 239 =over 4
 240
 241 =item
 242
 243 The user, the binary is executed as, may not have root privileges, i.E<nbsp>e.
 244 must have an UID that is non-zero. This is for your own good.
 245
 246 =back
 247
 248 =head1 SEE ALSO
 249
 250 L<collectd(1)>,
 251 L<collectd.conf(5)>,
 252 L<collectd-perl(5)>,
 253 L<collectd-unixsock(5)>,
 254 L<fork(2)>, L<exec(3)>
 255
 256 =head1 AUTHOR
 257
 258 Florian Forster E<lt>octo@verplant.orgE<gt>
 259
 260 =cut