=head1 NAME

collectd-unixsock - Documentation of collectd's C<unixsock plugin>

=head1 SYNOPSIS

  # See collectd.conf(5)
  LoadPlugin unixsock
  # ...
  <Plugin unixsock>
    SocketFile "/path/to/socket"
    SocketGroup "collectd"
    SocketPerms "0770"
  </Plugin>

=head1 DESCRIPTION

The C<unixsock plugin> opens an UNIX-socket over which one can interact with
the daemon. This can be used to use the values collected by collectd in other
applications, such as monitoring, or submit externally collected values to
collectd.

This plugin is used by L<collectd-nagios(1)> to check if some value is in a
certain range and exit with a Nagios-compatible exit code.

=head1 COMMANDS

Upon start the C<unixsock plugin> opens a UNIX-socket and waits for
connections. Once a connection is established the client can send commands to
the daemon which it will answer, if it understand them.

The following commands are implemented:

=over 4

=item B<GETVAL> I<Identifier>

If the value identified by I<Identifier> (see below) is found the complete
value-list is returned. The response is a space separated list of
name-value-pairs:

I<num> I<name>B<=>I<value>[ I<name>B<=>I<value>[ ...]]

If I<num> is less then zero, an error occurred. Otherwise it contains the
number of values that follow. Each value is of the form I<name>B<=>I<value>.
Counter-values are converted to a rate, e.E<nbsp>g. bytes per second.
Undefined values are returned as B<NaN>.

Example:
  -> | GETVAL myhost/cpu-0/cpu-user
  <- | 1 value=1.260000e+00

=item B<LISTVAL>

Returns a list of the values available in the value cache together with the
time of the last update, so that querying applications can issue a B<GETVAL>
command for the values that have changed.

The first line's status number is the number of identifiers returned or less
than zero if an error occurred. Each of the following lines contains the
update time as an epoch value and the identifier, separated by a space. The
update time is the time of the last value, as provided by the collecting
instance and may be very different from the time the server consideres to be
"now".

Example:
  -> | LISTVAL
  <- | 69 Values found
  <- | 1182204284 leeloo/cpu-0/cpu-idle
  <- | 1182204284 leeloo/cpu-0/cpu-nice
  <- | 1182204284 leeloo/cpu-0/cpu-system
  <- | 1182204284 leeloo/cpu-0/cpu-user
  ...

=item B<PUTVAL> I<Identifier> [I<OptionList>] I<Valuelist>

Submits one or more values (identified by I<Identifier>, see below) to the
daemon which will dispatch it to all it's write-plugins.

An I<Identifier> is of the form
C<I<host>B</>I<plugin>B<->I<instance>B</>I<type>B<->I<instance>> with both
I<instance>-parts being optional. If they're omitted the hyphen must be
omitted, too. I<plugin> and each I<instance>-part may be chosen freely as long
as the tuple (plugin, plugin instance, type instance) uniquely identifies the
plugin within collectd. I<type> identifies the type and number of values
(i.E<nbsp>e. data-set) passed to collectd. A large list of predefined
data-sets is available in the B<types.db> file.

The I<OptionList> is an optional list of I<Options>, where each option is a
key-value-pair. A list of currently understood options can be found below, all
other options will be ignored.

I<Valuelist> is a colon-separated list of the time and the values, each either
an integer if the data-source is a counter, or a double if the data-source is
of type "gauge". You can submit an undefined gauge-value by using B<U>. When
submitting B<U> to a counter the behavior is undefined. The time is given as
epoch (i.E<nbsp>e. standard UNIX time).

You can mix options and values, but the order is important: Options only
effect following values, so specifying an option as last field is allowed, but
useless. Also, an option applies to B<all> following values, so you don't need
to re-set an option over and over again.

The currently defined B<Options> are:

=over 4

=item B<interval=>I<seconds>

Gives the interval in which the data identified by I<Identifier> is being
collected.

=back

Please note that this is the same format as used in the B<exec plugin>, see
L<collectd-exec(5)>.

Example:
  -> | PUTVAL testhost/interface/if_octets-test0 interval=10 1179574444:123:456
  <- | 0 Success

=item B<PUTNOTIF> [I<OptionList>] B<message=>I<Message>

Submits a notification to the daemon which will then dispatch it to all plugins
which have registered for receiving notifications. 

The B<PUTNOTIF> if followed by a list of options which further describe the
notification. The B<message> option is special in that it will consume the rest
of the line as its value. The B<message>, B<severity>, and B<time> options are
mandatory.

Valid options are:

=over 4

=item B<message=>I<Message> (B<REQUIRED>)

Sets the message of the notification. This is the message that will be made
accessible to the user, so it should contain some useful information. This
option must be the last option because the rest of the line will be its value,
even if there are spaces and equal-signs following it! This option is
mandatory.

=item B<severity=failure>|B<warning>|B<okay> (B<REQUIRED>)

Sets the severity of the notification. This option is mandatory.

=item B<time=>I<Time> (B<REQUIRED>)

Sets the time of the notification. The time is given as "epoch", i.E<nbsp>e. as
seconds since January 1st, 1970, 00:00:00. This option is mandatory.

=item B<host=>I<Hostname>

=item B<plugin=>I<Plugin>

=item B<plugin_instance=>I<Plugin-Instance>

=item B<type=>I<Type>

=item B<type_instance=>I<Type-Instance>

These "associative" options establish a relation between this notification and
collected performance data. This connection is purely informal, i.E<nbsp>e. the
daemon itself doesn't do anything with this information. However, websites or
GUIs may use this information to place notifications near the affected graph or
table. All the options are optional, but B<plugin_instance> without B<plugin>
or B<type_instance> without B<type> doesn't make much sense and should be
avoided.

Please note that this is the same format as used in the B<exec plugin>, see
L<collectd-exec(5)>.

=back

Example:
  -> | PUTNOTIF type=temperature severity=warning time=1201094702 message=The roof is on fire!
  <- | 0 Success

=item B<FLUSH> [B<timeout=>I<Timeout>] [B<plugin=>I<Plugin> [...]]

Flushes all cached data older than I<Timeout> seconds. If no timeout has been
specified, it defaults to -1 which causes all data to be flushed.

If specified, only specific plugins are flushed. Otherwise all plugins
providing a flush callback are flushed.

Example:
  -> | FLUSH
  <- | 0 Done

=back

=head2 Identifiers

Value or value-lists are identified in a uniform fashion:

I<Hostname>/I<Plugin>/I<Type>

Where I<Plugin> and I<Type> are both either of type "I<Name>" or
"I<Name>-I<Instance>". This sounds more complicated than it is, so here are
some examples:

  myhost/cpu-0/cpu-user
  myhost/load/load
  myhost/memory/memory-used
  myhost/disk-sda/disk_octets

=head2 Return values

Unless otherwise noted the plugin answers with a line of the following form:

I<Num> I<Message>

If I<Num> is zero the message indicates success, if I<Num> is non-zero the
message indicates failure. I<Message> is a human-readable string that describes
the return value further.

Commands that return values may use I<Num> to return the number of values that
follow, such as the B<GETVAL> command. These commands usually return a negative
value on failure and never return zero.

=head1 ABSTRACTION LAYER

Shipped with the sourcecode comes the Perl-Module L<Collectd::Unixsock> which
provides an abstraction layer over the actual socket connection. It can be
found in the directory F<contrib/PerlLib>. If you want to use Perl to
communicate with the daemon, you're encouraged to use and expand this module.

=head1 SEE ALSO

L<collectd(1)>,
L<collectd.conf(5)>,
L<collectd-nagios(1)>,
L<unix(7)>

=head1 AUTHOR

Florian Forster E<lt>octo@verplant.orgE<gt>

=cut