Open Stack

Hi Ifat,


Thank you for starting discussion how AODH can be integrated with Vitrage that would be a good example of AODH integration with other OpenStack components.

The key role of creating alarm definition is to set endpoint (alarm_actins) which can be receive alarm notification from AODH. How the endpoints can be set in your use case? Those endpoints are configured via virtage API and stored in its DB?

I agree with Gordon, you can use even-alarm with generating "event" containing alarming message that can be captured in aodh if vitrage relay the alarm definition to aodh. That is more feasible way rather than creating alarm definition right before triggering alarm notification. The reason is that aodh evaluator may not be aware of new alarm definitions and won't send notification until its alarm definition cache is refreshed in less than 60 sec (default value).

Having special rule and external evaluator would be alternative, but it should be difficult to catch up latest aodh, since it will be changed faster with small code base as result of split from ceilometer.


BR,
Ryota

> -----Original Message-----
> From: AFEK, Ifat (Ifat) [mailto:ifat.afek at alcatel-lucent.com]
> Sent: Tuesday, November 24, 2015 1:15 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH
> 
> 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
> 
> __________________________________________________________________________
> 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