src/collectd-python.pod

   1 =head1 NAME
   2
   3 collectd-python - Documentation of collectd's C<python plugin>
   4
   5 =head1 SYNOPSIS
   6
   7   <LoadPlugin python>
   8     Globals true
   9   </LoadPlugin>
  10   # ...
  11   <Plugin python>
  12     ModulePath "/path/to/your/python/modules"
  13     LogTraces true
  14     Interactive true
  15     Import "spam"
  16
  17     <Module spam>
  18       spam "wonderful" "lovely"
  19     </Module>
  20   </Plugin>
  21
  22 =head1 DESCRIPTION
  23
  24 The C<python plugin> embeds a Python-interpreter into collectd and provides an
  25 interface to collectd's plugin system. This makes it possible to write plugins
  26 for collectd in Python. This is a lot more efficient than executing a
  27 Python-script every time you want to read a value with the C<exec plugin> (see
  28 L<collectd-exec(5)>) and provides a lot more functionality, too.
  29
  30 Currently only I<Python 2> is supported and at least I<version 2.3> is
  31 required.
  32
  33 =head1 CONFIGURATION
  34
  35 =over 4
  36
  37 =item B<LoadPlugin> I<Plugin>
  38
  39 Loads the Python plugin I<Plugin>. Unlike most other LoadPlugin lines, this one
  40 should be a block containing the line "Globals true". This will cause collectd
  41 to export the name of all objects in the python interpreter for all plugins to
  42 see. If you don't do this or your platform does not support it, the embeded
  43 interpreter will start anywa but you won't be able to load certain python
  44 modules, e.g. "time".
  45
  46 =item B<Encoding> I<Name>
  47
  48 The default encoding for Unicode objects you pass to collectd. If you omit this
  49 option it will default to B<ascii> on I<Python 2> and B<utf-8> on I<Python 3>.
  50 This is hardcoded in Python and will ignore everything else, including your
  51 locale.
  52
  53 =item B<ModulePath> I<Name>
  54
  55 Appends I<Name> to B<sys.path>. You won't be able to import any scripts you
  56 wrote unless they are located in one of the directories in this list. Please
  57 note that it only has effect on plugins loaded after this option.
  58
  59 =item B<LogTraces> I<bool>
  60
  61 If a python script throws an exception it will be logged by collectd with the
  62 name of the exception and the message. If you set this option to true it will
  63 also log the full stacktrace just like the default output of an interactive
  64 python interpreter. This should probably be set to false most of the time but
  65 is very useful for development and debugging of new modules.
  66
  67 =item B<Interactive> I<bool>
  68
  69 This option will cause the module to launch an interactive python interpreter
  70 that reads from and writes to the terminal. Note that collectd will terminate
  71 right after starting up if you try to run it as a daemon while this option is
  72 enabled to make sure to start collectd with the B<-f> option.
  73
  74 The B<collectd> module is I<not> imported into the interpreter's globals. You
  75 have to do it manually. Be sure to read the help text of the module, it can be
  76 used as a reference guide during coding.
  77
  78 This interactive session will behave slightly differently from a daemonized
  79 collectd script as well as from a normal python interpreter:
  80
  81 =over 4
  82
  83 =item
  84
  85 B<1.> collectd will try to import the B<readline> module to give you a decent
  86 way of entering your commands. The daemonized collectd won't do that.
  87
  88 =item
  89
  90 B<2.> collectd will block I<SIGINT>. Pressing I<Ctrl+C> will usually cause
  91 collectd to shut down. This would be problematic in an interactive session,
  92 therefore this signal will be blocked. You can still use it to interrupt
  93 syscalls like sleep and pause but it won't generate a I<KeyboardInterrupt>
  94 exception either.
  95
  96 To quit collectd send I<EOF> (press I<Ctrl+D> at the beginning of a new line).
  97
  98 =back
  99
 100 =item E<lt>B<Module> I<Name>E<gt> block
 101
 102 This block may be used to pass on configuration settings to a Python module.
 103 The configuration is converted into an instance of the B<Config> class which is
 104 passed to the registered configuration callback. See below for details about
 105 the B<Config> class and how to register callbacks.
 106
 107 The I<name> identifies the callback.
 108
 109 =back
 110
 111 =head1 WRITING YOUR OWN PLUGINS
 112
 113 Writing your own plugins is quite simple. collectd manages plugins by means of
 114 B<dispatch functions> which call the appropriate B<callback functions>
 115 registered by the plugins. Any plugin basically consists of the implementation
 116 of these callback functions and initializing code which registers the
 117 functions with collectd. See the section "EXAMPLES" below for a really basic
 118 example. The following types of B<callback functions> are known to collectd
 119 (all of them are optional):
 120
 121 =over 4
 122
 123 =item configuration functions
 124
 125 This type of functions is called during configuration if an appropriate
 126 B<Module> block has been encountered. It is called once for each B<Module>
 127 block which matches the name of the callback as provided with the
 128 B<register_config> method - see below.
 129
 130 Python thread support has not been initialized at this point so do not use any
 131 threading functions here!
 132
 133 =item init functions
 134
 135 This type of functions is called once after loading the module and before any
 136 calls to the read and write functions. It should be used to initialize the
 137 internal state of the plugin (e.E<nbsp>g. open sockets, ...). This is the
 138 earliest point where you may use threads.
 139
 140 =item read functions
 141
 142 This type of function is used to collect the actual data. It is called once
 143 per interval (see the B<Interval> configuration option of collectd). Usually
 144 it will call B<plugin_dispatch_values> to dispatch the values to collectd
 145 which will pass them on to all registered B<write functions>. If this function
 146 throws any kind of exception the plugin will be skipped for an increasing
 147 amount of time until it returns normally again.
 148
 149 =item write functions
 150
 151 This type of function is used to write the dispatched values. It is called
 152 once for every value that was dispatched by any plugin.
 153
 154 =item flush functions
 155
 156 This type of function is used to flush internal caches of plugins. It is
 157 usually triggered by the user only. Any plugin which caches data before
 158 writing it to disk should provide this kind of callback function.
 159
 160 =item log functions
 161
 162 This type of function is used to pass messages of plugins or the daemon itself
 163 to the user.
 164
 165 =item notification function
 166
 167 This type of function is used to act upon notifications. In general, a
 168 notification is a status message that may be associated with a data instance.
 169 Usually, a notification is generated by the daemon if a configured threshold
 170 has been exceeded (see the section "THRESHOLD CONFIGURATION" in
 171 L<collectd.conf(5)> for more details), but any plugin may dispatch
 172 notifications as well.
 173
 174 =item shutdown functions
 175
 176 This type of function is called once before the daemon shuts down. It should
 177 be used to clean up the plugin (e.g. close sockets, ...).
 178
 179 =back
 180
 181 Any function (except log functions) may set throw an exception in case of any
 182 errors. The exception will be passed on to the user using collectd's logging
 183 mechanism. If a log callback throws an exception it will be printed to standard
 184 error instead.
 185
 186 See the documentation of the various B<register_> methods in the section
 187 "FUNCTIONS" below for the number and types of arguments passed to each
 188 B<callback function>. This section also explains how to register B<callback
 189 functions> with collectd.
 190
 191 To enable a module, copy it to a place where Python can find it (i.E<nbsp>e. a
 192 directory listed in B<sys.path>) just as any other Python plugin and add
 193 an appropriate B<Import> option to the configuration file. After restarting
 194 collectd you're done.
 195
 196 =head1 CLASSES
 197
 198 The following complex types are used to pass values between the Python plugin
 199 and collectd:
 200
 201 =head2 Config
 202
 203 The Config class is an object which keeps the informations provided in the
 204 configuration file. The sequence of children keeps one entry for each
 205 configuration option. Each such entry is another Config instance, which
 206 may nest further if nested blocks are used.
 207
 208  class Config(object)
 209
 210 This represents a piece of collectd's config file. It is passed to scripts with
 211 config callbacks (see B<register_config>) and is of little use if created
 212 somewhere else.
 213
 214 It has no methods beyond the bare minimum and only exists for its data members.
 215
 216 Data descriptors defined here:
 217
 218 =over 4
 219
 220 =item parent
 221
 222 This represents the parent of this node. On the root node
 223 of the config tree it will be None.
 224
 225 =item key
 226
 227 This is the keyword of this item, i.e. the first word of any given line in the
 228 config file. It will always be a string.
 229
 230 =item values
 231
 232 This is a tuple (which might be empty) of all value, i.e. words following the
 233 keyword in any given line in the config file.
 234
 235 Every item in this tuple will be either a string or a float or a boolean,
 236 depending on the contents of the configuration file.
 237
 238 =item children
 239
 240 This is a tuple of child nodes. For most nodes this will be empty. If this node
 241 represents a block instead of a single line of the config file it will contain
 242 all nodes in this block.
 243
 244 =back
 245
 246 =head2 PluginData
 247
 248 This should not be used directly but it is the base class for both Values and
 249 Notification. It is used to identify the source of a value or notification.
 250
 251  class PluginData(object)
 252
 253 This is an internal class that is the base for Values and Notification. It is
 254 pretty useless by itself and was therefore not exported to the collectd module.
 255
 256 Data descriptors defined here:
 257
 258 =over 4
 259
 260 =item host
 261
 262 The hostname of the host this value was read from. For dispatching this can be
 263 set to an empty string which means the local hostname as defined in
 264 collectd.conf.
 265
 266 =item plugin
 267
 268 The name of the plugin that read the data. Setting this member to an empty
 269 string will insert "python" upon dispatching.
 270
 271 =item plugin_instance
 272
 273 Plugin instance string. May be empty.
 274
 275 =item time
 276
 277 This is the Unix timestamp of the time this value was read. For dispatching
 278 values this can be set to zero which means "now". This means the time the value
 279 is actually dispatched, not the time it was set to 0.
 280
 281 =item type
 282
 283 The type of this value. This type has to be defined in your I<types.db>.
 284 Attempting to set it to any other value will raise a I<TypeError> exception.
 285 Assigning a type is mandatory, calling dispatch without doing so will raise a
 286 I<RuntimeError> exception.
 287
 288 =item type_instance
 289
 290 Type instance string. May be empty.
 291
 292 =back
 293
 294 =head2 Values
 295
 296 A Value is an object which features a sequence of values. It is based on then
 297 I<PluginData> type and uses its members to identify the values.
 298
 299  class Values(PluginData)
 300
 301 A Values object used for dispatching values to collectd and receiving values
 302 from write callbacks.
 303
 304 Method resolution order:
 305
 306 =over 4
 307
 308 =item Values
 309
 310 =item PluginData
 311
 312 =item object
 313
 314 =back
 315
 316 Methods defined here:
 317
 318 =over 4
 319
 320 =item B<dispatch>([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.
 321
 322 Dispatch this instance to the collectd process. The object has members for each
 323 of the possible arguments for this method. For a detailed explanation of these
 324 parameters see the member of the same same.
 325
 326 If you do not submit a parameter the value saved in its member will be
 327 submitted. If you do provide a parameter it will be used instead, without
 328 altering the member.
 329
 330 =item B<write>([destination][, type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.
 331
 332 Write this instance to a single plugin or all plugins if "destination" is
 333 omitted. This will bypass the main collectd process and all filtering and
 334 caching. Other than that it works similar to "dispatch". In most cases
 335 "dispatch" should be used instead of "write".
 336
 337 =back
 338
 339 Data descriptors defined here:
 340
 341 =over 4
 342
 343 =item interval
 344
 345 The interval is the timespan in seconds between two submits for the same data
 346 source. This value has to be a positive integer, so you can't submit more than
 347 one value per second. If this member is set to a non-positive value, the
 348 default value as specified in the config file will be used (default: 10).
 349
 350 If you submit values more often than the specified interval, the average will
 351 be used. If you submit less values, your graphs will have gaps.
 352
 353 =item values
 354
 355 These are the actual values that get dispatched to collectd. It has to be a
 356 sequence (a tuple or list) of numbers. The size of the sequence and the type of
 357 its content depend on the type member your I<types.db> file. For more
 358 information on this read the L<types.db(5)> manual page.
 359
 360 If the sequence does not have the correct size upon dispatch a I<RuntimeError>
 361 exception will be raised. If the content of the sequence is not a number, a
 362 I<TypeError> exception will be raised.
 363
 364 =back
 365
 366 =head2 Notification
 367
 368 A notification is an object defining the severity and message of the status
 369 message as well as an identification of a data instance by means of the members
 370 of I<PluginData> on which it is based.
 371
 372 class Notification(PluginData)
 373 The Notification class is a wrapper around the collectd notification.
 374 It can be used to notify other plugins about bad stuff happening. It works
 375 similar to Values but has a severity and a message instead of interval
 376 and time.
 377 Notifications can be dispatched at any time and can be received with
 378 register_notification.
 379
 380 Method resolution order:
 381
 382 =over 4
 383
 384 =item Notification
 385
 386 =item PluginData
 387
 388 =item object
 389
 390 =back
 391
 392 Methods defined here:
 393
 394 =over 4
 395
 396 =item B<dispatch>([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.  Dispatch a value list.
 397
 398 Dispatch this instance to the collectd process. The object has members for each
 399 of the possible arguments for this method. For a detailed explanation of these
 400 parameters see the member of the same same.
 401
 402 If you do not submit a parameter the value saved in its member will be
 403 submitted. If you do provide a parameter it will be used instead, without
 404 altering the member.
 405
 406 =back
 407
 408 Data descriptors defined here:
 409
 410 =over 4
 411
 412 =item message
 413
 414 Some kind of description what's going on and why this Notification was
 415 generated.
 416
 417 =item severity
 418
 419 The severity of this notification. Assign or compare to I<NOTIF_FAILURE>,
 420 I<NOTIF_WARNING> or I<NOTIF_OKAY>.
 421
 422 =back
 423
 424 =head1 FUNCTIONS
 425
 426 The following functions provide the C-interface to Python-modules.
 427
 428 =over 4
 429
 430 =item B<register_*>(I<callback>[, I<data>][, I<name>]) -> identifier
 431
 432 There are eight different register functions to get callback for eight
 433 different events. With one exception all of them are called as shown above.
 434
 435 =over 4
 436
 437 =item
 438
 439 I<callback> is a callable object that will be called every time the event is
 440 triggered.
 441
 442 =item
 443
 444 I<data> is an optional object that will be passed back to the callback function
 445 every time it is called. If you omit this parameter no object is passed back to
 446 your callback, not even None.
 447
 448 =item
 449
 450 I<name> is an optional identifier for this callback. The default name is
 451 B<python>.I<module>. I<module> is taken from the B<__module__> attribute of
 452 your callback function. Every callback needs a unique identifier, so if you
 453 want to register the same callback multiple time in the same module you need to
 454 specify a name here. Otherwise it's save to ignore this parameter I<identifier>
 455 is the full identifier assigned to this callback.
 456
 457 =back
 458
 459 These functions are called in the various stages of the daemon (see the section
 460 L<"WRITING YOUR OWN PLUGINS"> above) and are passed the following arguments:
 461
 462 =over 4
 463
 464 =item register_config
 465
 466 The only argument passed is a I<Config> object. See above for the layout of this
 467 data type.
 468 Note that you can not receive the whole config files this way, only B<Module>
 469 blocks inside the Python configuration block. Additionally you will only
 470 receive blocks where your callback identifier matches B<python.>I<blockname>.
 471
 472 =item register_init
 473
 474 The callback will be called without arguments.
 475
 476 =item register_read(callback[, interval][, data][, name]) -> identifier
 477
 478 This function takes an additional parameter: I<interval>. It specifies the
 479 time between calls to the callback function.
 480
 481 The callback will be called without arguments.
 482
 483 =item register_shutdown
 484
 485 The callback will be called without arguments.
 486
 487 =item register_write
 488
 489 The callback function will be called with one arguments passed, which will be a
 490 I<Values> object. For the layout of I<Values> see above.
 491 If this callback function throws an exception the next call will be delayed by
 492 an increasing interval.
 493
 494 =item register_flush
 495
 496 Like B<register_config> is important for this callback because it determines
 497 what flush requests the plugin will receive.
 498
 499 The arguments passed are I<timeout> and I<identifier>. I<timeout> indicates
 500 that only data older than I<timeout> seconds is to be flushed. I<identifier>
 501 specifies which values are to be flushed.
 502
 503 =item register_log
 504
 505 The arguments are I<severity> and I<message>. The severity is an integer and
 506 small for important messages and high for less important messages. The least
 507 important level is B<LOG_DEBUG>, the most important level is B<LOG_ERR>. In
 508 between there are (from least to most important): B<LOG_INFO>, B<LOG_NOTICE>,
 509 and B<LOG_WARNING>. I<message> is simply a string B<without> a newline at the
 510 end.
 511
 512 If this callback throws an exception it will B<not> be logged. It will just be
 513 printed to B<sys.stderr> which usually means silently ignored.
 514
 515 =item register_notification
 516
 517 The only argument passed is a I<Notification> object. See above for the layout of this
 518 data type.
 519
 520 =back
 521
 522 =item B<unregister_*>(I<identifier>) -> None
 523
 524 Removes a callback or data-set from collectd's internal list of callback
 525 functions. Every I<register_*> function has an I<unregister_*> function.
 526 I<identifier> is either the string that was returned by the register function
 527 or a callback function. The identifier will be constructed in the same way as
 528 for the register functions.
 529
 530 =item B<flush>(I<plugin[, I<timeout>][, I<identifier>]) -> None
 531
 532 Flush one or all plugins. I<timeout> and the specified I<identifiers> are
 533 passed on to the registered flush-callbacks. If omitted, the timeout defaults
 534 to C<-1>. The identifier defaults to None. If the B<plugin> argument has been
 535 specified, only named plugin will be flushed.
 536
 537 =item B<error>, B<warning>, B<notice>, B<info>, B<debug>(I<message>)
 538
 539 Log a message with the specified severity.
 540
 541 =back
 542
 543 =head1 EXAMPLES
 544
 545 Any Python module will start similar to:
 546
 547   import collectd
 548
 549 A very simple read function might look like:
 550
 551   def read(data=None):
 552     vl = collectd.Values(type='gauge')
 553     vl.plugin='python.spam'
 554     vl.dispatch(values=[random.random() * 100])
 555
 556 A very simple write function might look like:
 557
 558   def write(vl, data=None):
 559     for i in vl.values:
 560       print "%s (%s): %f" % (vl.plugin, vl.type, i)
 561
 562 To register those functions with collectd:
 563
 564   collectd.register_read(read);
 565   collectd.register_write(write);
 566
 567 See the section L<"CLASSES"> above for a complete documentation of the data
 568 types used by the read, write and match functions.
 569
 570 =head1 NOTES
 571
 572 =over 4
 573
 574 =item
 575
 576 Please feel free to send in new plugins to collectd's mailinglist at
 577 E<lt>collectdE<nbsp>atE<nbsp>verplant.orgE<gt> for review and, possibly,
 578 inclusion in the main distribution. In the latter case, we will take care of
 579 keeping the plugin up to date and adapting it to new versions of collectd.
 580
 581 Before submitting your plugin, please take a look at
 582 L<http://collectd.org/dev-info.shtml>.
 583
 584 =back
 585
 586 =head1 CAVEATS
 587
 588 =over 4
 589
 590 =item
 591
 592 collectd is heavily multi-threaded. Each collectd thread accessing the python
 593 plugin will be mapped to a Python interpreter thread. Any such thread will be
 594 created and destroyed transparently and on-the-fly.
 595
 596 Hence, any plugin has to be thread-safe if it provides several entry points
 597 from collectd (i.E<nbsp>e. if it registers more than one callback or if a
 598 registered callback may be called more than once in parallel).
 599
 600 =item
 601
 602 The Python thread module is initialized just before calling the init callbacks.
 603 This means you must not use Python's threading module prior to this point. This
 604 includes all config and possibly other callback as well.
 605
 606 =item
 607
 608 The python plugin exports the internal API of collectd which is considered
 609 unstable and subject to change at any time. We try hard to not break backwards
 610 compatibility in the Python API during the life cycle of one major release.
 611 However, this cannot be guaranteed at all times. Watch out for warnings
 612 dispatched by the python plugin after upgrades.
 613
 614 =back
 615
 616 =head1 KNOWN BUGS
 617
 618 =over 4
 619
 620 =item
 621
 622 This plugin is not compatible with python3. Trying to compile it with python3
 623 will fail because of the ways string, unicode and bytearray bahavior was
 624 changed.
 625
 626 =item
 627
 628 Not all aspects of the collectd API are accessible from python. This includes
 629 but is not limited to meta-data, filters and data sets.
 630
 631 =back
 632
 633 =head1 SEE ALSO
 634
 635 L<collectd(1)>,
 636 L<collectd.conf(5)>,
 637 L<collectd-perl(5)>,
 638 L<collectd-exec(5)>,
 639 L<types.db(5)>,
 640 L<python(1)>,
 641
 642 =head1 AUTHOR
 643
 644 The C<python plugin> has been written by
 645 Sven Trenkel E<lt>collectdE<nbsp>atE<nbsp>semidefinite.deE<gt>.
 646
 647 This manpage has been written by Sven Trenkel
 648 E<lt>collectdE<nbsp>atE<nbsp>semidefinite.deE<gt>.
 649 It is based on the L<collectd-perl(5)> manual page by
 650 Florian Forster E<lt>octoE<nbsp>atE<nbsp>verplant.orgE<gt> and
 651 Sebastian Harl E<lt>shE<nbsp>atE<nbsp>tokkee.orgE<gt>.
 652
 653 =cut