[collectd] collectd 4.0 in server mode

[Florian Forster]

Hi Daniel,

On Mon, Apr 23, 2007 at 11:12:03PM +0100, Daniel Leite wrote:
> > I will look into why the daemon hasn't complained about these keys not
> > being valid. How did you start the daemon? ``By hand'' or using an
> > init-script of some sort?
> 
> i had a script, but as it failled, i tried via command line_

okay, I'll check why you didn't get an error message.

> Exiting normally
> Segmentation fault (core dumped)
> 
> I pressed ctrl+C to exit, i can try to debug that crash

That'd be great :) Use the rc6 which I've uploaded yesterday to do so,
though, since I've fixed shutdown-issues in the email plugin.

> > - `rrdtool' for writing values to RRD-files
> 
> but i still have problems, several rrd graphs show empty (like irq),
> others show a broken image (like swap, error 404), and i dint see how
> to log the HDs IO like in v3... bugs or not implemented?

Many RRD files have changed and since the `collection.cgi' assumes
certain DS-names in the RRD-files it may fail with some graphs. I have a
patch from Peter Holik for collection.cgi which adds the IRQ-graphs.
Swap (, CPU, memory, ...) have been split up to several RRD-files for
more flexibility, thus the displaying script needs to get the values
from multiple RRD-files with one DS each, not one RRD-files with many
DSes.

Disk-octets, -operations and -times should still be logged, but here,
too, have the RRD-files been split up.

> also starting the collectd i get a warning about hddtemp:
> 
> Plugin `hddtemp' did not register a callback.

That is weird. Could you send the files `src/config.h' and/or
`config.log', both generated by ./configure?

> and finally, does v4 server can collect data from v3 clients?

No, and it's quite difficult to implement. The problem is that many
RRD-files have been changed and the compatibility code would need to do
the same the migration-script (`contrib/migrate-3-4.px') is doing.
However, using Sebastian's perl-plugin it might be possible to re-use
that code to write a collectd-plugin in perl to do this.

> it would be useful for those like me, using it in several machines, it
> would allow a upgrade without breaking the log. the alternative is to
> upgrade in a new dir in all machines and only then stop the v3 and
> start the new version.

I think the smoothest transition (from the viewpoint of your user,
customer, boss, ...) would be to install version 4 parallel to version 3
first. Then set it up and test if all the information you expected from
version is still there. (I expect you're doing this right now on a
smaller subset of the machines, which is exactly what I would have done
;) Then, when both systems work fully and parallel to each other, you
can start migrating the version 3 files to the version 4 data-directory.
This will overwrite any data collected by version 4 so far with data
collected by version 3, but, and this is the reason for doing it in this
order, without a gap. Hopefully. ;)

> thanks for the help

Thanks to you, too :) With questions like yours I can see much better
where more work is needed. Also, now I have some base-texts which I can
use when writing a migratioin-guide..

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/20070424/8391ac8e/attachment.pgp