Hi, Nathan -
> > possibly using an
> > dynamically-reconfigured archive there as an intermediary. And this
> > enables functionality that your scheme doesn't:
>
> Minor point, but lets not talk about "yours" or "mine", please; there's
> multiple problems, and multiple potential solution vectors. [...]
(Of course - I was not being personal, just abbreviating to identify
the schemes.)
> > automatically
> > archiving data that any live-mode client asks for, so that transitions
> > between the long-past, the just-past, and live-mode are seamless.
>
> Here, you're saying "enables xxx, and thats good", whereas I'm saying
> "mandates xxx, and thats bad" - I'm unconvinced that all tools that want
> the usability features we're talking about here should *have* to record
> the data first.
Right. That should be another configurable option.
> We're fundamentally disagreeing on that aspect I think,
> and I'm certain the some-PMAPI-tool -> tell-pmlogger-what-to-log-when ->
> await-the-results-on-disk -> fetch-them-from-disk model is going to be
> more complex than the transition-from-log-direct-to-pmcd-fetch model).
The model (what the client does & sees) would not be different.
Whether there is a hidden pmlogger instance & managed at the server
would not be visible to a classical client, except perhaps by latency.
> [*] Hmmm, thinking out loud - it just won't work at all, will it? - how
> does the client tool expand the available (live, now) namespace without
> talking to pmcd to know what to tell pmlogger to log in the first place?
Yes, that's a tricky point. The live-archive server would have to
talk to a pmcd, in order to enumerate the PMNS. This could be done
- indirectly, via a large extension of pmlc
- but that seems clumsy
or
- directly
- by grabbing the PMCD-host url from pmlc (already published)
- then relaying pmns operations to it a la pmproxy
In the first case, a pmFetch could be implemented by the live-archive
server as a pmlc "log ... _metric-list" commands, then monitoring the
live-archive. This would cause some latency for first-time metrics
not already being collected fast enough, but it may well be tolerable.
In the second case, a pmfetch could be implemented by relaying the
operation to its direct pmcd connections, and optionally to pmlc for
archiving. (At that point, the live-archive server could just log the
values directly. At which point, maybe it's just a pmlogger+pmproxy
hybrid we're arriving at.)
> [...]
> [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".) OK, let's roll.
getargs():
Collapse the isarch==0 and ==1 case as much as possible,
including attempting calls such as pmGetArchiveLabel()/pmGetArchiveEnd()
on host-context. New libpcp would turn those into RPCs to the
live-archive-server (if so attached) to describe the time span of the
available archives. Suitable fallback for non-live-archive-server
connection. Do (undocumented!) pmTimeStateMode() for PM_CONTEXT_HOST too.
main():
getvals():
No obvious need of change.
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
% pmval -S '-1hour' -T '-1min' -t '60sec' -h SERVERHOST foo.metric
% pmval -g -h SERVERHOST foo.metric
The latter would require that the pmtime machinery let the user switch
between live mode (pause/run) and archive mode (back/pause/forward)
modes in the GUI, but pmval.c per se may not need any serious
modifications just for that.
Is the above the sort of thing you were looking for?
- FChE
|