Aggregate/combine several RRDs

[Jesper Skou Jensen]

Hi there,

I have used RRD for several years now, and am quite happy with it so
far. But I've only been using various tools to generate graphs and
stuff, but don't really know much about the structure of the RRDs.

Right now I'm trying to aggregate a bunch of RRDs into one, that is, I
have many RRD files that contains bandwidth/traffic "log" from some ADSL
connections, and I would like to aggregate those files in a way that I
can view the total bandwidth usage, both average and max. values.

Is that possible? If so, could you please give me some pointers on how
to get it done.

Thanks.


--

   Jesper S. Jensen
Basisnet og Sikkerhed
Uni-C - Århus, Danmark
    [phone]

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt]

On Thu, Jun 19, 2008 at 11:30:29AM +0200, Jesper Skou Jensen wrote:

> Hi there,
>
> I have used RRD for several years now, and am quite happy with it so
> far. But I've only been using various tools to generate graphs and
> stuff, but don't really know much about the structure of the RRDs.
>
> Right now I'm trying to aggregate a bunch of RRDs into one, that is, I
> have many RRD files that contains bandwidth/traffic "log" from some ADSL
> connections, and I would like to aggregate those files in a way that I
> can view the total bandwidth usage, both average and max. values.
>
> Is that possible? If so, could you please give me some pointers on how
> to get it done.

It sure is possible.  There will probably be tools available which
can do this. You could also study a bit and roll your own solution
for more flexibility.

Generally speaking:
Don't try to create one rrd with the combined information. Instead
collect data from multiple sources into one graph.

DEF:x1=sourc1.rrd:ds0:AVERAGE
DEF:x2=sourc2.rrd:ds0:AVERAGE
...
DEF:xn=sourcn.rrd:ds0:AVERAGE

DEF:y1=sourc1.rrd:ds0:MAX
DEF:y2=sourc2.rrd:ds0:MAX
...
DEF:yn=sourcn.rrd:ds0:MAX


Add all average values, add all maximums:

CDEF:xtotal=x1,x2,+,x3,+,...,xn,+
CDEF:ytotal=y1,y2,+,y3,+,...,yn,+

and then display.  But you will have unknown data in there, and
adding unknown to anything will produce unknown.

Instead of "x1", write "x1,UN,0,x,IF" to overcome this.  But make
sure to check out the various functions you can use, such as
AVG and TOTAL: http://oss.oetiker.ch/rrdtool/doc/rrdgraph_rpn.en.html

But don't start with such complex stuff.  Start as a beginner should
start: http://oss.oetiker.ch/rrdtool/tut/index.en.html

HTH
--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Simon Hobson-2]

Jesper Skou Jensen wrote:

>I have used RRD for several years now, and am quite happy with it so
>far. But I've only been using various tools to generate graphs and
>stuff, but don't really know much about the structure of the RRDs.
>
>Right now I'm trying to aggregate a bunch of RRDs into one, that is, I
>have many RRD files that contains bandwidth/traffic "log" from some ADSL
>connections, and I would like to aggregate those files in a way that I
>can view the total bandwidth usage, both average and max. values.
>
>Is that possible? If so, could you please give me some pointers on how
>to get it done.

Yes, and, try reading the list archive for the past couple of days in
that order - I'm sure it's been asked earlier this week !

Simply define multiple data sources using multiple DEF statements,
each one can be from a different file. Then draw a stacked graph to
show multiple values as a stack, or add them up with a CDEF statement
if you only want one area.

eg :

DEF:a=a.rrd:a:AVERAGE
DEF:b=b.rrd:b:AVERAGE
DEF:c=c.rrd:c:AVERAGE

CDEF:sum=a,b,+,c,+

Note that you can't get a MAX of the total traffic from a MAX of the
individual counters.

Eg, if you consolidate 3 samples into one, and they are 1,0,0 for a,
0,2,0 for b, and 0,0,1 for C :
MAX(a) is 1, MAX(b) is 2, MAX(c) is 1, sum of these would be 4, while
the actual max is only 2.


_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Jesper Skou Jensen]

Simon Hobson wrote:
> Yes, and, try reading the list archive for the past couple of days in
> that order - I'm sure it's been asked earlier this week !

D'oh, my bad... I googled my a*s off, but never found anything that was
quite what I was looking for, but I never thought of checking the
archives directly.

Alex van den Bogaerdt wrote:
 >Generally speaking:
 >Don't try to create one rrd with the combined information. Instead
 >collect data from multiple sources into one graph.

Oh yea, of course. Much simpler.


Thank you for your answers guys, now I'll just have to whip up a little
script to go through the RRD's.


--

   Jesper S. Jensen
Basisnet og Sikkerhed
Uni-C - Århus, Danmark
    [phone]

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

Jesper Skou Jensen <jesper.skou.jensen@...> writes:

> Thank you for your answers guys, now I'll just have to whip up a little
> script to go through the RRD's.

You may likely not even need a script to "go over". Simon sketched out
an example of how to draw from several RRD sources and apply
aggregatory functions in one single (!) graph call.

More specifically, the source RRDs in those DEFs can be different, so
you can define variables for data pulled from several sources and then
apply computations on them, in a single run. Just read the rrdgraph
man pages, and you'll see it's really not that hard.

The question is still of technical interest though, whether to create
intermediate RRDs for this kind of usage. This basically boils down to
the computing versus storage cost question I guess, plus the issue of
creating an additional point of error/failure.

I'm not currently aware of rrdtool directly supporting this kind of
intermediate RRDs, but would be interested to hear if somebody made
an attempt on this and got it working.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Erik de Mare]

<a06240803c4806dbecc64@...>
<485B59E8.5070709@...> <87lk101rkx.fsf@...>
Message-ID: <e00e5f6b378c77e565e687f424145f6c@...>
X-Sender: erik@...
User-Agent: RoundCube Webmail/0.1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit




On Fri, 20 Jun 2008 09:41:18 +0200, "Raimund Berger"
<raimund.berger@...> wrote:
> Jesper Skou Jensen <jesper.skou.jensen@...> writes:
>
>> Thank you for your answers guys, now I'll just have to whip up a little
>> script to go through the RRD's.
>
> I'm not currently aware of rrdtool directly supporting this kind of
> intermediate RRDs, but would be interested to hear if somebody made
> an attempt on this and got it working.

I once did something like this. it takes all the rrdfiles from the dir and
graphs them in 1 PNG.(assuming that all the rrdfile have the same DS and
RRA.)

http://haas.oezie.org/~erik/allesbijelkaar.pl 

example output: http://haas.oezie.org/~erik/total.png the numbers are all
the same because I copied the same file over and over again.

Mvg,
Erik


_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt]

On Fri, Jun 20, 2008 at 09:41:18AM +0200, Raimund Berger wrote:

> The question is still of technical interest though, whether to create
> intermediate RRDs for this kind of usage. This basically boils down to
> the computing versus storage cost question I guess, plus the issue of
> creating an additional point of error/failure.

Creating another RRDfile isn't hard to do.  Filling it with numbers
isn't hard either.  The biggest challenge is to get your minimum and
maximum rates correct.

When reading a previous RRD (e.g. with fetch) you will get rates.
This probably means your new RRD should have data source type GAUGE.

If you need to be able to set minimum, maximum and average, you will
need to compute a combination of three updates per interval which
get it exactly right.

Thinking out loud, hoping that someone else can point this group
to a better algorithm or knows shortcuts:

Goal: set Rmin, Ravg, Rmax (minimum,average,maximum rate) for one
RRDtool interval (e.g. in the RRA which has 86400 seconds per CDP,
two years back).  Obviously this means heartbeat should allow for
such a large interval.

Take Ravg as the basis. Needed: find two intervals Tmin and Tmax
so that Rmin*Tmin + Rmax+Tmax equals Ravg*(Tmin+Tmax). In addition
to this, Tmin+Tmax cannot be larger than Tavg (the entire interval
duration).

Start by setting both Tmin and Tmax to half Tavg.

If (Rmin+Rmax)<Ravg {
    decrease Tmin, but no shorter than 1 second.
    If (Rmin*Tmin+Rmax*Tmax) is still < Ravg*Tavg, increase Tmax. It
    should never happen that Tmax becomes >= Tavg. (error condition)
} elseif (Rmin+Rmax)>Ravg {
    decrease Tmax, but no shorter than 1 second.
    If (Rmin*Tmin+Rmax*Tmax) is still > Ravg*Tavg, increase Tmin. It
    should never happen that Tmin becomes >= Tavg. (error condition)
}
The new Tavg becomes Tavg-(Tmin+Tmax).  If it is <0 then there has
to be something wrong in the source RRD.  Abort.

Now perform two or three updates:
* update with Rmin for Tmin
* update with Rmax for Tmax
* if Tavg is not zero, update with Ravg for Tavg.


To visualize this algorithm:
Think of a rectangle "A", Ravg high and Tavg wide.  Overlayed are two
other rectangles "B" and "C": Rmin high half Tavg wide, and Rmax high
half Ravg wide.  In the process a rectangle "D" can be created, Ravg
high and just wide enough to that the combined width of B+C+D equals
the width of A.

The algorithm looks at the average height of the two smaller rectangles.
If it happens to be just fine, the if-then-else does nothing.

If the average is too low, rectangle B needs to become smaller.
If it cannot be made small enough, rectangle C needs to be taller.

Similarly: if the average is too high, rectangle C needs to be made
smaller and, if still not good, B needs to be taller.

If the combined width of B and C is larger than that of A, then I
believe something has to be wrong in the original data.  If it is
smaller, then just fill the remaining time with rectangle D which,
due to its height, has no impact on the average.


What do you think?  Am I on the right track here?  Has someone
already implemented this or a similar technique?

And should we discuss this here or on rrd-developers?

--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

Alex van den Bogaerdt <alex@...> writes:

> On Fri, Jun 20, 2008 at 09:41:18AM +0200, Raimund Berger wrote:
>
>> The question is still of technical interest though, whether to create
>> intermediate RRDs for this kind of usage. This basically boils down to
>> the computing versus storage cost question I guess, plus the issue of
>> creating an additional point of error/failure.
>
> Creating another RRDfile isn't hard to do.  Filling it with numbers
> isn't hard either.  The biggest challenge is to get your minimum and
> maximum rates correct.
>
> When reading a previous RRD (e.g. with fetch) you will get rates.
> This probably means your new RRD should have data source type GAUGE.

Right. The assumption would likely be to create an intermediate
RRD/RRA with same feed interval as the source(s) but basically no
consolidation on whatever you do with that data, i.e. primarily
graphing I guess. Anything else would lead into computational and
interpretational fine print, as you further line out.

And agreed, fetch and update via a script should not be too hard to
accomplish.

I have to take a rain check on the algorithmic discussion
though. Consecutive appliance of a min, max, average, last function
set in the various possible permutations while retaining some distinct
meaning and purpose is beyond my scope right now.

Thanks, R.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

Erik de Mare <erik@...> writes:

> <a06240803c4806dbecc64@...>
> <485B59E8.5070709@...> <87lk101rkx.fsf@...>
> Message-ID: <e00e5f6b378c77e565e687f424145f6c@...>
> X-Sender: erik@...
> User-Agent: RoundCube Webmail/0.1b
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
>
>
>
> On Fri, 20 Jun 2008 09:41:18 +0200, "Raimund Berger"
> <raimund.berger@...> wrote:
>> Jesper Skou Jensen <jesper.skou.jensen@...> writes:
>>
>>> Thank you for your answers guys, now I'll just have to whip up a little
>>> script to go through the RRD's.
>>
>> I'm not currently aware of rrdtool directly supporting this kind of
>> intermediate RRDs, but would be interested to hear if somebody made
>> an attempt on this and got it working.
>
> I once did something like this. it takes all the rrdfiles from the dir and
> graphs them in 1 PNG.(assuming that all the rrdfile have the same DS and
> RRA.)
>
> http://haas.oezie.org/~erik/allesbijelkaar.pl 
>
> example output: http://haas.oezie.org/~erik/total.png the numbers are all
> the same because I copied the same file over and over again.

Right, that's exactly what OP was asking about (and maybe even for) I
guess. That script nicely demonstrates how to stack up several sources
and computations on their data for a single graph call.

Thanks, R.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

"Raimund Berger" <raimund.berger@...> writes:

>> Creating another RRDfile isn't hard to do.  Filling it with numbers
>> isn't hard either.  The biggest challenge is to get your minimum and
>> maximum rates correct.
>
> And agreed, fetch and update via a script should not be too hard to
> accomplish.

Correction, not agreed. I forgot what I initially had in mind as being
the main obstacle to storage of computed intermediates, i.e. fetch
provoding no cdef.

While you can perform various computations on your input with graph
via cdef, I don't see a similar facility coming with fetch and/or
companions. So apparently, there's no way to stash those computed
results away in an RRD.

R.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt]

On Fri, Jun 20, 2008 at 10:37:31PM +0200, Raimund Berger wrote:

> "Raimund Berger" <raimund.berger@...> writes:
>
> >> Creating another RRDfile isn't hard to do.  Filling it with numbers
> >> isn't hard either.  The biggest challenge is to get your minimum and
> >> maximum rates correct.
> >
> > And agreed, fetch and update via a script should not be too hard to
> > accomplish.
>
> Correction, not agreed. I forgot what I initially had in mind as being
> the main obstacle to storage of computed intermediates, i.e. fetch
> provoding no cdef.
>
> While you can perform various computations on your input with graph
> via cdef, I don't see a similar facility coming with fetch and/or
> companions. So apparently, there's no way to stash those computed
> results away in an RRD.

Have you looked at rrdtool xport ?

--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

Alex van den Bogaerdt <alex@...> writes:

> On Fri, Jun 20, 2008 at 10:37:31PM +0200, Raimund Berger wrote:
>> "Raimund Berger" <raimund.berger@...> writes:
>>
>> >> Creating another RRDfile isn't hard to do.  Filling it with numbers
>> >> isn't hard either.  The biggest challenge is to get your minimum and
>> >> maximum rates correct.
>> >
>> > And agreed, fetch and update via a script should not be too hard to
>> > accomplish.
>>
>> Correction, not agreed. I forgot what I initially had in mind as being
>> the main obstacle to storage of computed intermediates, i.e. fetch
>> provoding no cdef.
>>
>> While you can perform various computations on your input with graph
>> via cdef, I don't see a similar facility coming with fetch and/or
>> companions. So apparently, there's no way to stash those computed
>> results away in an RRD.
>
> Have you looked at rrdtool xport ?

That one looks better, thanks a lot.

Incidentally, and as I admittedly didn't look at those xml outputs
very closely yet, do you know if xport does write dump format, so it's
output can directly be fed into restore again?

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Alex van den Bogaerdt]

On Fri, Jun 20, 2008 at 11:37:24PM +0200, Raimund Berger wrote:

> > Have you looked at rrdtool xport ?
>
> That one looks better, thanks a lot.
>
> Incidentally, and as I admittedly didn't look at those xml outputs
> very closely yet, do you know if xport does write dump format, so it's
> output can directly be fed into restore again?

No, I don't know. But if I may guess: no, I don't think it can.

--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Raimund Berger]

Alex van den Bogaerdt <alex@...> writes:

> On Fri, Jun 20, 2008 at 11:37:24PM +0200, Raimund Berger wrote:
>
>> > Have you looked at rrdtool xport ?
>>
>> That one looks better, thanks a lot.
>>
>> Incidentally, and as I admittedly didn't look at those xml outputs
>> very closely yet, do you know if xport does write dump format, so it's
>> output can directly be fed into restore again?
>
> No, I don't know. But if I may guess: no, I don't think it can.

That was my initial guess when I said "not directly supported". So to
kind of finally answer OP's question, the kind of data aggregation he
asked for is apparently best supported only when graphing.

If he still wants to sample the aggregated data into an intermediate
RRD to save cpu cycles, he has to do xports, because only those
provide the defs and cdefs he presumably wants to perform, and then
parse the xml output into corresponding update calls himself.

If he does an attempt on this, as already said, the intermediate data
type should likely be gauge, to avoid distortion due to rrdtool rate
calculations, and there should best be no consolidation function
performed for the same reason, i.e. steps=1 in the RRA definition.

That's at least what I understand at this point.

R.

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Robert-91]

Hi list,

Every single version of rrdtool I tried on Solaris 10 is failing on "make install", any suggestions? and binaries downloaded from Soilaris freeware are missing RRDs.so in

 

/usr/local/rrdtool-1.2.15/lib/perl/5.8.4/sun4-solaris-64int/auto

 

 

ld: fatal: Symbol referencing errors. No output written to .libs/rrdtoolmodule.so
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `rrdtoolmodule.so'
Current working directory /export/home/raj/rrdtool-1.2.19/bindings/python
*** Error code 1
The following command caused the error:
failcom='exit 1'; \
for f in x $MAKEFLAGS; do \
  case $f in \
    *=* | --[!k]*);; \
    *k*) failcom='fail=yes';; \
  esac; \
done; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list=' python'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" = "."; then \
    dot_seen=yes; \
    local_target="$target-am"; \
  else \
    local_target="$target"; \
  fi; \
  (cd $subdir && make  $local_target) \
  || eval $failcom; \
done; \
if test "$dot_seen" = "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/home/raj/rrdtool-1.2.19/bindings
*** Error code 1
The following command caused the error:
failcom='exit 1'; \
for f in x $MAKEFLAGS; do \
  case $f in \
    *=* | --[!k]*);; \
    *k*) failcom='fail=yes';; \
  esac; \
done; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list='src bindings doc examples'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" = "."; then \
    dot_seen=yes; \
    local_target="$target-am"; \
  else \
    local_target="$target"; \
  fi; \
  (cd $subdir && make  $local_target) \
  || eval $failcom; \
done; \
if test "$dot_seen" = "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/home/raj/rrdtool-1.2.19
*** Error code 1
make: Fatal error: Command failed for target `all'

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

[Jesper Skou Jensen]

Erik de Mare wrote:
> I once did something like this. it takes all the rrdfiles from the dir and
> graphs them in 1 PNG.(assuming that all the rrdfile have the same DS and
> RRA.)
>
> http://haas.oezie.org/~erik/allesbijelkaar.pl 
>
> example output: http://haas.oezie.org/~erik/total.png the numbers are all
> the same because I copied the same file over and over again.

Sweet. That did almost what I wanted. With a little bit of fine-tuning
it was exactly what I needed.

Thank you very much.


--

   Jesper S. Jensen
Basisnet og Sikkerhed
Uni-C - Århus, Danmark
    [phone]

_______________________________________________
rrd-users mailing list
rrd-users@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users