[openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

AFEK, Ifat (Ifat) ifat.afek at alcatel-lucent.com
Mon Nov 23 16:14:59 UTC 2015


Hi Gord,

Please see my answers below.

Ifat.


> -----Original Message-----
> From: gord chung [mailto:gord at live.ca]
> Sent: Monday, November 23, 2015 4:57 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom
> alarms in AODH
> 
> hi Ifat,
> 
> i added some questions below.
> 
> On 23/11/2015 7:16 AM, AFEK, Ifat (Ifat) wrote:
> > Hi,
> >
> > We have a couple of questions regarding AODH alarms.
> >
> > In Vitrage[1] project we have two use cases that involve Ceilometer:
> >
> > 1. Import Ceilometer alarms, as well as alarms and resources from
> other sources (Nagios, Zabbix, Nova, Heat, etc.), and produce RCA
> insights about the connection between different alarms.
> to clarify, Ceilometer alarms is deprecated for Aodh and will be
> removed very, very soon.

Right, I meant Aodh alarms.

> 
> > 2. Raise "deduced alarms". For example, in case we detect a high
> memory consumption on a host, we would like to raise deduced alarms
> saying "instance might be suffering due to high memory consumption on
> the host" on all related instances. Then, we can further deduce that
> applications running on these instances might also be affected, and
> raise alarms on them as well.
> >
> > Initially we planned to raise these deduced alarms in AODH, so other
> Openstack components may consume them as well. Then, when we looked at
> AODH alarms documentation, we noticed that there is currently no way of
> raising custom alarms. We saw only three types of alarms: threshold
> alarms, combination alarms and event alarms.
> >
> > So, our questions are:
> >
> > * Is there an alternative way of raising alarms in AODH?
> what do we mean by raising alarms? do you want to create a new alarm
> definition for Aodh or do you want to trigger an action? do you want to
> have a new non-REST action?

I guess I would like to do both: create a new alarm definition, then 
trigger it (call alarm_actions), and possibly later on set its state 
back to OK (call ok_action).
I understood that currently all alarm triggering is internal in AODH, 
according to threshold/events/combination alarm rules. Would it be 
possible to add a new kind of rule, that will allow triggering the 
alarm externally? 

> 
> > * Do you think custom alarms belong in AODH? Are you interested in
> adding this capability to AODH?
> >
> > We would be happy to hear your vision and thoughts about it.
> >
> >
> > Thanks,
> > Ifat and Alexey.
> >
> >
> > [1] https://wiki.openstack.org/wiki/Vitrage
> >
> >
> >
> >
> >
> ______________________________________________________________________
> > ____ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> gord
> 
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list