Hi Marko,
----- Original Message -----
> Hi,
>
> On 2016-07-20 23:43, Nathan Scott wrote:
> > ----- 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).
>
> If we think metrics with PM_INDOM_NULL as one-dimensional metrics,
> metrics with instance domains as two-dimensional metrics, and these
> metrics which have two dynamic dimensions as three-dimensional metrics,
> are there other such "3D" metrics in standard / often used PMDAs
> present already, how are they set up?
I sent through the cgroup example earlier - see the pmda.c and cgroup.c
code below src/pmdas/linux_proc - there's several different examples of
these compound domains in there.
> >> 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 don't see this any kind of issue here. The case that a component must
> begin with an alphabetic is documented in pmns(5) but for some reason
> it is not checked/forced and in fact everything seemed to work with
> components beginning with a digit.
That alpha/digit aspect is only a tiny part of the problem - instance names
can have all sorts of (common) characters that metric names cannot (hyphen,
plus, colon, braces, @$%^&*=;,./ ... etc). Particularly problematic in the
past has been the hyphen - subtraction in pmie's language, and it is often
used in device naming too.
> (Btw, how well pmns(5) is up-to-date, it lists several domain IDs for
> Oracle, Sybase, Informix, and e.g. OpenBSD and libvirt are in the
> "End-user and demo PMDA" range?
*nod* - that table is a bit out of date - the comment at the head of stdpmid
is the latest source of truth.
> Perhaps a component is allowed to begin with a digit these days?
Nothing has changed on that front though.
>
> This worked already earlier ok, PMIDs were never different for added
> metrics (IOW, the names and PMIDs for, e.g., VCPU4 related metrics were
> always the same). I've now double-checked it by starting/stopping VMs,
> libvirt PMDA, PMCD, and libvirtd in random order and as should, PMIDs
> and names never change.
>
It tends to be block devices and network interfaces that are problematic,
not CPUs FWIW - these are added and removed more commonly.
> > 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.
>
Yeah, I wouldn't just dismiss this aspect either - a max of 70-ish block
devices will surely be limiting to some people.
> Martins, you were already trying out this libvirt PMDA after its
> initial posting and you have lots of valuable experience and insight
> with PCP also in general, how do you see these two approaches, which
> one would be more suitable for you and your use cases?
FWIW, it was primarily from problems that Martins and Joe observed that
we ended up switching the cgroup metrics over to this compound instance
name approach.
> Below is a rebased patch (on top of the backing patch) and which has
> the one extra line needed to allow using e.g. ..net.net0.. instead of
> ..net.0.. etc.
(hmm, is it not possible to get the actual interface names from libvirt?
i.e. like eth0, lo0, etc?)
cheers.
--
Nathan
|