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