Hi -
>>>> ... needs to be deterministic, else bugs - see mail re dmcache/dmthin a
>>>> little earlier for more details. IOW, restarting/reconfiguring the PMDA
>>>> needs to ensure the same IDs are generated for the same metrics/indoms.
>>>
>>> I couldn't find the email you were referring to, but I see the problem
>>
>> Oh, sorry, that was an obscure reference - this is the one I meant:
>> http://www.pcp.io/pipermail/pcp/2015-March/006876.html
Can we back up a minute and assess why exactly this constraint is
being suggested?
I'm aware of no place in the documentation that claims that numeric
PMIDs can be assumed stable across pcp contexts - so every pcp client
I've seen does an explicit name-to-pmid resolution step. Is this
true?
What is the origin of the referenced email's concern about
pmlogrewrite? Each archive is self-describing, and in isolation has
no need to match name-to-pmid mappings to any other archive. When/if
archives are appended to each other, sure, pmlogextract(merge) may not
handle this case well today, but that's a problem only of that tool.
Other multi-archive tools work fine (pmwebd/graphite, and I hope
pmchart).
Even if it were desirable to work around pmlogextract shortcomings,
this need not mean that there has to be a sophisticated or long-term
uniqueness guarantee. It may well be sufficient to make it likely
that if pmcd is restarted, with no change to json metadata files, that
the same numbers be produced. That in turn could be handled
straightforwardly by deterministic traversal of the json metadata
files (such as by sorting by their pathnames).
- FChE
|