----- "Max Matveev" <makc@xxxxxxxxx> wrote:
> >>>>> "nscott" == Nathan Scott <nscott@xxxxxxxxxx> writes:
>
> nscott> - how does one create an instantaneous value? (like, number
> nscott> of users, length of a queue, etc).
> You can use DISCRETE and never change the extra value from 0.
Hmmm. That would only allow signed 64 bit values though.
> nscott> - what is the MMV_ENTRY_DISCRETE type? (seems to become a
> nscott> PM_SEM_DISCRETE metric that changes and has some state
> nscott> associated with it?)
> It's sort of a rate - I think I've used it for time sampling or some
> sort of rate: it's basically a difference between two samples - old
> and new.
Yeah, AFAICT, time sampling is your INTEGRAL type, which handles the
gettimeofday calls for you.
So ... bit of a problem here, doesn't seem to be any way to extend
the API to handle PM_SEM_INSTANT correctly. Any suggestions? Do
we need a new "sem" field in the mmv_stats_metric_t structure? (as
in struct pmDesc). I suspect so... which means an API/ABI change.
> nscott> - did you consider string values? (no support currently,
> afaict,
> nscott> but did you have a design in mind for implementing that?)
> Did not even think about them - did not need them.
>
> The way it was written the content of the file is fixed after it has
> been opened, it's not going to change. If I was adding support for
> strings, I'd probably create yet another section in the file to store
> the strings and do some sort of rudumentary allocator or just fix the
> maximum size for each string.
OK, thanks, will think about it some more. More questions that came up
today, maybe you have some thoughts here too:
- we put all metrics in the namespace at mmv.<identifier>.* ... there's
a request to make this <identifier>.* so that developers have the names
that they want for their metrics (obviously, top level name conflicts
could then happen ... not much can be done about that though).
- having to update $PCP_PMDAS_DIR/mmv/mmv.conf to add valid <identifier>
tokens is not very "user friendly" - developers would rather just be able
to run their app and have the names magically appear when instrumentation
is enabled. We might achieve this by scanning /var/tmp/mmv automatically
and/or through a more distribution friendly /etc/pmdammv.d/* (directory
of files, not just one conf file).
Perhaps we could consider the above two things together - eg. if there's a
mmv.conf entry with a cluster#, use that with mmv. prefixed names, else we
use auto-numbering clusters and no mmv. prefix for other MMV files found
in /var/tmp/mmv ...? That'd still give people who want fixed PMIDs with
known clusters everything they need, and also give the flexibility other
people want.
cheers.
--
Nathan
|