Hi Marko,
----- Original Message -----
> > [...]
> > What kind of "highly problematic" scenarios there has been in the past?
>
> So, one example is pmie - there is no equivalent of some_inst, etc for
> metric names, so rules end up having to be expanded for every metric.
> pmchart configs have similar issues, regex matching on instance names
> is available but metric names are expected to be more static (and need
> individual expansion in the configuration files).
>
> Another class of problems is around naming - metric names are defined
> to be less flexible than instance names (as per that pmns(5) extract,
> from earlier).
I forgot another biggie yesterday - related to the persistence of PMIDs.
Its important to a number of the client tools (pmlogger, pmie, pmchart,
hmmm pretty much all actually) that if pmcd is restarted, metrics return
with the same PMID as before (this is pretty much part of the protocol
over-the-wire, and its also necessary on-disk between archives of the
same host).
This becomes very difficult to ensure in the case of dynamic metrics -
it was the main reason we switch cgroups to using this model IIRC. And
the pmdaCache interfaces support persisting instance identifiers well of
course.
Also, along the vein of PMIDs, and especially depending on how the PMID
"cluster" identifier is used, the size limits of 10 bits (1024 metrics)
and/or 22 bits (if full cluster space available also) are less appealing
than the convenience of the full 32 bit instance identifier space.
cheers.
--
Nathan
|