More comfortable chart display

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

More comfortable chart display

alix-r

Hello,

I don't want to complain about the way RRDTOOL displays recorded data. I'm
explicitly quite
happy with all the options  RRDTOOL offers!

Nevertheless, I'm looking for an other tool which can display the stored
data (I converted them to XML)
in a more comfortable way.

The reason is , I'm logging about 30 temperatures over a period of 3 month
any minute. The data base
is organized that way, that I can get all one minute temperatures over the
hole 3 month. My problem
now is to select a certain time area of my interest and zoom it, so I can
identify the results of
certain external events. That is a bit difficult to realize with RRDTOOL
GRAPH and quite time-consuming.
(provided I used the right features of that really powerful tool).

Does anybody know a tool which allows to display a XML data set generated by
rrdtool , in a way  I could
quickly move to a certain time position and quickly zoom in the area around
that position ? I would
prefer a tool running on Windows, but Linux would also be ok.

Thank you very much.

Robert


--
View this message in context: http://www.nabble.com/More-comfortable-chart-display-tp21641750p21641750.html
Sent from the RRDTool - User mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: More comfortable chart display

Martin Sperl-4
Hi!

A colleague of mine has written a java-script a few years ago that was
able to take a dynamically created rrd-graph (based on a cgi-script that
takes arguments for start, end, min and max) and allowed us to zoom into
the image by selecting the "interresting area". Sadly this code is no
longer available to me (and also a copyright issue...).

This was working quite well, but was not perfect, as we were not able to
enlarge the size of the image itself, as then all the scaling would have
gone astray. Other effecting parameter are: Label of Y-Axis, Title
(maybe multiline), font-size,... So there is the need to get the scale
and the "graph area within the image" without to much guesswork or
assumptions about the graph layout.

So what I see that you would need to create is:
* a cgi-script tat can create the graph dynamically based on the
arguments you give - I believe that several people have creates some
cgis like these, but as usual these tend to be highly "use-case"
specific... This is really not very complex and you should be able this
with a few lines of perl/php/ruby code (depending on available language
bindings).
* a javascript that does handle this "selection" and does a reload of
the image as soon as the selection is done.

Then you should be able to handle your requirements for showing such a
graph without having to create a separate graphing tool, which would
introduce additional overhad and lead you to reinventing the wheel like
how to do "Axis labels" placements (which RRD tool is handling quite nicely)

To avoid the "scaling" problems within the Image itself, maybe we
should  think of how we can extend rrdtool so that it can embed the
drawing area and the X/Y-scale information into the PNGs or JPGs - e.g.
write EXIF information - and then have the javascript use the provided
information for scale calculations.
(For the JavaScritpt accessing the information this code maybe a
starting point:
http://blog.nihilogic.dk/2008/08/imageinfo-reading-image-metadata-with.html)

Actually I believe that a few people would like such a capability for
rrdtool...

Ciao,
          Martin

alix-r wrote:

> Hello,
>
> I don't want to complain about the way RRDTOOL displays recorded data. I'm
> explicitly quite
> happy with all the options  RRDTOOL offers!
>
> Nevertheless, I'm looking for an other tool which can display the stored
> data (I converted them to XML)
> in a more comfortable way.
>
> The reason is , I'm logging about 30 temperatures over a period of 3 month
> any minute. The data base
> is organized that way, that I can get all one minute temperatures over the
> hole 3 month. My problem
> now is to select a certain time area of my interest and zoom it, so I can
> identify the results of
> certain external events. That is a bit difficult to realize with RRDTOOL
> GRAPH and quite time-consuming.
> (provided I used the right features of that really powerful tool).
>
> Does anybody know a tool which allows to display a XML data set generated by
> rrdtool , in a way  I could
> quickly move to a certain time position and quickly zoom in the area around
> that position ? I would
> prefer a tool running on Windows, but Linux would also be ok.
>
> Thank you very much.
>
> Robert
>
>
>  

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: More comfortable chart display

oetiker
Administrator
Hi Martin,

as for the javascript part, there is code for this in smokeping ...

getting more meta information from rrdtool is also implemnted
through the graphv call.

check it out!

cheers
tobi


--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: More comfortable chart display

Martin Sperl-4
Well, Alex - there is an approach for you...

As for graphv, nice - it gives the basic information and could be used
to add this information external to rrdtool - I still think it would be
"nicer" to have rrdtool do it in a standardized way without having to
reinvent the wheel repeatedly...

On closer inspection I would say that something is missing from the
output of graphv, which could introduce problems: the min/max time is
not given!
Imagine, that we create an initial graph with the parameters: "--start
-2weeks --end now" the javascript also would need to translate "-1week"
and "now" back to a real time and it could do it differently  than
rrdtool (e.g: using the wrong timezone for conversion, or the more
complex translation cases that rrdtool handles "-1day+6hours", ...)

So maybe we should add this to the output of graphv as well for
completeness.

Otherwise we will again need to add it separately by calling RRDs::times
and "enriching" the graphv output  with this information. But then as
this is 2 different calls to RRD, you will potentially get slight
deltas, depending on the sequence and the complexity of the graphs
(graphs with more than 1000 DEFs take some time to generate;)

Ciao,
          Martin

Tobias Oetiker wrote:

> Hi Martin,
>
> as for the javascript part, there is code for this in smokeping ...
>
> getting more meta information from rrdtool is also implemnted
> through the graphv call.
>
> check it out!
>
> cheers
> tobi
>
>
>  

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: More comfortable chart display

oetiker
Administrator
Hi Martin,

Today Martin Sperl wrote:

> Well, Alex - there is an approach for you...
>
> As for graphv, nice - it gives the basic information and could be used to add
> this information external to rrdtool - I still think it would be "nicer" to
> have rrdtool do it in a standardized way without having to reinvent the wheel
> repeatedly...
>
> On closer inspection I would say that something is missing from the output of
> graphv, which could introduce problems: the min/max time is not given!
> Imagine, that we create an initial graph with the parameters: "--start -2weeks
> --end now" the javascript also would need to translate "-1week" and "now" back
> to a real time and it could do it differently  than rrdtool (e.g: using the
> wrong timezone for conversion, or the more complex translation cases that
> rrdtool handles "-1day+6hours", ...)
>
> So maybe we should add this to the output of graphv as well for completeness.

good point ... something like this ?

--- rrd_graph.c (revision 1737)
+++ rrd_graph.c (working copy)
@@ -3115,6 +3115,10 @@
     grinfo_push(im, sprintf_alloc("image_width"), RD_I_CNT, info);
     info.u_cnt = im->yimg;
     grinfo_push(im, sprintf_alloc("image_height"), RD_I_CNT, info);
+    info.u_cnt = im->start;
+    grinfo_push(im, sprintf_alloc("graph_start"), RD_I_CNT, info);
+    info.u_cnt = im->end;
+    grinfo_push(im, sprintf_alloc("graph_end"), RD_I_CNT, info);

     /* get actual drawing data and find min and max values */
     if (data_proc(im) == -1)


cheers
tobi

>
> Otherwise we will again need to add it separately by calling RRDs::times and
> "enriching" the graphv output  with this information. But then as this is 2
> different calls to RRD, you will potentially get slight deltas, depending on
> the sequence and the complexity of the graphs (graphs with more than 1000 DEFs
> take some time to generate;)
>
> Ciao,
>          Martin
>
> Tobias Oetiker wrote:
> > Hi Martin,
> >
> > as for the javascript part, there is code for this in smokeping ...
> >
> > getting more meta information from rrdtool is also implemnted
> > through the graphv call.
> >
> > check it out!
> >
> > cheers
> > tobi
> >
> >
> >
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users