Hey guys,
----- Original Message -----
>
> > [...]
> > [pmval] a relatively simple tool, but I think it has just enough complexity
> > to start showing where I think cracks will first appear. Ignoring all
> > the libpcp magic that we'll need to make happen with whatever scheme we
> > use, can you describe the changes that will be needed there to make host
> > mode go back in time and then move forward to seamless live fetching?
> > I literally do not think its possible with just a pmSetMode() addition,
> > with current pmFetch semantics for live mode, and the way the current
> > tools use it - see the call to __pmtimevalSleep(delta) in particular.
>
> Just before, you were talking about backward-compatibility concerns.
> But now, we're talking about the showcase scenario of how existing
> clients could be minimally adapted to live-archiving: scrolling back
> and forth in time. IOW, what would be the minimal changes to pmval to
> have "pmval -h ..." support scrolling in time. (I don't know what
> you're referring to by "cracks".)
Yep, sorry - its barely English that above paragraph of mine - more
braindump than valid prose. Cracks just referred to "where I think
things will start to not work as we'd hope/expect", as in...
> ...
> That may be all, as far as the pmval.c changes are concerned. Things
> like this should start working:
>
> % pmval -S '-30 days' -d -h SERVERHOST foo.metric
Assuming there's 30 days worth of data to be found, I think the above
(thanks to that pesky __pmtimevalSleep in pmval.c) will take ~30 days
to print its first live sample (default pmval sampling interval being
1 second). Am I missing something? (not sure why you went with "-d"
here - doesn't help us AFAICT...?)
That sleep is the central point here & it embodies the core problem,
as I see it, which is that host context API callers will sleep before
fetching (the sampling interval is implemented by the tool, and not
inside libpcp). Changing that is a big change to live mode fetch
semantics. Of course, no sleep is needed in archive mode - we want
that data as rapidly as possible, but we now have one.
So, as a user, what I'd expect to see the above invocation do is to
dump out all that historical data immediately, and then begin the
sampling of live data (assumes the tool sleeps in-between samples,
such that each sample is taken at an appropriate time).
> Is the above the sort of thing you were looking for?
Yep, spot on - my brain functions best with examples for some reason
& this made things clearer for me at least (in particular, wasn't
sure if there were more extensive changes you had in mind) - thanks!!
cheers.
--
Nathan
|