[openstack-dev] [ceilometer] Compute agent local VM inspector - potential enhancement

Eoghan Glynn eglynn at redhat.com
Fri Aug 1 06:46:03 UTC 2014



> Disclaimer: I'm not fully vested on ceilometer internals, so bear with me.
> 
> For consumers wanting to leverage ceilometer as a telemetry service atop
> non-OpenStack Clouds or infrastructure they don't own, some edge cases
> crop up. Most notably the consumer may not have access to the hypervisor
> host and therefore cannot leverage the ceilometer compute agent on a per
> host basis.

Yes, currently such access to the hypervisor host is required, least in
the case of the libvirt-based inspector.
 
> In such scenarios it's my understanding the main option is to employ the
> central agent to poll measurements from the monitored resources (VMs,
> etc.). 

Well, the ceilometer central agent is not generally concerned with
with polling related *directly* to VMs - rather it handles acquiring
data from RESTful API (glance, neutron etc.) that are not otherwise
available in the form of notifications, and also from host-level
interfaces such as SNMP.

> However this approach requires Cloud APIs (or other mechanisms)
> which allow the polling impl to obtain the desired measurements (VM
> memory, CPU, net stats, etc.) and moreover the polling approach has it's
> own set of pros / cons from a arch / topology perspective.

Indeed.

> The other potential option is to setup the ceilometer compute agent
> within the VM and have each VM publish measurements to the collector --
> a local VM agent / inspector if you will. With respect to this local VM
> agent approach:
> (a) I haven't seen this documented to date; is there any desire / reqs
> to support this topology?
> (b) If yes to #a, I whipped up a crude PoC here:
> http://tinyurl.com/pqjgotv  Are folks willing to consider a BP for this
> approach?

So in a sense this is similar to the Heat cfn-push-stats utility[1]
and seems to suffer from the same fundamental problem, i.e. the need
for injection of credentials (user/passwds, keys, whatever) into the
VM in order to allow the metric datapoints be pushed up to the
infrastructure layer (e.g. onto the AMQP bus, or to a REST API endpoint).

How would you propose to solve that credentialing issue?

Cheers,
Eoghan

[1] https://github.com/openstack/heat-cfntools/blob/master/bin/cfn-push-stats



More information about the OpenStack-dev mailing list