----- Original Message -----
> > -----Original Message-----
> > [...]
> > It now appears to me (and once again, please correct me if I am wrong!)
> that
> > the goal is for clients to be able to examine metrics from multiple
> archives,
> > each of which may have multiple volumes (already supported) and each of
> > which may be arbitrarily distinct (i.e. not necessarily created by the
> same
> > pmlogger or even on the same machine).
>
> Yep, but all the archives have contain data collected from the same host ...
> different hosts require different contexts and different archives (or
> different sets of archives)
*nod*
> > Until we all agree on what the ultimate goal is here (and perhaps I'm the
> only
> > one who is still not sure), it would seem unlikely that we can agree on an
I think there's still lots of uncertainty in this area, you're definitely
not the only one who is unsure Dave.
> I still see these as disjoint and independent pieces of work. There is a
> use case for both at the same time, but I think this is likely to be a less
> common use case. The more common use cases are
> - historical analysis over a set of archives that are _not_ being actively
> written
> - live analysis where you want some (small) history from one archive that is
> being written to provide context for on-going live reporting
*nod* - those are consistent with the requirements I've seen in production
use. But, I think Frank has a good point re auto-logging ... it'd be nice
to be able to allow clients to optionally/transparently do this (and doing
a better job than pmchart of today). The cost of a turn-pmlogger-into-pmcd
approach is too high IMO (refactoring large amounts of pmcd and pmlogger,
new protocols, high complexity factor, inefficient-by-design, enforced-use,
and so on) - however, I'm sure we can devise more effective ways of reaching
that goal.
This too I see as an orthogonal, follow-up kind of project - something that
is above and beyond even the original unified context concept. Perhaps its
more like the caching context concept - an optionally-recorded live context.
> Even in the less common case of combining the two, they are still disjoint
> ... the transition from archive to live involves only ONE archive.
(could be more than one I think - it'd be good to be able to merge system-
logged data ala pmlogger_daily(1), and personal-logged data ala pmchart(1)
into one stream; both of those sources would be independently growing).
> So we could proceed with the archive set work which is better understood and
> not subject to architectural discussion, and independently focus on the
> architectural design for the transition piece which is where there is less
> agreement at the moment.
*nod* ... there are of course many unknown aspects to multi-archive support,
at this early stage (all the below-the-surface technical aspects). Moving
the focus there would be good - but I also agree with Dave's earlier comment
that its worth thinking about future paths, to not inadvertently make life
more difficult for the next stages (e.g. maybe stacking the archive contexts
will help us later too, rather than simply expanding __pmLogCtl/__pmArchCtl
at this early stage).
cheers.
--
Nathan
|