[collectd] Re: collectd: quota

[Florian Forster]

Hello Niki,

I'll answer your mail in english so the people on the mailinglist
understand what I'm saying/writing. Maybe one of them has a strong
opinion about the issues raised here..

On Thu, Nov 24, 2005 at 07:25:58PM +0100, Niki W. Waibel wrote:
> wollte fragen ob du weisst ob schon jmd ein plugin fuer disk-quotas
> geschrieben hat. disk.c ist fuer meine anwendung zu "ungenau".

Summary: Has anyone written a plugin to monitor disk quotas?

Not to my knowledge..

> oh, noch was. /var/lib/collectd sollte relativ zu ${prefix} sein.

Summary: The data directory should be relative to PREFIX (as given to
  ./configure)

You have a point, but then again I dislike having data in `/usr/var' or
binaries in `/bin'.. My favorite solution would be to put the binary in
`/opt/collectd-$version/bin' and the RRD files in
`/opt/collectd-$version/lib', but I guess the Linux folks would kill me
for that ;)

I'll most likely make it possible to configure it (the data directory)
using `--localstatedir' and change the plugin directory using
`--libdir'..

> (lib, wenn die daten irgendwie platform-abhaengig sind (ist das bei
> rrd-1.2 noch so?), ansonsten log (evtl auch db)).

Summary: Are RRD files platform dependend?

Yes, they are. At least using RRDTool 1.0 an `rrd value' is simply a
double which is platform dependend.. I'd guess that, when using
`COUNTER' the values stored are 64 bit integers, but that's just a
guess..

> ich hab hier einige solaris u linux rechner. die multicast
> idee uebers netzwerk ist gut. allerdings sollte der traffic
> verschluesselt und authentifiziert sein. mal schauen ob ich
> da mit openssl was dazubasteln kann (weiss nicht ob es sich
> zeitlich ausgehen wird)...

Summary: The multicast traffic should be encrypted. He's looking into
  it..

The problem is, that I don't want any server->client traffic. I.e., the
client shall not know which servers exist. This leaves us with three
options:
1) Use one private key for all servers
2) Use authentication only (i.e. sign the traffic, but don't encrypt)
3) Use symmetric encryption

I think I'd go for solution #2, but that's more a feeling than having
any strong reasons for it ;)

> was mir nicht so gut gefaellt sind die fixen vorgaben
> bei den rrd's. ich brauche eine datenhaltung auf 10 jahre
> und fuer die ersten jahre eine hoehere aufloesung.

Summary: RRAs should be configurable, especially the amount of data kept
  for each resolution and the resolution itself.

The resolution issue has been brought up before, but with the opposite
direction: So increase the initervals at which data is collected. The
arguments against letting the user change that interval are:
- Amount of data kept in each RRA changes, which may lead to unexpected
  resolutions when drawing the graphs
- RRD files created by one instance may have holes are work `different'
  when used with another instance

While I'm tempted to give in and make the `step' configurable (assuming
that people who decrese it know what they do) I will not make the size
of an RRA configurable (unless someone gives me a good reason).
My reasons are:
- It scares users
- It can be adjusted easily
- It's one place in the source that needs to be touched if you want to
  compile it in
- It's a mess to `configure' this at compile time

If anyone disagrees with me there and has reasons to do it anyway or
doesn't agree with my arguments, please tell me..

Niki, thanks for you feedback and requests, I'm looking forward to hear
from you again. Please let me know when your thesis is done :)

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/20051124/54e8a4b2/attachment.pgp