pcp
[Top] [All Lists]

Re: MMV questions

To: Nathan Scott <nscott@xxxxxxxxxx>
Subject: Re: MMV questions
From: Max Matveev <makc@xxxxxxxxx>
Date: Mon, 15 Jun 2009 22:56:20 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <765922600.6343411245025249624.JavaMail.root@xxxxxxxxxxxxxxxxxx>
References: <380462529.6342771245024314554.JavaMail.root@xxxxxxxxxxxxxxxxxx> <765922600.6343411245025249624.JavaMail.root@xxxxxxxxxxxxxxxxxx>
>>>>> "nscott" == Nathan Scott writes:

 nscott> OK, thanks, will think about it some more.  More questions
 nscott> that came up today, maybe you have some thoughts here too:

 nscott> - we put all metrics in the namespace at mmv.<identifier>.*
 nscott>   ... there's a request to make this <identifier>.* so that
 nscott>   developers have the names that they want for their metrics
 nscott>   (obviously, top level name conflicts could then happen
 nscott>   ... not much can be done about that though).

 nscott> - having to update $PCP_PMDAS_DIR/mmv/mmv.conf to add valid
 nscott>   <identifier> tokens is not very "user friendly" -
 nscott>   developers would rather just be able to run their app and
 nscott>   have the names magically appear when instrumentation is
 nscott>   enabled.  We might achieve this by scanning /var/tmp/mmv
 nscott>   automatically and/or through a more distribution friendly
 nscott>   /etc/pmdammv.d/* (directory of files, not just one conf
 nscott>   file).
The reson for the config file was precisely because we've tried to
avoid metrics from automatically appearing - the original project was
prone to "sudden" files appearing in the unusual places.

Plus the obvious need to control PMID assignments.  

Plus it was the only place to check for updates - if the file is not
updated then no need to reload rescan the directory.

It's all rather lame anyway.

 nscott> Perhaps we could consider the above two things together -
 nscott> eg. if there's a mmv.conf entry with a cluster#, use that
 nscott> with mmv. prefixed names, else we use auto-numbering clusters
 nscott> and no mmv. prefix for other MMV files found in /var/tmp/mmv
 nscott> ...? 
I've tried using pmns to control pmid assigments - pmda loads its own
copy of pmns. It works but only for non-DSO pmdas for obvious reasons.
Having a config file as fallback should be fine too - just requires a
bit more work on the pmda side to check that the files it finds in its
directory should be loaded.

BTW, I wouldn't worry about API or on-disk format - I think the only
user of the original MMV is either dead or getting close to it.

max

<Prev in Thread] Current Thread [Next in Thread>