[Libvir] Re: [collectd] collectd libvirtstats plugin

[Florian Forster]

Hi Rich,

as promised, I've taken a more in-depth look at the `libvirtstats'
plugin (I've adopted this as a working title for now and will do the
renaming on the weekend or so..) and it looks very good, thanks again :)

The `_virDomainInfo' structure has the members `memory' and `maxMem'.
Can one calculate `unused' or `free' (or whatever the preferred term in
this particular case is) memory using `maxMem - memory'? Would that be
an interesting metric?

I'm not sure what the best way to store the CPU usage is. Is the
`cpuTime' member of the `_virDomainInfo' structure the same as the sum
over all `(struct _virVcpuInfo).cpuTime'? Does collecting the total make
sense in this case? I'd much rather use the same `type' for ``normal''
CPU statistics and this case which would be much simpler if we didn't
collect the total..

I've done some minor things while looking through the code. It basically
a mix of coding style and personal convention. Since there's no Debian
package yet I didn't install try to compile it yet. I'll install the
library and fix the errors I've made as soon as I have some more spare
time. The things I've changed are basically:
- Rather use `sizeof (array);' than the `DATA_MAX_NAME_LEN' define.
- NULL-terminate the strings unconditionally after `strncpy' or
  `snprintf' was used.
- Rather use
  -- 8< --
   if (status != 0) { handle_error (); }
  -- >8 --
  than
  -- 8< --
   if (status == -1) { handle_error (); }
  -- >8 --

On Mon, Nov 05, 2007 at 02:00:12PM +0000, Richard W.M. Jones wrote:
> In the types.db, I have set the max for virt_cpu_total to be
> 256,000,000,000. [...] Therefore I have assumed here that
> max CPUs = 256.

That's basically the reason why I'd rather collect each virtual CPU in a
separate file and ``simply'' combine the graphs. This will work for n+1
CPUs ;)

> I'm using CSV output, which works, but it seems to report the
> aggregate counter values instead of the differences.  Is that to be
> expected?

Yes, that is expected. The changes I've made for the next feature
release (4.3) include an easy way to get the rates for a counter value.
So I will certainly add an option to store rates instead.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071107/749106b4/attachment-0001.sig>