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@redhat.com>
To: "Discussions around Hawkular development" <hawkular-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev