projects
/
collectd.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
|
inline
| side by side (parent:
bc58fd4
)
Lua plugin: s/Collectd/collectd/g in manpage
author
Ruben Kerkhof
<ruben@rubenkerkhof.com>
Sun, 14 Aug 2016 11:58:14 +0000
(13:58 +0200)
committer
Ruben Kerkhof
<ruben@rubenkerkhof.com>
Sun, 14 Aug 2016 11:58:14 +0000
(13:58 +0200)
src/collectd-lua.pod
patch
|
blob
|
history
diff --git
a/src/collectd-lua.pod
b/src/collectd-lua.pod
index
62dd850
..
2f18f60
100644
(file)
--- a/
src/collectd-lua.pod
+++ b/
src/collectd-lua.pod
@@
-12,7
+12,7
@@
=head1 NAME
=head1 NAME
-collectd-lua - Documentation of
C
ollectd's C<Lua plugin>
+collectd-lua - Documentation of
c
ollectd's C<Lua plugin>
=head1 SYNOPSIS
=head1 SYNOPSIS
@@
-26,9
+26,9
@@
collectd-lua - Documentation of Collectd's C<Lua plugin>
=head1 DESCRIPTION
=head1 DESCRIPTION
-The C<Lua plugin> embeds a Lua interpreter into
C
ollectd and provides an
-interface to
C
ollectd's plugin system. This makes it possible to write plugins
-for
C
ollectd in Lua. This is a lot more efficient than executing a
+The C<Lua plugin> embeds a Lua interpreter into
c
ollectd and provides an
+interface to
c
ollectd's plugin system. This makes it possible to write plugins
+for
c
ollectd in Lua. This is a lot more efficient than executing a
Lua script every time you want to read a value with the C<exec plugin> (see
L<collectd-exec(5)>) and provides a lot more functionality, too.
Lua script every time you want to read a value with the C<exec plugin> (see
L<collectd-exec(5)>) and provides a lot more functionality, too.
@@
-56,11
+56,11
@@
If B<BasePath> is not specified, this needs to be an absolute path.
=head1 WRITING YOUR OWN PLUGINS
=head1 WRITING YOUR OWN PLUGINS
-Writing your own plugins is quite simple.
C
ollectd manages plugins by means of
+Writing your own plugins is quite simple.
c
ollectd manages plugins by means of
B<dispatch functions> which call the appropriate B<callback functions>
registered by the plugins. Any plugin basically consists of the implementation
of these callback functions and initializing code which registers the
B<dispatch functions> which call the appropriate B<callback functions>
registered by the plugins. Any plugin basically consists of the implementation
of these callback functions and initializing code which registers the
-functions with
C
ollectd. See the section "EXAMPLES" below for a really basic
+functions with
c
ollectd. See the section "EXAMPLES" below for a really basic
example. The following types of B<callback functions> are implemented in the
Lua plugin (all of them are optional):
example. The following types of B<callback functions> are implemented in the
Lua plugin (all of them are optional):
@@
-69,8
+69,8
@@
Lua plugin (all of them are optional):
=item read functions
These are used to collect the actual data. It is called once
=item read functions
These are used to collect the actual data. It is called once
-per interval (see the B<Interval> configuration option of
C
ollectd). Usually
-it will call B<collectd.dispatch_values> to dispatch the values to
C
ollectd
+per interval (see the B<Interval> configuration option of
c
ollectd). Usually
+it will call B<collectd.dispatch_values> to dispatch the values to
c
ollectd
which will pass them on to all registered B<write functions>. If this function
does not return 0 the plugin will be skipped for an increasing
amount of time until it returns normally again.
which will pass them on to all registered B<write functions>. If this function
does not return 0 the plugin will be skipped for an increasing
amount of time until it returns normally again.