regarding ceilometer+oslo.messaging backend[1]. i feel like i should
mention, i'm not sure how you guys are using the query but i should
mention that is not the correct way to use Ceilometer meters as it
currently isn't measuring anything (see hardcoded - volume:1)
again, i'm not sure what query you are utilising, but i would suggest
you probably change this to use Events (possibly with elasticsearch)
rather than Meters because it currently doesn't seem to make much sense.
[1]
https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml#L792
On 09/11/2015 5:57 AM, Boris Pavlovic wrote:
Hi stackers,
Intro
-------
It's not a big secret that OpenStack is huge and complicated ecosystem
of different
services that are working together to implement OpenStack API.
For example booting VM is going through many projects and services:
nova-api, nova-scheduler, nova-compute, glance-api, glance-registry,
keystone, cinder-api, neutron-api... and many others.
The question is how to understand what part of the request takes the
most of the time and should be improved. It's especially interested to
get such data under the load.
To make it simple, I wrote OSProfiler which is tiny library that
should be added to all OpenStack
projects to create cross project/service tracer/profiler.
Demo (trace of CLI command: nova boot) can be found here:
http://boris-42.github.io/ngk.html
This library is very simple. For those who wants to know how it works
and how it's integrated with OpenStack take a look here:
https://github.com/openstack/osprofiler/blob/master/README.rst
What is the current status?
-----------------------------------
Good news:
- OSprofiler is mostly done
- OSprofiler is integrated with Cinder, Glance, Trove & Ceilometer
Bad news:
- OSprofiler is not integrated in a lot of important projects:
Keystone, Nova, Neutron
- OSprofiler can use only Ceilometer + oslo.messaging as a backend
- OSprofiler stores part of arguments in api-paste.ini part in
project.conf which is terrible thing
- There is no DSVM job that check that changes in OSprofiler don't
break the projects that are using it
- It's hard to enable OSprofiler in DevStack
Good news:
I spend some time and made 4 specs that should address most of issues:
https://github.com/openstack/osprofiler/tree/master/doc/specs
Let's make it happen in Mitaka!
Thoughts?
By the way somebody would like to join this effort?)
Best regards,
Boris Pavlovic
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
gord
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
