=over 4
-=item
+=item *
E-Mail type (e.g. "ham", "spam", "virus", ...) and size (bytes):
If C<size> is less than or equal to zero, C<size> is ignored.
-=item
+=item *
Spam score:
s:<value>
-=item
+=item *
Successful spam checks (e.g. "BAYES_99", "SUBJECT_DRUG_GAP_C", ...):
=over 4
-=item
+=item *
The user, the binary is executed as, may not have root privileges, i.E<nbsp>e.
must have an UID that is non-zero. This is for your own good.
-=item
+=item *
Early versions of the plugin did not use a command but treated all lines as if
they were arguments to the I<PUTVAL> command. When the I<PUTNOTIF> command was
=over 4
-=item
+=item *
Please feel free to send in new plugins to collectd's mailing list at
E<lt>collectdE<nbsp>atE<nbsp>collectd.orgE<gt> for review and, possibly,
=over 4
-=item
+=item *
collectd is heavily multi-threaded. Each collectd thread accessing the perl
plugin will be mapped to a Perl interpreter thread (see L<threads(3perl)>).
that no data is shared between threads by default. You have to use the
B<threads::shared> module to do so.
-=item
+=item *
Each function name registered with collectd has to be available before the
first thread has been created (i.E<nbsp>e. basically at compile time). This
will not work. This is due to the fact that the symbol table is not shared
across different threads.
-=item
+=item *
Each plugin is usually only loaded once and kept in memory for performance
reasons. Therefore, END blocks are only executed once when collectd shuts
down. You should not rely on END blocks anyway - use B<shutdown functions>
instead.
-=item
+=item *
The perl 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
=over 4
-=item
+=item *
Currently, it is not possible to flush a single Perl plugin only. You can
either flush all Perl plugins or none at all and you have to use C<perl> as
=over 4
-=item
+=item *
B<1.> collectd will try to import the B<readline> module to give you a decent
way of entering your commands. The daemonized collectd won't do that.
-=item
+=item *
B<2.> collectd will block I<SIGINT>. Pressing I<Ctrl+C> will usually cause
collectd to shut down. This would be problematic in an interactive session,
To quit collectd send I<EOF> (press I<Ctrl+D> at the beginning of a new line).
-=item
+=item *
B<3.> collectd handles I<SIGCHLD>. This means that Python won't be able to
determine the return code of spawned processes with system(), popen() and
=over 4
-=item
+=item *
I<callback> is a callable object that will be called every time the event is
triggered.
-=item
+=item *
I<data> 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.
-=item
+=item *
I<name> is an optional identifier for this callback. The default name is
B<python>.I<module>. I<module> is taken from the B<__module__> attribute of
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.
-=item
+=item *
I<identifier> is the full identifier assigned to this callback.
=back
-=item B<flush>(I<plugin>[, I<timeout>][, I<identifier>]) -> None
+=item B<flush>(I<plugin[, timeout][, identifier]) -> None
Flush one or all plugins. I<timeout> and the specified I<identifiers> are
passed on to the registered flush-callbacks. If omitted, the timeout defaults
=over 4
-=item
+=item *
Please feel free to send in new plugins to collectd's mailing list at
E<lt>collectdE<nbsp>atE<nbsp>collectd.orgE<gt> for review and, possibly,
=over 4
-=item
+=item *
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
from collectd (i.E<nbsp>e. if it registers more than one callback or if a
registered callback may be called more than once in parallel).
-=item
+=item *
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.
-=item
+=item *
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
=over 4
-=item
+=item *
Not all aspects of the collectd API are accessible from Python. This includes
but is not limited to filters and data sets.
=over 4
-=item
+=item *
The I<Type> cannot be left unspecified, because it is not reasonable to add
apples to oranges. Also, the internal lookup structure won't work if you try
to group by type.
-=item
+=item *
There must be at least one unspecified, ungrouped field. Otherwise nothing
will be aggregated.
=over 4
-=item
+=item *
foo.example.com/cpu-even-average/cpu-idle
-=item
+=item *
foo.example.com/cpu-even-average/cpu-system
-=item
+=item *
foo.example.com/cpu-even-average/cpu-user
-=item
+=item *
...
=over 4
-=item
+=item *
Sum, per-state, over all CPUs installed in the system; and
-=item
+=item *
Sum, per-CPU, over all non-idle states of a CPU, creating an "active" state.
=head2 Plugin C<ntpd>
-The C<ntpd> plugin collects per-peer ntpd data such as time offset and time
+The C<ntpd> plugin collects per-peer ntp data such as time offset and time
dispersion.
For talking to B<ntpd>, it mimics what the B<ntpdc> control program does on
-wire - using B<mode 7> specific requests. This mode is deprecated with
+the wire - using B<mode 7> specific requests. This mode is deprecated with
newer B<ntpd> releases (4.2.7p230 and later). For the C<ntpd> plugin to work
correctly with them, the ntp daemon must be explicitly configured to
enable B<mode 7> (which is disabled by default). Refer to the I<ntp.conf(5)>
=over 4
-=item
+=item *
Check I</etc/uuid> (or I<UUIDFile>).
-=item
+=item *
Check for UUID from HAL (L<http://www.freedesktop.org/wiki/Software/hal>) if
present.
-=item
+=item *
Check for UUID from C<dmidecode> / SMBIOS.
-=item
+=item *
Check for UUID from Xen hypervisor.
=over 4
-=item
+=item *
Input plugins are queried periodically. They somehow acquire the current value
of whatever they where designed to work with and submit these values back to
reads the current cpu-counters of time spent in the various modes (user,
system, nice, ...) and dispatches these counters to the daemon.
-=item
+=item *
Output plugins get the dispatched values from the daemon and does something
with them. Common applications are writing to RRD-files, CSV-files or sending
projects / collectd.git / commitdiff