[collectd] Re: collectd: quota

[Florian Forster]

Hi again,

On Fri, Nov 25, 2005 at 04:25:04PM +0100, Niki 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)?

Since I receive amazingly many contributions a documents describing
common pitfalls would be good to have, but I don't have much free time
on my hands at the moment :/ I'll summarize in short how the process
works and what's important:
- A define, e.g. `COLLECT_<MODULE>', is used to decide wether or not to
  build a module. That define is eventually defined to `0' by the
  configure script. If it's not defined some reasonable default should
  be set (i.e. check if needed libraries exist, check the operating
  system, etc..)
- A module has four main parts
  * init
    Initialize the plugin. This routine should find values that hardly
    ever change (number of processors, interfaces, ...). This routine is
    used upon startup and may be called again. So you have to (re)set
    any module-global counters for example..
    On Linux this routine might be used to decide wether to use /sys or
    /proc, for example..
  * read
    Get the values from whereever.. The values are then passed to
    `submit'. This function is normally very platform dependend. Use
    #if and #elsif to decide with implementation to use..
  * submit
    Submit transforms the different values into a string that is passed
    to rrdtool sometime later. Though it's not absolutely neccessary I
    strongly suggest it, so the possibly system dependend `read' routine
    uses a uniform `interface' for it's values..
    The string is then passed to `plugin_submit'. That value may then
    send the value over a network, encrypt it before it does so or do
    other weird stuff with that..
  * write
    This function is called by the `plugin' module. It calculates the
    filename of the RRD file (`<module>.rrd' or <module>-<instance>.rrd
    is preferred). Then it calls `rrd_update_file' with the newly
    calculated filename and the DS-definitions.

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

Take a look at `rrd.h':
-- 8< --
/* Transplanted from rrd_format.h */
typedef double       rrd_value_t;         /* the data storage type is
                                           * double */
-- >8 --

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

There are many numbers stored in the various headers, too, so making all
that endian independend is no fun ;) I haven't heard any `official'
statement though, possibly Tobi would accept such a patch ;)

> > Summary: The multicast traffic should be encrypted. He's looking into
> >   it..
> i see your point. however. i'll first try to get the quota plugin
> going.

No hurry ;) I haven't heard any security concerns yet.. (besides your
mail of couse)

Hope this helps you, I'll hope to get this pile of work off my desk
tonight so I have all of tomorrow to at last release version 3.4.0..

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/20051125/d6fbe910/attachment.pgp