Hi Marko,
----- Original Message -----
> [...]
> > - libvirt API provides VM metrics for individual vCPUs/NICs/block
> > devices but since instance IDs are the domain UUIDs in the PMDA, it's
> > unclear what would be the optimal approach to provide those (dynamic)
> > device metrics as PCP metrics. Thus the PMDA combines these together.
>
> I investigated the Python PMDA API a bit and this turned out to be
> pretty straightforward. The patch below implements per-device metrics
> for vCPU/block/net. It's easy to see that these could be very
> interesting, e.g., in case of a database VM or a file server VM. There's
> quite some amount of new code but most of it is executed only when
> adding new metrics (for example, if libvirt.domstats.net.1.rd.times
> does not exists and a VM with two NICs (0, 1) is present, then that
> metric is being added, libvirt.domstats.net.0.rd.times and others are
> left untouched. And when the VM with two NICs goes away, there will
> be just the typical "not available" return code sent to the clients.
"libvirt.domstats.net.0.rd.times" - this looks like it's representing
individual network devices using the metric namespace, is that right?
That has proved highly problematic in the past - in general, much more
flexibility (not to mention correctness often, too) is to found in the
approach of using a new indom with a compound instance name, e.g.
libvirt.domstats.net.rd.times[vmXXX/ifNNN]
This tends to make things easier on the client side too, from a users
point of view - e.g. writing pmie rules, pmchart configs, etc.
Finally (a minor one for reference), the namespace component "0" there
isn't quite meeting the namespace syntax rules from pmns(5)...
"Each component in the pathname must begin with an alphabetic
character, and be followed by zero or more characters drawn
from the alphabetics, the digits and the underscore ``_'' ..."
cheers.
--
Nathan
|