[openstack-dev] [ceilometer] Monitoring Physical Devices

Zehnder Toni (zehndton) zehndton at students.zhaw.ch
Tue Dec 4 07:11:18 UTC 2012


Yes, I'm working on it. At the moment I elaborate the concept. An update of the wikipage will come soon.

Toni

> -----Original Message-----
> From: Lu, Lianhao [mailto:lianhao.lu at intel.com]
> Sent: Tuesday, December 04, 2012 3:46 AM
> To: OpenStack Development Mailing List; Zehnder Toni (zehndton)
 > On 11/20/12 3:50 AM, " Lu, Lianhao " < lianhao.lu at intel.com > wrote:> 

> Hi guys,
> 
> Is there anyone working on this yet? If not, I'd like to help.
> 
> -Lianhao
> 
> 
> JC Martin wrote on 2012-11-21:
> > I believe that it's critical for openstack to manage physical
> > hardware, even more so than VM. The VM management is the
> > responsibility of the tenant, and can be achieved from the VM, through
> some external services.
> > Openstack can provide VM performance management but I believe that
> > it's not core. On the other end, it should be the primary
> > responsibility of openstack to make sure that its infrastructure is healthy.
> This includes :
> >    - Monitoring Hypervisor helath, capacity, performance
> >    - Predicting and repairing Hardware failures (e.g. Disk SMART)
> >    - Recovering VMs from failed hardware This, in the order on
> > importance. This would also include the monitoring and management of
> > the associated components (nova scheduler, APIs, ...)
> >
> > Thanks,
> >
> > JC
> >
> >
> > On 11/20/12 3:50 AM, "Jiang, Yunhong" <yunhong.jiang at intel.com> wrote:
> >
> >> Firstly, openstack is mostly a system manage the VM instance (create,
> >> schedule, desotry etc), instead of the host system, thus host
> >> management itself does not belongs to openstack scope IMHO.
> >>
> >> Secondly, usually there are already some monitor/management system in
> >> data center that manages the host, checking IPMI event etc, and those
> >> system is not part of openstack.
> >>
> >> However, the host system state IS really important to openstack, for
> >> example, if some system is over-hot, it's important to notify nova
> >> scheduler to stop load instance to that system etc.
> >>
> >> So I think the best solution is, host management system will input
> >> data to ceilometer, and some system (either part of ceilometer, or
> >> 3rd party
> >> software) will monitor these data, will provide policy/action to
> >> handle host situation. As these monitor system exist already, I think
> >> a REST API will be much easier to wrap them, rather than ceilometer
> >> message bus. And I don't think we need re-invent the wheel in
> >> openstack to manage the host system, which is not openstack's scope.
> >>
> >> Any idea?
> >>
> >> Thanks
> >> --jyh
> >>
> >> Zehnder Toni (zehndton) wrote on 2012-11-20:
> >>> Hi,
> >>>
> >>> I can't see why an internal resource should send data via REST API post.
> >>> Could you explain why a REST API post is required?
> >>> I think the new agent shouldn't send data in a different way than
> >>> the existing agents.
> >>>
> >>> Toni
> >>>
> >>> Jiang, Yunhong wrote on 2012-11-15:
> >>>> As I'm beginning work on
> >>>> https://blueprints.launchpad.net/ceilometer/+spec/meter-post-api,
> >>>> so my question to the architect is, would it be possible for the
> >>>> hardware monitor to send information through REST API, instead of
> >>>> the event bus? That will make the hardware agent simpler IMHO.
> >>>>
> >>>> Thanks
> >>>> --jyh
> >>>>
> >>>> Zehnder Toni (zehndton) wrote on 2012-11-15:
> >>>>> Hi there,
> >>>>>
> >>>>>
> >>>>>
> >>>>> As we discussed last week there is a need for hardware monitoring
> >>>>> in the OpenStack environment. I worked out a blueprint (see
> >>>>>
> >>>>> https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physi
> >>>>> cal
> >>>>> - device s
> >>>>>
> >>>>> <https://blueprints.launchpad.net/ceilometer/+spec/monitoring-
> phys
> >>>>> ica l -devic es> ) for this case. There is also a diagram of the
> >>>>> architecture on es> the wiki (see
> >>>>> http://wiki.openstack.org/Ceilometer/MonitoringPhysicalDevices) so
> >>>>> we can discuss about it more specifically.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Toni



More information about the OpenStack-dev mailing list