Hi Martins,
----- Original Message -----
> Nathan,
>
> On 10/8/14 8:15 PM, Nathan Scott wrote:
> > Spot on, yes; keeping the existing PMIDs for those proc metrics that
> > become dynamic and making the hotproc variants just the same (but with
> > non-conflicting cluster IDs of course).
> >
> >> It seems like the first step would be to convert the existing pmda to
> >> handle dynamic metrics for the appropriate clusters that already exist
> >> before we worry about hotproc?
> > Yep. I believe that will work nicely - of course there may be issues
> > I've not anticipated (lemme know early on, if so), but I'm pretty sure
> > that will work out well.
> >
> I've made some progress on this but wanted to clarify a couple things.
> This seems a little more involved than I initially thought, unless I'm
> missing some points. I think we want the metrics to be named as I had
> in my current implementation:
>
> hotproc.psinfo.pid
> and
> proc.psinfo.pid
>
> ...etc....
>
> but we are still going to have proc metrics that don't map to hotproc
> variants like:
>
> proc.runq.*
> proc.control.*
Yep.
> And certainly there are hotproc metrics that have no corresponding proc
> metrics, and the control metrics are different between the two.
Right.
> But in general, how would root_proc look for a mix of dynamic and static
> metrics under a single tree? Like this where we would duplicate the
> dynamic elements for both subtrees?
>
> ****************
> [...]
> ****************
>
Yes, that's how I'd imagined the namespace file would look.
>
> If this is the case, how do the calls to "pmdaDynamicPMNS" work? We
> would need at least 2, correct:?
Correct, with the way the pmdaDynamicPMNS call works, I think it'd
have to be one per cluster in this case.
> Or would we need one for each proc.foo entity since we are mixing
> dynamic and static items in a tree?
Yes, one per [hot]proc.foo entity will be needed I think.
> pmdaDynamicPMNS("proc",.....
> pmdaDynamicPMNS("hotproc",.....
(so one call per top level subtree)
pmdaDynamicPMNS("proc.psinfo",.....
pmdaDynamicPMNS("proc.memory",.....
etc.
The functions in the "....." above would very likely be shared, and
the namespace "refresh" concept is far, far simpler than the cgroups
case (which is a *very* dynamic namespace, potentially changing even
between fetches) - our case for proc/hotproc is simpler - an example
closer to this case here would be src/pmdas/linux/interrupts.c.
> My confusion mostly stems from the fact that I haven't yet figured out
> if there is a "right way" to do this mixing. i.e. do I just skip over
> any static metrics in the "refresh_*" calls?
>
> Or should everything under proc be dynamic? Thus, I would just do:
> ***********************
> root {
> cgroup
> proc PROC:*:*
> hotproc PROC:*:*
> }
> ***********************
As per discussion earlier - nope, not this latter approach, cos...
>
> But then, again, I need some way of handling static metrics that don't
> overlap.
*nod* - the above isn't what I was imagining - there's lots of static
proc metrics we just want to leave as is, our aim here is to share the
metrics which are being duplicated for hotproc (and not only sharing
the names, but also the descriptors and help text).
>
> The second observation is that namespace grouping are not 1:1 wrt
> cluster groupings. For example, proc.psinfo contains metrics from 4
> different clusters. From my reading of existing code, I don't think
> this will be a problem, but just wanted to check.
Agreed - I don't think this will be a problem. I suspect you'll need a
series of calls to pmdaDynamicPMNS(), for each [hot]proc.foo subtree and
each with just a single cluster in the "set" (2nd parameter).
> Finally, I looked through various pmdas and some (mmv and sample) handle
> dynamic metrics in a more direct way, without the infrastructure
> provided by pmdaDynamicPMNS adding to my confusion on the right way to
> do this.
>
> Thanks for any prodding in the right direction.
The interrupts example above might give further ideas around tackling it
using pmdaDynamicPMNS. But, if you're finding that to get in the way by
all means go for an MMV-style or pmdasample-style approach without using
that interface.
cheers.
--
Nathan
|