.\" -*- mode: troff; coding: utf-8 -*-
.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
.ie n \{\
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "COLLECTD-PYTHON 5"
.TH COLLECTD-PYTHON 5 2024-03-07 5.12.0.git collectd
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH NAME
collectd\-python \- Documentation of collectd's "python plugin"
.SH SYNOPSIS
.IX Header "SYNOPSIS"
.Vb 7
\&  LoadPlugin python
\&  # ...
\&  <Plugin python>
\&    ModulePath "/path/to/your/python/modules"
\&    LogTraces true
\&    Interactive false
\&    Import "spam"
\&
\&    <Module spam>
\&      spam "wonderful" "lovely"
\&    </Module>
\&  </Plugin>
.Ve
.SH DESCRIPTION
.IX Header "DESCRIPTION"
The \f(CW\*(C`python plugin\*(C'\fR embeds a Python-interpreter into collectd and provides an
interface to collectd's plugin system. This makes it possible to write plugins
for collectd in Python. This is a lot more efficient than executing a
Python-script every time you want to read a value with the \f(CW\*(C`exec plugin\*(C'\fR (see
\&\fBcollectd\-exec\fR\|(5)) and provides a lot more functionality, too.
.PP
The minimum required Python version is \fI2.6\fR.
.SH CONFIGURATION
.IX Header "CONFIGURATION"
.IP "\fBLoadPlugin\fR \fIPlugin\fR" 4
.IX Item "LoadPlugin Plugin"
Loads the Python plugin \fIPlugin\fR.
.IP "\fBEncoding\fR \fIName\fR" 4
.IX Item "Encoding Name"
The default encoding for Unicode objects you pass to collectd. If you omit this
option it will default to \fBascii\fR on \fIPython 2\fR. On \fIPython 3\fR it will
always be \fButf\-8\fR, as this function was removed, so this will be silently
ignored.
These defaults are hardcoded in Python and will ignore everything else,
including your locale.
.IP "\fBModulePath\fR \fIName\fR" 4
.IX Item "ModulePath Name"
Prepends \fIName\fR to \fBsys.path\fR. You won't be able to import any scripts you
wrote unless they are located in one of the directories in this list. Please
note that it only has effect on plugins loaded after this option. You can
use multiple \fBModulePath\fR lines to add more than one directory.
.IP "\fBLogTraces\fR \fIbool\fR" 4
.IX Item "LogTraces bool"
If a Python script throws an exception it will be logged by collectd with the
name of the exception and the message. If you set this option to true it will
also log the full stacktrace just like the default output of an interactive
Python interpreter. This does not apply to the CollectError exception, which
will never log a stacktrace.
This should probably be set to false most of the time but is very useful for
development and debugging of new modules.
.IP "\fBInteractive\fR \fIbool\fR" 4
.IX Item "Interactive bool"
This option will cause the module to launch an interactive Python interpreter
that reads from and writes to the terminal. Note that collectd will terminate
right after starting up if you try to run it as a daemon while this option is
enabled so make sure to start collectd with the \fB\-f\fR option.
.Sp
The \fBcollectd\fR module is \fInot\fR imported into the interpreter's globals. You
have to do it manually. Be sure to read the help text of the module, it can be
used as a reference guide during coding.
.Sp
This interactive session will behave slightly differently from a daemonized
collectd script as well as from a normal Python interpreter:
.RS 4
.IP \(bu 4
\&\fB1.\fR collectd will try to import the \fBreadline\fR module to give you a decent
way of entering your commands. The daemonized collectd won't do that.
.IP \(bu 4
\&\fB2.\fR Python will be handling \fISIGINT\fR. Pressing \fICtrl+C\fR will usually cause
collectd to shut down. This would be problematic in an interactive session,
therefore Python will be handling it in interactive sessions. This allows you
to use \fICtrl+C\fR to interrupt Python code without killing collectd. This also
means you can catch \fIKeyboardInterrupt\fR exceptions which does not work during
normal operation.
.Sp
To quit collectd send \fIEOF\fR (press \fICtrl+D\fR at the beginning of a new line).
.IP \(bu 4
\&\fB3.\fR collectd handles \fISIGCHLD\fR. This means that Python won't be able to
determine the return code of spawned processes with \fBsystem()\fR, \fBpopen()\fR and
subprocess. This will result in Python not using external programs like less
to display help texts. You can override this behavior with the \fBPAGER\fR
environment variable, e.g. \fIexport PAGER=less\fR before starting collectd.
Depending on your version of Python this might or might not result in an
\&\fBOSError\fR exception which can be ignored.
.Sp
If you really need to spawn new processes from Python you can register an init
callback and reset the action for SIGCHLD to the default behavior. Please note
that this \fIwill\fR break the exec plugin. Do not even load the exec plugin if
you intend to do this!
.Sp
There is an example script located in \fBcontrib/python/getsigchld.py\fR  to do
this. If you import this from \fIcollectd.conf\fR SIGCHLD will be handled
normally and spawning processes from Python will work as intended.
.RE
.RS 4
.RE
.IP "\fBImport\fR \fIName\fR" 4
.IX Item "Import Name"
Imports the python script \fIName\fR and loads it into the collectd
python process. If your python script is not found, be sure its
directory exists in python's \fBsys.path\fR. You can prepend to the
\&\fBsys.path\fR using the \fBModulePath\fR configuration option.
.IP "<\fBModule\fR \fIName\fR> block" 4
.IX Item "<Module Name> block"
This block may be used to pass on configuration settings to a Python module.
The configuration is converted into an instance of the \fBConfig\fR class which is
passed to the registered configuration callback. See below for details about
the \fBConfig\fR class and how to register callbacks.
.Sp
The \fIname\fR identifies the callback.
.SH STRINGS
.IX Header "STRINGS"
There are a lot of places where strings are sent from collectd to Python and
from Python to collectd. How exactly this works depends on whether byte or
unicode strings or Python2 or Python3 are used.
.PP
Python2 has \fIstr\fR, which is just bytes, and \fIunicode\fR. Python3 has \fIstr\fR,
which is a unicode object, and \fIbytes\fR.
.PP
When passing strings from Python to collectd all of these object are supported
in all places, however \fIstr\fR should be used if possible. These strings must
not contain a NUL byte. Ignoring this will result in a \fITypeError\fR exception.
If a byte string was used it will be used as is by collectd. If a unicode
object was used it will be encoded using the default encoding (see above). If
this is not possible Python will raise a \fIUnicodeEncodeError\fR exception.
.PP
When passing strings from collectd to Python the behavior depends on the
Python version used. Python2 will always receive a \fIstr\fR object. Python3 will
usually receive a \fIstr\fR object as well, however the original string will be
decoded to unicode using the default encoding. If this fails because the
string is not a valid sequence for this encoding a \fIbytes\fR object will be
returned instead.
.SH "WRITING YOUR OWN PLUGINS"
.IX Header "WRITING YOUR OWN PLUGINS"
Writing your own plugins is quite simple. collectd manages plugins by means of
\&\fBdispatch functions\fR which call the appropriate \fBcallback functions\fR
registered by the plugins. Any plugin basically consists of the implementation
of these callback functions and initializing code which registers the
functions with collectd. See the section "EXAMPLES" below for a really basic
example. The following types of \fBcallback functions\fR are known to collectd
(all of them are optional):
.IP "configuration functions" 4
.IX Item "configuration functions"
These are called during configuration if an appropriate
\&\fBModule\fR block has been encountered. It is called once for each \fBModule\fR
block which matches the name of the callback as provided with the
\&\fBregister_config\fR method \- see below.
.Sp
Python thread support has not been initialized at this point so do not use any
threading functions here!
.IP "init functions" 4
.IX Item "init functions"
These are called once after loading the module and before any
calls to the read and write functions. It should be used to initialize the
internal state of the plugin (e.\ g. open sockets, ...). This is the
earliest point where you may use threads.
.IP "read functions" 4
.IX Item "read functions"
These are used to collect the actual data. It is called once
per interval (see the \fBInterval\fR configuration option of collectd). Usually
it will call \fBplugin_dispatch_values\fR to dispatch the values to collectd
which will pass them on to all registered \fBwrite functions\fR. If this function
throws any kind of exception the plugin will be skipped for an increasing
amount of time until it returns normally again.
.IP "write functions" 4
.IX Item "write functions"
These are used to write the dispatched values. It is called
once for every value that was dispatched by any plugin.
.IP "flush functions" 4
.IX Item "flush functions"
These are used to flush internal caches of plugins. It is
usually triggered by the user only. Any plugin which caches data before
writing it to disk should provide this kind of callback function.
.IP "log functions" 4
.IX Item "log functions"
These are used to pass messages of plugins or the daemon itself
to the user.
.IP "notification function" 4
.IX Item "notification function"
These are used to act upon notifications. In general, a
notification is a status message that may be associated with a data instance.
Usually, a notification is generated by the daemon if a configured threshold
has been exceeded (see the section "THRESHOLD CONFIGURATION" in
\&\fBcollectd.conf\fR\|(5) for more details), but any plugin may dispatch
notifications as well.
.IP "shutdown functions" 4
.IX Item "shutdown functions"
These are called once before the daemon shuts down. It should
be used to clean up the plugin (e.g. close sockets, ...).
.PP
Any function (except log functions) may throw an exception in case of
errors. The exception will be passed on to the user using collectd's logging
mechanism. If a log callback throws an exception it will be printed to standard
error instead.
.PP
See the documentation of the various \fBregister_\fR methods in the section
"FUNCTIONS" below for the number and types of arguments passed to each
\&\fBcallback function\fR. This section also explains how to register \fBcallback
functions\fR with collectd.
.PP
To enable a module, copy it to a place where Python can find it (i.\ e. a
directory listed in \fBsys.path\fR) just as any other Python plugin and add
an appropriate \fBImport\fR option to the configuration file. After restarting
collectd you're done.
.SH CLASSES
.IX Header "CLASSES"
The following complex types are used to pass values between the Python plugin
and collectd:
.SS CollectdError
.IX Subsection "CollectdError"
This is an exception. If any Python script raises this exception it will
still be treated like an error by collectd but it will be logged as a
warning instead of an error and it will never generate a stacktrace.
.PP
.Vb 1
\& class CollectdError(Exception)
.Ve
.PP
Basic exception for collectd Python scripts.
Throwing this exception will not cause a stacktrace to be logged, even if
LogTraces is enabled in the config.
.SS Signed
.IX Subsection "Signed"
The Signed class is just a long. It has all its methods and behaves exactly
like any other long object. It is used to indicate if an integer was or should
be stored as a signed or unsigned integer object.
.PP
.Vb 1
\& class Signed(long)
.Ve
.PP
This is a long by another name. Use it in meta data dicts
to choose the way it is stored in the meta data.
.SS Unsigned
.IX Subsection "Unsigned"
The Unsigned class is just a long. It has all its methods and behaves exactly
like any other long object. It is used to indicate if an integer was or should
be stored as a signed or unsigned integer object.
.PP
.Vb 1
\& class Unsigned(long)
.Ve
.PP
This is a long by another name. Use it in meta data dicts
to choose the way it is stored in the meta data.
.SS Config
.IX Subsection "Config"
The Config class is an object which keeps the information provided in the
configuration file. The sequence of children keeps one entry for each
configuration option. Each such entry is another Config instance, which
may nest further if nested blocks are used.
.PP
.Vb 1
\& class Config(object)
.Ve
.PP
This represents a piece of collectd's config file. It is passed to scripts with
config callbacks (see \fBregister_config\fR) and is of little use if created
somewhere else.
.PP
It has no methods beyond the bare minimum and only exists for its data members.
.PP
Data descriptors defined here:
.IP parent 4
.IX Item "parent"
This represents the parent of this node. On the root node
of the config tree it will be None.
.IP key 4
.IX Item "key"
This is the keyword of this item, i.e. the first word of any given line in the
config file. It will always be a string.
.IP values 4
.IX Item "values"
This is a tuple (which might be empty) of all value, i.e. words following the
keyword in any given line in the config file.
.Sp
Every item in this tuple will be either a string, a float or a boolean,
depending on the contents of the configuration file.
.IP children 4
.IX Item "children"
This is a tuple of child nodes. For most nodes this will be empty. If this node
represents a block instead of a single line of the config file it will contain
all nodes in this block.
.SS PluginData
.IX Subsection "PluginData"
This should not be used directly but it is the base class for both Values and
Notification. It is used to identify the source of a value or notification.
.PP
.Vb 1
\& class PluginData(object)
.Ve
.PP
This is an internal class that is the base for Values and Notification. It is
pretty useless by itself and was therefore not exported to the collectd module.
.PP
Data descriptors defined here:
.IP host 4
.IX Item "host"
The hostname of the host this value was read from. For dispatching this can be
set to an empty string which means the local hostname as defined in
collectd.conf.
.IP plugin 4
.IX Item "plugin"
The name of the plugin that read the data. Setting this member to an empty
string will insert "python" upon dispatching.
.IP plugin_instance 4
.IX Item "plugin_instance"
Plugin instance string. May be empty.
.IP time 4
.IX Item "time"
This is the Unix timestamp of the time this value was read. For dispatching
values this can be set to zero which means "now". This means the time the value
is actually dispatched, not the time it was set to 0.
.IP type 4
.IX Item "type"
The type of this value. This type has to be defined in your \fItypes.db\fR.
Attempting to set it to any other value will raise a \fITypeError\fR exception.
Assigning a type is mandatory, calling dispatch without doing so will raise a
\&\fIRuntimeError\fR exception.
.IP type_instance 4
.IX Item "type_instance"
Type instance string. May be empty.
.SS Values
.IX Subsection "Values"
A Value is an object which features a sequence of values. It is based on the
\&\fIPluginData\fR type and uses its members to identify the values.
.PP
.Vb 1
\& class Values(PluginData)
.Ve
.PP
A Values object used for dispatching values to collectd and receiving values
from write callbacks.
.PP
Method resolution order:
.IP Values 4
.IX Item "Values"
.PD 0
.IP PluginData 4
.IX Item "PluginData"
.IP object 4
.IX Item "object"
.PD
.PP
Methods defined here:
.IP "\fBdispatch\fR([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) \-> None." 4
.IX Item "dispatch([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None."
Dispatch this instance to the collectd process. The object has members for each
of the possible arguments for this method. For a detailed explanation of these
parameters see the member of the same same.
.Sp
If you do not submit a parameter the value saved in its member will be
submitted. If you do provide a parameter it will be used instead, without
altering the member.
.IP "\fBwrite\fR([destination][, type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) \-> None." 4
.IX Item "write([destination][, type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None."
Write this instance to a single plugin or all plugins if "destination" is
omitted. This will bypass the main collectd process and all filtering and
caching. Other than that it works similar to "dispatch". In most cases
"dispatch" should be used instead of "write".
.PP
Data descriptors defined here:
.IP interval 4
.IX Item "interval"
The interval is the timespan in seconds between two submits for the same data
source. This value has to be a positive integer, so you can't submit more than
one value per second. If this member is set to a non-positive value, the
default value as specified in the config file will be used (default: 10).
.Sp
If you submit values more often than the specified interval, the average will
be used. If you submit less values, your graphs will have gaps.
.IP values 4
.IX Item "values"
These are the actual values that get dispatched to collectd. It has to be a
sequence (a tuple or list) of numbers. The size of the sequence and the type of
its content depend on the type member your \fItypes.db\fR file. For more
information on this read the \fBtypes.db\fR\|(5) manual page.
.Sp
If the sequence does not have the correct size upon dispatch a \fIRuntimeError\fR
exception will be raised. If the content of the sequence is not a number, a
\&\fITypeError\fR exception will be raised.
.IP meta 4
.IX Item "meta"
These are the meta data for this Value object.
It has to be a dictionary of numbers, strings or bools. All keys must be
strings. \fIint\fR and <long> objects will be dispatched as signed integers unless
they are between 2**63 and 2**64\-1, which will result in a unsigned integer.
You can force one of these storage classes by using the classes
\&\fBcollectd.Signed\fR and \fBcollectd.Unsigned\fR. A meta object received by a write
callback will always contain \fBSigned\fR or \fBUnsigned\fR objects.
.SS Notification
.IX Subsection "Notification"
A notification is an object defining the severity and message of the status
message as well as an identification of a data instance by means of the members
of \fIPluginData\fR on which it is based.
.PP
class Notification(PluginData)
The Notification class is a wrapper around the collectd notification.
It can be used to notify other plugins about bad stuff happening. It works
similar to Values but has a severity and a message instead of interval
and time.
Notifications can be dispatched at any time and can be received with
register_notification.
.PP
Method resolution order:
.IP Notification 4
.IX Item "Notification"
.PD 0
.IP PluginData 4
.IX Item "PluginData"
.IP object 4
.IX Item "object"
.PD
.PP
Methods defined here:
.IP "\fBdispatch\fR([type][, message][, plugin_instance][, type_instance][, plugin][, host][, time][, severity][, meta]) \-> None.  Dispatch a notification." 4
.IX Item "dispatch([type][, message][, plugin_instance][, type_instance][, plugin][, host][, time][, severity][, meta]) -> None. Dispatch a notification."
Dispatch this instance to the collectd process. The object has members for each
of the possible arguments for this method. For a detailed explanation of these
parameters see the member of the same same.
.Sp
If you do not submit a parameter the value saved in its member will be
submitted. If you do provide a parameter it will be used instead, without
altering the member.
.PP
Data descriptors defined here:
.IP message 4
.IX Item "message"
Some kind of description of what's going on and why this Notification was
generated.
.IP severity 4
.IX Item "severity"
The severity of this notification. Assign or compare to \fINOTIF_FAILURE\fR,
\&\fINOTIF_WARNING\fR or \fINOTIF_OKAY\fR.
.IP meta 4
.IX Item "meta"
These are the meta data for the Notification object.
It has to be a dictionary of numbers, strings or bools. All keys must be
strings. \fIint\fR and \fIlong\fR objects will be dispatched as signed integers unless
they are between 2**63 and 2**64\-1, which will result in a unsigned integer.
One of these storage classes can be forced by using the classes
\&\fBcollectd.Signed\fR and \fBcollectd.Unsigned\fR. A meta object received by a
notification callback will always contain \fBSigned\fR or \fBUnsigned\fR objects.
.SH FUNCTIONS
.IX Header "FUNCTIONS"
The following functions provide the C\-interface to Python-modules.
.IP "\fBregister_*\fR(\fIcallback\fR[, \fIdata\fR][, \fIname\fR]) \-> identifier" 4
.IX Item "register_*(callback[, data][, name]) -> identifier"
There are eight different register functions to get callback for eight
different events. With one exception all of them are called as shown above.
.RS 4
.IP \(bu 4
\&\fIcallback\fR is a callable object that will be called every time the event is
triggered.
.IP \(bu 4
\&\fIdata\fR is an optional object that will be passed back to the callback function
every time it is called. If you omit this parameter no object is passed back to
your callback, not even None.
.IP \(bu 4
\&\fIname\fR is an optional identifier for this callback. The default name is
\&\fBpython\fR.\fImodule\fR. \fImodule\fR is taken from the \fB_\|_module_\|_\fR attribute of
your callback function. Every callback needs a unique identifier, so if you
want to register the same callback multiple times in the same module you need to
specify a name here. Otherwise it's safe to ignore this parameter.
.IP \(bu 4
\&\fIidentifier\fR is the full identifier assigned to this callback.
.RE
.RS 4
.Sp
These functions are called in the various stages of the daemon (see the section
"WRITING YOUR OWN PLUGINS" above) and are passed the following arguments:
.IP register_config 4
.IX Item "register_config"
The only argument passed is a \fIConfig\fR object. See above for the layout of this
data type.
Note that you cannot receive the whole config files this way, only \fBModule\fR
blocks inside the Python configuration block. Additionally you will only
receive blocks where your callback identifier matches \fBpython.\fR\fIblockname\fR.
.IP register_init 4
.IX Item "register_init"
The callback will be called without arguments.
.IP "register_read(callback[, interval][, data][, name]) \-> \fIidentifier\fR" 4
.IX Item "register_read(callback[, interval][, data][, name]) -> identifier"
This function takes an additional parameter: \fIinterval\fR. It specifies the
time between calls to the callback function.
.Sp
The callback will be called without arguments.
.IP register_shutdown 4
.IX Item "register_shutdown"
The callback will be called without arguments.
.IP register_write 4
.IX Item "register_write"
The callback function will be called with one argument passed, which will be a
\&\fIValues\fR object. For the layout of \fIValues\fR see above.
If this callback function throws an exception the next call will be delayed by
an increasing interval.
.IP register_flush 4
.IX Item "register_flush"
Like \fBregister_config\fR is important for this callback because it determines
what flush requests the plugin will receive.
.Sp
The arguments passed are \fItimeout\fR and \fIidentifier\fR. \fItimeout\fR indicates
that only data older than \fItimeout\fR seconds is to be flushed. \fIidentifier\fR
specifies which values are to be flushed.
.IP register_log 4
.IX Item "register_log"
The arguments are \fIseverity\fR and \fImessage\fR. The severity is an integer and
small for important messages and high for less important messages. The least
important level is \fBLOG_DEBUG\fR, the most important level is \fBLOG_ERR\fR. In
between there are (from least to most important): \fBLOG_INFO\fR, \fBLOG_NOTICE\fR,
and \fBLOG_WARNING\fR. \fImessage\fR is simply a string \fBwithout\fR a newline at the
end.
.Sp
If this callback throws an exception it will \fBnot\fR be logged. It will just be
printed to \fBsys.stderr\fR which usually means silently ignored.
.IP register_notification 4
.IX Item "register_notification"
The only argument passed is a \fINotification\fR object. See above for the layout of this
data type.
.RE
.RS 4
.RE
.IP "\fBunregister_*\fR(\fIidentifier\fR) \-> None" 4
.IX Item "unregister_*(identifier) -> None"
Removes a callback or data-set from collectd's internal list of callback
functions. Every \fIregister_*\fR function has an \fIunregister_*\fR function.
\&\fIidentifier\fR is either the string that was returned by the register function
or a callback function. The identifier will be constructed in the same way as
for the register functions.
.IP "\fBget_dataset\fR(\fIname\fR) \-> \fIdefinition\fR" 4
.IX Item "get_dataset(name) -> definition"
Returns the definition of a dataset specified by \fIname\fR. \fIdefinition\fR is a list
of tuples, each representing one data source. Each tuple has 4 values:
.RS 4
.IP name 4
.IX Item "name"
A string, the name of the data source.
.IP type 4
.IX Item "type"
A string that is equal to either of the variables \fBDS_TYPE_COUNTER\fR,
\&\fBDS_TYPE_GAUGE\fR, \fBDS_TYPE_DERIVE\fR or \fBDS_TYPE_ABSOLUTE\fR.
.IP min 4
.IX Item "min"
A float or None, the minimum value.
.IP max 4
.IX Item "max"
A float or None, the maximum value.
.RE
.RS 4
.RE
.IP "\fBflush\fR(\fIplugin[, timeout][, identifier]) \-\fR None" 4
.IX Item "flush(plugin[, timeout][, identifier]) - None"
Flush one or all plugins. \fItimeout\fR and the specified \fIidentifiers\fR are
passed on to the registered flush-callbacks. If omitted, the timeout defaults
to \f(CW\-1\fR. The identifier defaults to None. If the \fBplugin\fR argument has been
specified, only named plugin will be flushed.
.IP "\fBerror\fR, \fBwarning\fR, \fBnotice\fR, \fBinfo\fR, \fBdebug\fR(\fImessage\fR)" 4
.IX Item "error, warning, notice, info, debug(message)"
Log a message with the specified severity.
.SH EXAMPLES
.IX Header "EXAMPLES"
Any Python module will start similar to:
.PP
.Vb 1
\&  import collectd
.Ve
.PP
A very simple read function might look like:
.PP
.Vb 1
\&  import random
\&
\&  def read(data=None):
\&    vl = collectd.Values(type=\*(Aqgauge\*(Aq)
\&    vl.plugin=\*(Aqpython.spam\*(Aq
\&    vl.dispatch(values=[random.random() * 100])
.Ve
.PP
A very simple write function might look like:
.PP
.Vb 3
\&  def write(vl, data=None):
\&    for i in vl.values:
\&      print "%s (%s): %f" % (vl.plugin, vl.type, i)
.Ve
.PP
To register those functions with collectd:
.PP
.Vb 2
\&  collectd.register_read(read)
\&  collectd.register_write(write)
.Ve
.PP
See the section "CLASSES" above for a complete documentation of the data
types used by the read, write and match functions.
.SH CAVEATS
.IX Header "CAVEATS"
.IP \(bu 4
collectd is heavily multi-threaded. Each collectd thread accessing the Python
plugin will be mapped to a Python interpreter thread. Any such thread will be
created and destroyed transparently and on-the-fly.
.Sp
Hence, any plugin has to be thread-safe if it provides several entry points
from collectd (i.\ e. if it registers more than one callback or if a
registered callback may be called more than once in parallel).
.IP \(bu 4
The Python thread module is initialized just before calling the init callbacks.
This means you must not use Python's threading module prior to this point. This
includes all config and possibly other callback as well.
.IP \(bu 4
The python plugin exports the internal API of collectd which is considered
unstable and subject to change at any time. We try hard to not break backwards
compatibility in the Python API during the life cycle of one major release.
However, this cannot be guaranteed at all times. Watch out for warnings
dispatched by the python plugin after upgrades.
.SH "KNOWN BUGS"
.IX Header "KNOWN BUGS"
.IP \(bu 4
Not all aspects of the collectd API are accessible from Python. This includes
but is not limited to filters.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fBcollectd\fR\|(1),
\&\fBcollectd.conf\fR\|(5),
\&\fBcollectd\-perl\fR\|(5),
\&\fBcollectd\-exec\fR\|(5),
\&\fBtypes.db\fR\|(5),
\&\fBpython\fR\|(1),
.SH AUTHOR
.IX Header "AUTHOR"
The \f(CW\*(C`python plugin\*(C'\fR has been written by
Sven Trenkel <collectd\ at\ semidefinite.de>.
.PP
This manpage has been written by Sven Trenkel
<collectd\ at\ semidefinite.de>.
It is based on the \fBcollectd\-perl\fR\|(5) manual page by
Florian Forster <octo\ at\ collectd.org> and
Sebastian Harl <sh\ at\ tokkee.org>.