[rrd-developers] Demo: RRD - Web 2.0 style
Peter Stamfest
peter at stamfest.at
Thu Oct 14 08:17:28 CEST 2010
Tobias Oetiker <tobi at oetiker.ch> schrieb am 14.10.2010 07:28:15:
> Hi Peter,
>
> Yesterday Peter Stamfest wrote:
>
> > Tobias Oetiker <tobi at oetiker.ch> schrieb am 13.10.2010 23:09:45:
> >
> > > Today Peter Stamfest wrote:
> > >
> > > > Hi everybody!
> > > >
> > [...]
> > > >
> > > > Has this been done before?
> > >
> > > yep ... that was about the state I was at as well when I was
> > > hacking this last time ... got side tracked though ... :-(
> > >
> > > in any event, things should be simpler now since the graphv
> > > interface gives lots of 'sensible' information and could also be
> > > easily enhanced to give more info if required.
> >
> > This actually *is* using graphv. And as I said, the major pain was the
> > missing absolute time frame in the generated picture.
>
> I thought graph_start and graph_end to be useful for this ...
This is a misunderstanding. I am using graph_start and graph_end. It is
just that in a standard image, you never know if "13:20" refers to
2010-10-13 or 2005-09-27 *visually*.
And this was the major problem, because the rest was so ... simple.
> >
> > I'm unsure what kind of support would be needed to enhance
responsibility:
> > It might make sense to somehow keep data ready for graphing multiple
> > times, but I am unsure about a usable interface in order to keep
rrdtool
> > and this web 2.0 thing separate...
>
> I would have two graphs ... a wide long one below and the detail
> one above ...
I thought about an approach where the server would generate a longer graph
once and many move requests would access this image and rearrange slices
from it into a new graph, but this has *many* problems:
- time resolution for an entire graph always is determined by the lowest
time resolution in any part of the graph
- vertical resolution depends on the difference between highest and lowest
value (mod command line settings)
- time axis labelling would be a real pain as well
Before settling for the use of rrdtool for graphing, I investigated some
client-side only approaches (using things like
http://www.simile-widgets.org/), but that didn't work very well.
The current approach has the advantage that it might be "clouded": Just
add more CPU power to RRD graphing and motion gets smoother. One might
also "precreate" intermediate images.
Another possibility would be to translate all of rrdgraph into javascript
and use an HTML canvas, accessing the RRD data through AJAX. I think this
is what will happen in the long run..... but it would expose raw RRD data
to the world, something that is often not really wanted.
peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20101014/c45ea660/attachment-0001.htm
More information about the rrd-developers
mailing list