[openstack-dev] 回复： [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

Luo Gangyi lgy181 at foxmail.com
Fri Sep 11 16:30:43 UTC 2015 

Thanks Julien :)
  
 >  But I don't think Ceilometer has this metric posted to Gnocchi yet, the
>  code is a bit young and not finished on the Ceilometer side. If you
>  check gnocchi_resources.yaml, it's still marked "ignored" for now.
  
 I checked it again, no "ignored" is marked, seems the bug of devstack ;(
  
 And it's OK that gnocchi is not perfect now, but I still have some worries about how gnocchi deal with or going to deal with instance-xxxx-tapxxx condition.
 I see 'network.incoming.bytes' belongs to resouce type 'instance'. But no attributes of instance can save the infomation of tap name. Although I can search
 all metric ids from resouce id(instance uuid), how do I distinguish them from different taps of an instance?
  ------------------
 Luo Gangyi   luogangyi at cmss.chinamobile.com



  
  

 

 ------------------ 原始邮件 ------------------
  发件人: "Julien Danjou";<julien at danjou.info>;
 发送时间: 2015年9月12日(星期六) 凌晨0:01
 收件人: "Luo Gangyi"<lgy181 at foxmail.com>; 
 抄送: "OpenStack Development Mailing L"<openstack-dev at lists.openstack.org>; 
 主题: Re: [openstack-dev] [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

 

On Fri, Sep 11 2015, Luo Gangyi wrote:

Hi Gangyi,

>  I am using master branch and newest code for testing.

Cool.

>  For the purpose for learning the structure of gnocchi, I changed the
>  default UUID type of mysql from binary to char, so I can easily link
>  the resource-id(I mean in database), metric id and directory name of
>  storing measures.

Bah, don't do that – and rather use PostgreSQL, it's the recommended
backend. :)

>  When I did that, I found all the metrics where their resource id is
>  combined(here, I mean in Ceilometer, such as instance-xxx-tapxxxx)
>  have no measures stored.


>  Log in Ceilometer collector records this:
>  "
>  2015-09-11 07:55:55.097 10636 ERROR ceilometer.dispatcher.gnocchi [-] Resource instance-00000001-4641f59e-994c-4255-b0ec-43a276d1c19c-tap8aadb7ad-d7 creation failed with status: 400: <html>
>  <head>
>   <title>400 Bad Request</title>
>  </head>
>  <body>
>   <h1>400 Bad Request</h1>
>   The server could not comply with the request since it is either malformed or otherwise incorrect.<br /><br />
> Invalid input: required key not provided @ data['display_name']
>   </body>
> </html>
>
>  "
>  So I wander whether gnocchi cannot deal with such combined resource-id metrics or whether it is because I change the UUID type or whatever.

Yes, it can, but the problem is more likely in the Ceilometer collector
dispatcher code that is sending the data. From the error you have, it
seems it tries to create an instance but it has no value for
display_name, so it is denied by Gnocchi. If this is from a standard
devstack installation, I'd suggest to open a bug on Ceilometer.

>  And another question is how to query measures for those metrics whose
>  resource id is combined.

They are resource on their own so if you know their id you can just
access the metrics at /v1/resources/<type>/<id>/metric/<name>/measures.

>  For example, I want to query the network traffic of an vm, I know the
>  instance uuid 1111-2222, I know metric name
>  'network.incoming.byte.rate' but I do not know the exact resouce_id
>  and metric id. What procedure should I do ?

You need to know the ID of the resource and then ask for its metric on
the REST interface. If you don't know the ID of the resource, you can
search for it by instance id.

But I don't think Ceilometer has this metric posted to Gnocchi yet, the
code is a bit young and not finished on the Ceilometer side. If you
check gnocchi_resources.yaml, it's still marked "ignored" for now.

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150912/b78b4f1c/attachment.html>

More information about the OpenStack-dev mailing list