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