Hi -
> > > [...] Depending on the overhead of this instrumentation, you may
> > > wish to consider using an additional control variable and pmStore(1)
> > > to allow a user to enable or disable the collection [...]
> >
> > FWIW, I wish we leaned less on this particular technique.
>
> The missing piece is better (client) tool support - its needed for not
> just enabling expensive metrics, but also server-side filtering. [...]
Server-side filtering would still be a per-client proposition. I
wouldn't want my run pmlogger to become silent just because some other
guy is filtering his stream.
> > The pmda infrastructure has the ability to track individual pcp
> > clients coming and going. So, a pmda can/should activate
> > collection on demand,
> A client simply showing interest in the metrics from a PMDA is not enough
> information to know whether expensive collection should be enabled or not
> though.
Why not?
> A PMDA can export both expensive and inexpensive metrics too, or the
> enabled state may be system wide (like hardware counters, or gluster
> volume stats, or any of a number of other things that the underlying
> data domain creators have chosen not to enable by default).
Sure, these statistics may not be worth keeping if no one's listening.
But we're talking about the case where a PCP client has expressed
specific interest in them: it's the opposite case.
- FChE
|