[rrd-developers] Demo: RRD - Web 2.0 style
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
> > 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
> > 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rrd-developers