pcp
[Top] [All Lists]

Re: [pcp] PCP libvirt PMDA

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] PCP libvirt PMDA
From: Marko Myllynen <myllynen@xxxxxxxxxx>
Date: Tue, 19 Jul 2016 11:38:42 +0300
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <37250089.6949181.1468900166388.JavaMail.zimbra@xxxxxxxxxx>
Organization: Red Hat
References: <1fa58d82-ac73-7747-c58d-acf880bc2155@xxxxxxxxxx> <20ae899d-50c6-1457-644f-f45ad26c63d4@xxxxxxxxxx> <37250089.6949181.1468900166388.JavaMail.zimbra@xxxxxxxxxx>
Reply-to: Marko Myllynen <myllynen@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2
Hi,

On 2016-07-19 06:49, Nathan Scott wrote:
> ----- 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?

Correct.

> 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.

What kind of "highly problematic" scenarios there has been in the past?
It seems that your proposal would glue two IDs together which could be
kept separated and I don't see how to my proposal would make things more
difficult. For example, in a situation where all VMs are connected to
one network with NIC0 and one or two VMs might have few extra NICs, it
would easy to monitor either the common network traffic
(libvirt.domstats.net.0) or the other NICs (libvirt.domstats.net.{1,2}).

I'm also wondering which one would be more easier approach e.g. with
pmwebd/grafana or Zabbix?

Thanks,

-- 
Marko Myllynen

<Prev in Thread] Current Thread [Next in Thread>