[Perfparse-devel] Re: Use of RRD

[Yves M. <yme...@li...>]

> Garry, Yves,
>
> I want to talk about RRD, however I have lost the original thread.
>
> Let me explain my worries about using RRD.  Please correct me where I a=
m
> going wrong.

My comments will be my explanations.
Garry has his own opinion (I agree with him for most of what he said).

>
> Round Robin Database gives a method of storing a fixed period of data
> which is stored locally and may be graphed by many available open sourc=
e
> programs.  This is a fast self-purging method liked by many people.
>
> But what are we proposing?
>
> i) Using just RRD.
>
> ii) Using RRD for storage of Binary data, and a DBMS for everything els=
e.
>
> iii) Using PP as is, but also store data in RRD.

iv) Using RRD for storage of Binary data, and a DBMS for *all*

Well, propose everything !
Some may only use the perfparse binary (not the CGI...) to create RRD fil=
es and use them
with other tools. Some may need database storage. Some may need both...

I my mind, there is only a --rrd-dump=3Drrdfile option to add in perfpars=
e.c and to support.
Those who want to graph the data from the rrdfile will use their own tool=
s, and maybe
some may send us a contribution ?

> I have seen some comments about using (i), just RRD.
>
> If we do this, the product we will have effectively is not PerfParse.
> - There will be no storage of raw data.

For now, this is not a problem for me: I use only binary data.

> - The extra information we plan, like a range of WARN and CRITICAL
> values will not be supported.

This is a choice I can do for here. My need is that the extra information=
s are parsed. I
don't mind they are not stored.
And there is a hack we can do: store them as another value. The rrdfile w=
ill grow
faster, with 5 values instead of 1 (val, warnmin, warnmax, critmin, critm=
ax)

> - The product will not be client/server, and therefore the whole of PP
> must be using on a single machine.

I need this. So I need the database (except if we make another server/cli=
ent system, but
this is not planned, and we have enough of them for now)

>
> Effectivelly, the entire PP CGI is redendent and we should probably
> advise users to use one of the existing mature RRD viewers.  This will
> mean that PP is reduced to just the 'perfparse' program, which it's sel=
f
> is reduced to just storing binary values in an RRD database.
>
> I don't think we want to do this. :)

I think that some want it. You would not have so many mails about it othe=
rwise.

> With option (ii), using RRD for the binary data.  This also presents
> some problems:
>
> - Extra data, like range of WARN and CRIT cannot be supported in full.
> Although two lines for each can be stored to indicate range.  Messy!

The users make the choice.

> - Half of PP is client/server, half is local.

This is good for data storage. Few data central, a lot of data on each mo=
nitored machine.
If the CGI could ask each monitored machine for the data, it would be bet=
ter for data
storage : save the data with your usual backup procedure. It would also b=
e better for
network traffic: only the needed values go on the network.
Sadly, it is more complex to implement this because of the client-server =
issue.

> - Referential Integrity is hard to maintain using two different databas=
e
> types.
> - Lots of re-coding to get the chart to read RRD data.

About this: probably like you, I fully disagree about the CGI reading RRD=
 data.
I agree with feeding RRD files, but exploitation of RRD files has to be d=
one with other
tools (that can be part of the perfparse project, one day, why not ?)

> Again, I wonder whether this is worth it, although there might be an
> argument.
>
>
> My feeling is that we should provide an option the user can select when
> compiling:
>
> 1. Store data as RRD for their own use, or not.
> 2. Store data as PP format, or not.

Yes :)
My own reflexion results in the same conclusion :)

Yves
>
> In the second case, we are effectively providing a method to import dat=
a
> into RRD, and the users chooses not to use any of the other features we
> provide.
>
> As always, I look forward to your comments.
>
> Ben
>
>
>
>
>


--=20
- Homepage    - http://ymettier.free.fr - http://www.logicacmg.com -
- GPG key     - http://ymettier.free.fr/gpg.txt                    -
- Maitretarot - http://www.nongnu.org/maitretarot/                 -
- GTKtalog    - http://www.nongnu.org/gtktalog/                    -