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