> -Original Message-
> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> Sent: Tuesday, December 08, 2015 11:17 AM
>
> Hi Ifat,
>
> In short, 'event' is generated in OpenStack, 'alarm' is defined by a
> user. 'event' is a container of data passed from other OpenStack
> services through
Hi Ryota,
> -Original Message-
> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> Sent: Tuesday, December 08, 2015 11:17 AM
>
> In short, 'event' is generated in OpenStack, 'alarm' is defined by a
> user. 'event' is a container of data passed from other OpenStack
> services through
Hi Ifat,
> > Can we clarify use case again in terms of service role definition?
>
> Our use cases focus on giving value to the cloud admin, who will be able to:
>
> - view the topology of his environment, the relations between the physical,
> virtual and applicative layer and the
> statuses
> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Monday, December 07, 2015 12:00 PM
>
> I find it odd to have UI use cases first, as their terribly large for a
> MVP. Unless Vitrage already exists and you have all the code figured
> out. :)
We have most of it
On Mon, Dec 07 2015, AFEK, Ifat (Ifat) wrote:
> Our goal is to get as much information as we can from various data
> sources. If you connect Nagios to telemetry project, and we can get
> nagios alarms directly from Aodh, it would be great. Is it something
> that you planned on doing for
Hi Julien,
> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Thursday, December 03, 2015 4:27 PM
>
> I think that I would be more interested by connecting Nagios to
> Ceilometer/Gnocchi/Aodh with maybe the long-term goal of replacing it
> by that stack, which
Hi Ryota,
> -Original Message-
> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> Sent: Friday, December 04, 2015 9:42 AM
>
> > The next step can happen if and when Aodh supports alarm templates.
> > If Vitrage can handle about 30 alarm types, and there are 100
> > instances, we don't
Hi Ifat,
> > > Let me see if I got this right: are you suggesting that we create
> > > on-the-fly alarm definitions with no alarm_actions, for every
> > > deduced
> > alarm that we want to raise? And this will spare us the extra alarm
> > evaluation in AODH?
> >
> > Yes. But, please note that
Hi Ifat,
> > One approach we can take, is that you configure aodh to pass each row
> > event (e.g. each VM downed) wrapped in alarm notification to vitrage,
> > then do some operation (e.g. deducing, aggregating) and store
> > resource- level alarm without any alarm_actions, so that users can
On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:
> Another question is our need to get alarms from other sources, like
> Nagios, zabbix, ganglia, etc. We thought that Vitrage would query these
> Alarms from each source directly, and then create alarms in AODH in the
> same way as our deduced
On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:
> One of Vitrage's goals is to gather information from different layers -
> Physical, virtual and applicative - create a topology tree with the
> Relations between the different entities in all layers, and perform
> alarm analysis based on this
Hi Julien,
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Thursday, December 03, 2015 10:53 AM
>
> On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote:
>
> > Another question is our need to get alarms from other sources, like
> > Nagios, zabbix, ganglia, etc. We thought that Vitrage would
Hi Ryota,
> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
> >
> > Let me see if I got this right: are you suggesting that we create
> > on-the-fly alarm definitions with no alarm_actions, for every deduced
> alarm that we want to raise? And this will spare us the extra alarm
> evaluation in
On Wed, Dec 02 2015, AFEK, Ifat (Ifat) wrote:
> As we understand it, if we take the first approach you describe, then we can
> have an alarm refer to all the VMs in the system, but then if the alarm is
> triggered by one VM or by five VMs, the result will be the same - only one
> alarm will be
Hi Julien,
Please see our questions below.
Ifat and Elisha.
> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
>
> On Wed, Dec 02 2015, ROSENSWEIG, ELISHA (ELISHA) wrote:
> > Regarding the second point: Say we have 30 different types of alarms
> > we might want to
On Wed, Dec 02 2015, ROSENSWEIG, ELISHA (ELISHA) wrote:
> Regarding the second point: Say we have 30 different types of alarms we might
> want to raise on an OpenStack instance (VM). What I understand from your
> explanation is that when we create a new instance, we need to create 30 new
> alarms
Hi Ryota,
Thanks for your response, please see my comments below.
Ifat.
> -Original Message-
> From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com]
>
> Hi,
>
>
> Sorry for my late response...
>
> It seems like a fundamental question whether we should have rich
> function or intelligence
Hi,
Sorry for my late response...
It seems like a fundamental question whether we should have rich function or
intelligence in on-the-fly event alarm evaluation. I think we can add simple
operations (like aggregating alarm) in aodh evaluator, and other operations
(like deducing with
> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
>
> On Wed, Dec 02 2015, AFEK, Ifat (Ifat) wrote:
>
> > Can this be supported without defining an alarm for every VM
> separately?
>
> No, it's not possible. You'd have to create the alarm for each instance
> for
On Tue, Dec 01 2015, ROSENSWEIG, ELISHA (ELISHA) wrote:
> 1. Does AODH currently support raising alarms on resources not modeled
> in OpenStack? For example, raising an alarm on a Switch? Or does each
> alarm have to relate to a resource ID (or IDs)(
Yes, Aodh does not really care, especially
Wednesday, December 02, 2015 12:26 PM
> To: ROSENSWEIG, ELISHA (ELISHA)
> Cc: OpenStack Development Mailing List (not for usage questions); AFEK,
> Ifat (Ifat)
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom
> alarms in AODH
>
> On Tue, Dec 01 2015, ROS
r AODH integration right now.
>
> Thanks,
> Ifat.
>
>
> -Original Message-
> From: AFEK, Ifat (Ifat) [mailto:ifat.a...@alcatel-lucent.com]
> Sent: Tuesday, November 24, 2015 7:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-de
m: Julien Danjou [mailto:jul...@danjou.info]
> Sent: Tuesday, December 01, 2015 3:25 PM
> To: AFEK, Ifat (Ifat)
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom
> alarms in AODH
>
>
On Tue, Dec 01 2015, AFEK, Ifat (Ifat) wrote:
> In Vitrage, we would like to evaluate and correlate different kinds of alarms:
> AODH threshold alarms, event alarms, Nagios alarms, Ganglia alarms, Zabbix
> alarms, etc. This includes alarms on physical resources that are not part of
> OpenStack,
) [mailto:ifat.a...@alcatel-lucent.com]
Sent: Tuesday, November 24, 2015 7:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms
in AODH
Hi Gord, Hi Ryota,
(I sent the same mail again in a more readable format
,
Ifat.
[2]
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
> -Original Message-
> From: gord chung [mailto:g...@live.ca]
> Sent: Monday, November 23, 2015 9:45 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer][aod
ists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising
> custom alarms in AODH
>
>
>
> On 23/11/2015 11:14 AM, AFEK, Ifat (Ifat) wrote:
> > I guess I would like to do both: create a new alarm definition, then
> > trigger it (call
fat.a...@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.
&g
On 23/11/2015 11:14 AM, AFEK, Ifat (Ifat) wrote:
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,
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
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
Hi Gord,
Please see my answers below.
Ifat.
> -Original Message-
> From: gord chung [mailto:g...@live.ca]
> Sent: Monday, November 23, 2015 4:57 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom
> alar
32 matches
Mail list logo
