----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 2010-04-14 at 08:02 +1000, Nathan Scott wrote:
>
> No real issue with this, but a few comments.
>
> 1. By "drop a file" I presume you're thinking one file per pmda that
> wants to play, and then "somewhere" in libpcp I process all of the
> files
Right, that was what I was thinking.
> in the magic directory. This means update is file replacement,
> rather
> than the edit and update a common file model that is much more error
> prone.
Right. Someday, pmcd could perhaps take a leaf out of this book,
but way beyond scope here.
> 4. Should we retire the $PMDA_LOCAL_PROC and $PMDA_LOCAL_SAMPLE
> controls
> that influence when the proc and sample metrics might be available
> for
> PM_CONTEXT_LOCAL? I think they are passed their use-by date, so
> would
> not worry if they were quietly forgotten about.
>
I'd be happy with that too, yep.
> 5. A lot cleaner than all of this would be an extended pmcd.conf
> format
> that included a "pick me for PM_CONTEXT_LOCAL" flag ... there is
> space
> to do that at the end of the dso line (no arguments for dsos). This
> would be
> - system wide
> - at the discretion of the pmda install script
> - atomic with pmda install/remove
> - no environment variables
Mmm, yes, nice idea - do we even need to extend the format? Just say
any dso pmda listed in pmcd.conf is auto-loaded for local context?
With the clear/add/del a programmer can still fine tune their needs,
if they really just want particular PMDAs for a specialised tool.
This all means you have to parse pmcd.conf in libpcp, which is a bit
more involved perhaps than walking a directory and using the existing
(-K) parser code ... but, you choose, I'd be happy with either way.
cheers.
--
Nathan
|