9:52 a.m.
Hi,
[ I picked "Matter" on purpose in the subject, as the other term (E.) is
too much overloaded. ]
ManageIQ has Events (going forward I call them ME), that are similar to
our Alerts.
There are some event parsers that take incoming data and then forward it
into the
MiQ events system, where automatic actions can be triggered
Now we have a pretty similar concept with our alerts.
For ME on metrics, MiQ pulls the metrics and the provider integration
creates
the ME on them.
I wonder if for other purposes we can use our existing alerts subsystem
with some "canned alerts", that translate input into such MiQ-Events and
forward them into MiQ.
With "canned" I mean that those are not set up via UI, but rather we
have "trigger templates" that are applied each time a new resource of a
given type is added to inventory.
This implies that those templates can only work on things that do not
have
a variable threshold like system going up/down, WildFly reporting
"reload
needed" and so on.
While it would be certainly possible to implement this at the level of
emitting
inventory "matters" and metric "matters" and so on I think having that
central
piece of logic to do it - could be better to handle.
10:02 a.m.
Although having "out of the box" canned triggers defined, it may also still be
good to provide users with a customisation mechanism to define their own alert triggers -
which create "events" for MiQ to consume and react to.
Users could just use the REST APIs - but still may be more user friendly to offer some
form of UI. This shouldn't be an issue, if it is considered
configuration/customisation of the provider?
Regards
Gary
----- Original Message -----
Hi,
[ I picked "Matter" on purpose in the subject, as the other term (E.) is
too much overloaded. ]
ManageIQ has Events (going forward I call them ME), that are similar to
our Alerts.
There are some event parsers that take incoming data and then forward it
into the
MiQ events system, where automatic actions can be triggered
Now we have a pretty similar concept with our alerts.
For ME on metrics, MiQ pulls the metrics and the provider integration
creates
the ME on them.
I wonder if for other purposes we can use our existing alerts subsystem
with some "canned alerts", that translate input into such MiQ-Events and
forward them into MiQ.
With "canned" I mean that those are not set up via UI, but rather we
have "trigger templates" that are applied each time a new resource of a
given type is added to inventory.
This implies that those templates can only work on things that do not
have
a variable threshold like system going up/down, WildFly reporting
"reload
needed" and so on.
While it would be certainly possible to implement this at the level of
emitting
inventory "matters" and metric "matters" and so on I think having
that
central
piece of logic to do it - could be better to handle.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:11 a.m.
I think the point is where this concept belongs (MiQ or the provider, or somewhere in the
middle).
I see valid that a provider have events that are forwarded to MiQ.
As it is commented, these events can go from different degree of complexities (from quite
simple, or even more complicated, with rules to generate this).
How to configure/manage this on the provider is the key, as Gary comments, possible
options could be REST only, or even UI.
My point is that we are introducing a new concept in MiQ which is the application point of
view, so, perhaps the whole Policy mechanism of MiQ is not enough to offer the richness
that an application point of view from middleware perspective needs, so having the way to
define these events in the provider is ok.
Lucas
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, March 1, 2016 10:02:17 AM
Subject: Re: [Hawkular-dev] "Matter" support in Hawkular
Although having "out of the box" canned triggers defined, it may also still
be good to provide users with a customisation mechanism to define their own
alert triggers - which create "events" for MiQ to consume and react to.
Users could just use the REST APIs - but still may be more user friendly to
offer some form of UI. This shouldn't be an issue, if it is considered
configuration/customisation of the provider?
Regards
Gary
----- Original Message -----
> Hi,
>
> [ I picked "Matter" on purpose in the subject, as the other term (E.) is
> too much overloaded. ]
>
> ManageIQ has Events (going forward I call them ME), that are similar to
> our Alerts.
> There are some event parsers that take incoming data and then forward it
> into the
> MiQ events system, where automatic actions can be triggered
>
> Now we have a pretty similar concept with our alerts.
>
> For ME on metrics, MiQ pulls the metrics and the provider integration
> creates
> the ME on them.
>
> I wonder if for other purposes we can use our existing alerts subsystem
> with some "canned alerts", that translate input into such MiQ-Events and
> forward them into MiQ.
> With "canned" I mean that those are not set up via UI, but rather we
> have "trigger templates" that are applied each time a new resource of a
> given type is added to inventory.
> This implies that those templates can only work on things that do not
> have
> a variable threshold like system going up/down, WildFly reporting
> "reload
> needed" and so on.
>
> While it would be certainly possible to implement this at the level of
> emitting
> inventory "matters" and metric "matters" and so on I think
having that
> central
> piece of logic to do it - could be better to handle.
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:31 p.m.
From what I've seen so far MiQ has a bunch of pre-defined events (MEs).
On first look, these MEs seem mostly relevant to VMs/Cloud providers and
maybe not so much to a MW manager. It is, I think, possible to define
custom events for a provider, like the hawkular provider.
Importantly, I think you can only send MiQ an event that it knows
about. So, any sort of ad-hoc generation of Hawkular events (HEs) may
not be a good fit, or there may need to be some "catch-all" pre-defined
ME to which they all map.
I do think it makes sense that the Hawkular provider define some custom
MEs that are more specific to application monitoring. Yesterday I
started experimenting and am trying to generate deployment events
(failures and successes) in MiQ. How these get to MiQ is an
implementation detail of our provider but it could very well make sense
to use H Alerts to generate HEs that then get pulled (I'm not sure yet
how this happens, I think it is a pull) as MEs, via the gem via a fetch
using the H Alerts rest API. In other words, use H Alerts' as our
provider impl for HE handling. It already has robust handling for
events, whether trigger generated or injected via the API. So
generate/feed all events into, and then fetch them via, H Alerts. This
does not even require any trigger definitions, or any alert generation,
until or unless we need it. Just use the already existing HE apis. This
is exactly how the deployment eventing works. We capture the deployment
response via the command gateway listener, which then converts the
response into an event. That event would then make its way from an HE
to an ME via the hawkular provider.
As an aside, we already have migrated all of Hawkular's trigger
definitions to the server so all of the old triggers are already in
headless hawkular. Whether we need any of them is unclear. For example,
an alert based on a failed deployment would likely no longer be useful
in hawkular, instead it would probably be defined as an alert in MiQ,
based on the Failed Deployment ME.
On 3/1/2016 4:11 AM, Lucas Ponce wrote:
I think the point is where this concept belongs (MiQ or the provider,
or somewhere in the middle).
I see valid that a provider have events that are forwarded to MiQ.
As it is commented, these events can go from different degree of complexities (from quite
simple, or even more complicated, with rules to generate this).
How to configure/manage this on the provider is the key, as Gary comments, possible
options could be REST only, or even UI.
My point is that we are introducing a new concept in MiQ which is the application point
of view, so, perhaps the whole Policy mechanism of MiQ is not enough to offer the richness
that an application point of view from middleware perspective needs, so having the way to
define these events in the provider is ok.
Lucas
----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
> Sent: Tuesday, March 1, 2016 10:02:17 AM
> Subject: Re: [Hawkular-dev] "Matter" support in Hawkular
>
> Although having "out of the box" canned triggers defined, it may also
still
> be good to provide users with a customisation mechanism to define their own
> alert triggers - which create "events" for MiQ to consume and react to.
>
> Users could just use the REST APIs - but still may be more user friendly to
> offer some form of UI. This shouldn't be an issue, if it is considered
> configuration/customisation of the provider?
>
> Regards
> Gary
>
> ----- Original Message -----
>> Hi,
>>
>> [ I picked "Matter" on purpose in the subject, as the other term (E.)
is
>> too much overloaded. ]
>>
>> ManageIQ has Events (going forward I call them ME), that are similar to
>> our Alerts.
>> There are some event parsers that take incoming data and then forward it
>> into the
>> MiQ events system, where automatic actions can be triggered
>>
>> Now we have a pretty similar concept with our alerts.
>>
>> For ME on metrics, MiQ pulls the metrics and the provider integration
>> creates
>> the ME on them.
>>
>> I wonder if for other purposes we can use our existing alerts subsystem
>> with some "canned alerts", that translate input into such MiQ-Events
and
>> forward them into MiQ.
>> With "canned" I mean that those are not set up via UI, but rather we
>> have "trigger templates" that are applied each time a new resource of
a
>> given type is added to inventory.
>> This implies that those templates can only work on things that do not
>> have
>> a variable threshold like system going up/down, WildFly reporting
>> "reload
>> needed" and so on.
>>
>> While it would be certainly possible to implement this at the level of
>> emitting
>> inventory "matters" and metric "matters" and so on I think
having that
>> central
>> piece of logic to do it - could be better to handle.
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:30 a.m.
On 1 Mar 2016, at 10:02, Gary Brown wrote:
Although having "out of the box" canned triggers defined,
it may also
still be good to provide users with a customisation mechanism to
define their own alert triggers - which create "events" for MiQ to
consume and react to.
I think this depends on the use case you want to address.
We need to make sure not to confuse users with basically
two places in the UI to set up "alerts" - one in the provider
integration and one in the 'automate' and 'control' sections
of the MiQ UI.
Actually before sending my original mail I had a section
about configuring some details of those canned triggers
via e.g. a config file.
Users could just use the REST APIs - but still may be more user
friendly to offer some form of UI. This shouldn't be an issue, if it
is considered configuration/customisation of the provider?
Yes. If it is clearly not duplicating the treatment of
the MiQ-events that already exists and rather configures
the way the provider initially sets up the translation
from Hawkular-internals to MiQ-Events.
3255
days inactive
3255
days old
4 comments
4 participants
participants (4)
-
Gary Brown -
Heiko W.Rupp -
Jay Shaughnessy -
Lucas Ponce