Open Stack

Heat cfntools is based on SSH, so I assume it requires TCP/IP connectivity
between VM and the central agent(or collector). But in the cloud, some
networks are isolated from infrastructure layer network, because of security
reasons. Some of our customers even explicitly require such security
protection. Does it mean those isolated VMs cannot be monitored by this
proposed-VM-agent?

I really wish we can figur out how it could work for all VMs but with no
security issues.

I'm not familiar with heat-cfntools, so, correct me if I am wrong :)


Best regards!
Kurt

-----邮件原件-----
发件人: Eoghan Glynn [mailto:eglynn at redhat.com] 
发送时间: 2014年8月1日 14:46
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector -
potential enhancement



> 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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev