Open Stack

Ok, so far i have been able to generate the following output:

+-------------------+-------------+
|      Property     |    Value    |
+-------------------+-------------+
| cpu0              | 0.0         |
| cpu1              | 0.0         |
| memory            | Unavailable |
| vda_bytes_read    | 1010688     |
| vda_bytes_written | 5729280     |
| vnet1_bytes_read  | 682         |
| vnet1_bytes_sent  | 0           |
+-------------------+-------------+

I'm not sure about the cpu values, since i need to sample these during 1
second in order to obtain a valid value. I've followed the same logic as
the one virt-top uses(http://people.redhat.com/~rjones/virt-top/faq.html).
The memory keeps returning an empty value, i suppose it has something to do
with libvirt.  Apparently, the result is just a dictionary/associative
array where you can add the keys and values you seem fit. What i didn't
find was any convention for the names of each property.

On Thu, Mar 29, 2012 at 12:00 AM, Paul Voccio <paul.voccio at rackspace.com>wrote:

>  Leander,
>
>  I'm able to gather this info with the nova diagnostics <uuid>
>
>  nova  diagnostics ff275ab0-d4c7-407d-b041-e9c7fa8c429e
>  +----------------+-----------------+
> |    Property    |      Value      |
> +----------------+-----------------+
> | cpu0           | 0.0048          |
> | cpu1           | 0.0013          |
> | cpu2           | 0.0010          |
> | cpu3           | 0.0008          |
> | memory         | 1269986368.0000 |
> | memory_target  | 1269986368.0000 |
> | vbd_xvdc_read  | 0.0             |
> | vbd_xvdc_write | 0.0             |
> | vif_0_tx       | 0.0             |
> +----------------+-----------------+
>
>
>  Thanks,
> ~pvo
>
> Paul Voccio
> paul.voccio at rackspace.com
> 770-335-2143 (c)
> pvo on #freenode
>
>  On Mar 27, 2012, at 10:29 AM, Leander Bessa wrote:
>
> I was hopping to find out more as well, since the only information i
> currently have comes from "nova help diagnostics". It would
> be interesting to work since this appears to be hypervisor agnostic and
> would allow for the development of a monitoring tool which fetches its
> information solely from the openstack api.
>
> On Tue, Mar 27, 2012 at 8:42 AM, Diego Parrilla Santamaría <
> diego.parrilla.santamaria at gmail.com> wrote:
>
>> I'm not familiar with nova-diagnostics, but we use collectd to gather
>> information about each virtual machine running in KVM. We get information
>> about cpu usage, memory, disk io, and network io per instance. Obviously
>> it's not nicely integrated with nova commands, but it works in our
>> deployments. And it comes in the distro by default.
>>
>>  Let me know if I can help you in this blueprint: the only reason now in
>> our distro to use collectd is kvm instances performance. If we can get from
>> nova we should go that way in the future.
>>
>>  Cheers
>> Diego
>>  --
>>  Diego Parrilla
>>  <http://www.stackops.com/>*CEO*
>> *www.stackops.com | * diego.parrilla at stackops.com** | +34 649 94 43 29<%2B34%20649%2094%2043%2029>|
>> skype:diegoparrilla*
>> * <http://www.stackops.com/>
>>  *
>>
>> *
>>
>>
>>
>>  On Mon, Mar 26, 2012 at 6:06 PM, Leander Bessa <leanderbb at gmail.com>wrote:
>>
>>>  Hello,
>>>
>>>  I've been trying to implement the nova-diagnostics command  for
>>> libvirt. I'm using the devstack installation on ubuntu 12.04. So far i've
>>> managed to gather information regarding CPU, IO (network and disks). The
>>> memory reading only works with the virsh command and does not report the
>>> actual memory usage.  As pointed out to me previously, i've been looking at
>>> the implementation of nova-diagnostics for the xenapi in order to try and
>>> figure out how to supply the data back to openstack. However, i can not
>>> make any sense of it. All i know is that it returns a set of keys with
>>> values, which i suppose represent the values of the readings. What i wish
>>> to know is if there's any document or specification which i can read which
>>> defines what nova-diagnostics should return and under what format.
>>>
>>>
>>>  Regards,
>>>
>>> Leander
>>>
>>>  _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120329/4084af74/attachment.html>