<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.2">
</HEAD>
<BODY>
Hi<BR>
Dnia 2010-02-23, wto o godzinie 18:03 +0100, Sebastian Harl pisze: about that yet. Any comments would be appreciated.
<BLOCKQUOTE TYPE=CITE>
<PRE>
> In an ideal world, you would set a DefaultInterval for all plugins
> (20secs?) and then potentially overwrite that value in the
> configuration of every plugin. That would be perfect.
Yes, that is the idea, basically.
> But maybe there are restrictions, like a plugin could only have an
> interval that is a multiple of the base interval?
There are no such restrictions (from a collectd-core architectural point
of view). The question is, whether we want to introduce a config block
for each and every plugin where most plugins will support a single
config option ("Interval") only. This would, e.g., look like this:
Interval 10 # default
LoadPlugin cpu
LoadPlugin load
LoadPlugin postgresql
LoadPlugin rrdtool
<Plugin cpu>
Interval 5
</Plugin>
<Plugin postgresql>
Interval 60
# more postgresql configuration
</Plugin>
# more configuration
Then, cpu would read its values using a 5 seconds interval, load would
use the default of 10 seconds and postgresql would use 60 seconds. As I
said before, the "downside" of this approach is that this feature has to
be implemented in every single plugin.
</PRE>
</BLOCKQUOTE>
That would be imo most "user-friendly", because it keeps non-default plugin config "close" to other configuration options (no need for <LoadPlugin> and <Plugin> Sections)
<BLOCKQUOTE TYPE=CITE>
<PRE>
Another approach might be to do something like this:
Interval 10
<LoadPlugin cpu>
Interval 5
</LoadPlugin>
LoadPlugin load
# more configuration
This could be implemented in the daemon itself, so it would not require
a modification of every plugin. Plugins could still support a more
specific "Interval" option (e.g., the "postgresql" plugin might want to
support different intervals for querying different databases). However,
that would introduce three different kinds of intervals: a global
interval, a plugin specific interval overwriting the global
configuration and a plugin instance (or whatever) specific interval
overwriting the plugin specific interval. That might be confusing to
users but it would probably require the least code changes and the most
consistent behavior (as in: it's not possible to accidentally have some
plugin not implementing the plugin specific interval option). Also, I'm
not yet a 100% sure how to implement that [*].
Any comments about that?
Cheers,
Sebastian
[*] One approach might be to keep a look-up table in the daemon, storing
(plugin name, interval) pairs. When a plugin registers a read
callback without specifying an interval, the daemon would try to
look up the interval in that table and fall back to the global
interval. This would require all plugins to strictly follow a naming
convention when registering read callbacks, though (e.g.
"<plugin_name>-<instance>").
</PRE>
</BLOCKQUOTE>
Following name convention is good thing anyway, idea looks good and it would have nice "backward compatibilty" so no need to rewrite all plugins<BR>
<BR>
Regards<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Mariusz Gronczewski (XANi) <<A HREF="mailto:xani666@gmail.com">xani666@gmail.com</A>>
GnuPG: 0xEA8ACE64
<A HREF="http://devrandom.pl">http://devrandom.pl</A>
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>