[collectd] Re: collectd: quota

[Niki Waibel]

On 24-Nov-2005 Florian Forster wrote:
> 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..

ok, so sorry about writing german...

> On Thu, Nov 24, 2005 at 07:25:58PM +0100, Niki W. Waibel wrote:
> Summary: Has anyone written a plugin to monitor disk quotas?
> 
> Not to my knowledge..

so i am going to start that (this night).
any suggestions/directions so far (before i start)?

> 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 ;)

hehe -- those linux users. i usually use /misc/$cpu-$vendor-$os/opt
and have links in /misc/$cpu-$vendor-$os/bin, /misc/$cpu-$vendor-$os/lib, ...
that way i can have everything on a network share, not messing around with
any local install.

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

that would be a very clean solution (and is actually what i wanted to
point out).

> 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..

i knew that for 1.0... has anyone out there tested that for 1.2?
or asked the author of rrdtool about a statement?

i thought it was only an endian issue... a switch in rrdtool to
force some byte sex would be very nice to have.

> 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 see your point.

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

however. i'll first try to get the quota plugin going.

> 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..

i think i'd like to discuss this later. i am very new to this
program. so i'll watch for a while what's going on on the mailinglist.

dont want to push in too much complains/arguments at this point.
things might have been already discussed...

> 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 :)

we'll keep contact. just subscribed to the list.

niki