[collectd] Feedback: 4.2.0 - rpm, config, collection.cgi, usuability

[Florian Forster]

Hi Iain,

thank you very much for your feedback :) One can hardly ever have enough
of that ;)

On Thu, Nov 01, 2007 at 02:10:14PM +0100, Iain Lea wrote:
> - fixed collectd.spec file to work with new plugins and collection.conf
>   http://iainlea.dyndns.org/software/collectd/4.2.0/collectd.spec

Cool, thanks ;) I have two short questions, though:
1) Why do you depend on `perl-Regexp-Common'? Is that needed to build
   the `perl' plugin?
2) Is including
   `/usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod' in the
   package usual? Name and location kind of indicate it's a list of
   installed Perl modules or something..?

> - generated 4.2.0 rpms available here:

Thanks again :) Do you mind if I pull them and put them on the download
page?

> - edited collectd.conf file to have a reasonable set of default
>   plugins. It also has a problem in that the directory paths are
>   non-standard

The plugins are activated/deactivated (i. e. commented in/out) depending
on whether they were built or not. The paths are set according to the
`prefix' argument given to the configure script. Putting the actual
`localstatedir' there is not that easy because it often has the form
"${prefix}/var", i. e. the variable `prefix' is not substituted yet.

I think the best way is to include a Fedora-/package-specific sample
configuration in the source package (or in contrib/fedora) and install
that one instead. The Debian package does that, too.

> - edited collection.conf file to have a reasonable default paths i.e,

Those are the default paths when you configure without `--prefix' or
other arguments. Again, for the package I'd use an altered version of
the file.

> - What does the extra "rrd" in path /var/lib/collectd/rrd/ bring? Why
>   not just keep it as /var/lib/collectd/ or some new funcionality
>   planned?

It's up to you to chose another path, but the default is chosen so that
the RRD-files and the CSV-files don't mix.

> - The collection.cgi in v4 vs. v3 is built for listing many hosts
>   whose collectd data is located on a single host (or at least it
>   seems that way). Whats needed to bring it upto the easy to use (ie.
>   1 click) of v3 while keeping the expanded v4 capabilities are the
>   following minor addtions:

Yeah, the script is not very sophisticated. I've hacked it together so I
can see some graphs and I've segmented it so much to I can see the graph
I need as fast as possible (i. e. without waiting for the page to load
followed by a period of scrolling around ;)

I might put some more work into it, but I don't want to promise anything
here. I'd be happy to accept patches though, if anyone's brave enough to
dig through that hack.. ;)

> 4. seems as though displaying the load has an axis scaling problem.

I don't see it.. Do you have a graph and/or some more explanation?

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20071101/737c14fb/attachment.pgp