[collectd] Config changes
octo at verplant.org
Sat Sep 19 08:09:29 CEST 2009
thanks for your comments :)
On Fri, Sep 18, 2009 at 12:39:38PM +0200, Mirko Buffoni wrote:
> I noticed that 'LoadPlugin vserver' directive is not present anymore
> in collectd.conf, though the plugin is compiled.
Weird. It should be included in the standard config file, though
-- 8< --
octo at leeloo:~/collectd $ grep vserver src/collectd.conf.in
#@BUILD_PLUGIN_VSERVER_TRUE at LoadPlugin vserver
-- >8 --
> Couchdb is missing 'LoadPlugin couchdb' directive in collectd.conf
The “CouchDB” plugin has been renamed to “cURL-JSON” (due to the fact
that it can query other daemons, such as Hadoop, too). I see that the
example block is still named “couchdb” though. I've changed that to
“curl_json”. Thanks for noticing.
> Generated collectd.conf is missing additional parameter for dns
> #<Plugin dns>
> # SelectNumericQueryTypes true
It's added, thanks :)
> #<Plugin http>
> # URL "http://example.com/collectd-import"
> # User "www-user"
> # Password "secret"
> I cannot find which plugin is this for. Leftover of write_http?
I think so, yes. I've removed it.
> This is a proposal. I went through all plugins and created a
> different config file layout:
> To me this has several advantages: plugin classification allows me to
> better identify plugins based on their purpose, and also to deploy a
> rather standardized package with more or less plugins which can be
> installed separately together with their config file, in a separate
> package, when needed.
I have to admit such classifications usually annoy me, because I can't
see at once what's where. Also, it seems to be a natural law that the
category one look in at first is not the right category. [*]
> Of course the best would be to keep up-to-date the single
> configuration files, hopefully with a brief description at the top of
> the config file, and maybe with the part of the manual that summarize
> the parameters, as a quick reference, to avoid to go through the
> manual each time.
The problem I'm seeing here is that this is very hard to maintain.
Keeping 80+ files up to date and consistent with the manpage is a lot of
maintenance work Keeping 80+ files up to date and consistent with the
manpage is a lot of maintenance work for little extra comfort. And I
don't think the resulting inconsistencies will necessarily improve the
The only way I could picture this was to centralize the information and
generate everything from this. Ideally, that place is the POD files from
which the manpages are generated. We could add a bunch or extra markup
and write scripts to generate the config snippets from that.
-- 8< --
=head2 Plugin C<csv>
=for comment BEGIN DESCRIPTION csv
The CSV plugin …
=for comment END DESCRIPTION csv
=for comment BEGIN SYNOPSIS csv
=for comment END SYNOPSIS csv
-- >8 --
[*] Maybe categories have heard of Schrödinger? If something could be in
two or more categories, it's undecided in which category it is until
you look. And then it's in the/an other.
Florian octo Forster
Hacker in training
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090919/d4493e12/attachment.pgp
More information about the collectd