[Hawkular-dev] Event Store - triggering alerts

[Gary Brown]

Hi Jay

Thanks for the detailed explanation.

>From a BTM perspective, we will mainly be dealing with json on the bus, so its likely users would want to evaluate individual fields within the json structure. So string evaluation is ok for now, but I think we should plan for supporting more complex condition evaluation in the future.

Regards
Gary

----- Original Message -----
> 
> Hi Gary,
> 
> Probably restating much of the below...  Alerts does integrate with the
> bus and listens on three topics.  Two of which are specific to
> integrating with Hawkular Metrics, and one is relevant only to bus
> integration.  Hawkular feeds will supply numeric and availability
> metrics and those will be published to the HawkularMetricData and
> HawkularAvailabilityData topics.  H Alerts subscribes to them both.
> Because only a small subset of data persisted in metrics will be
> relevant to alerting (only those involved in defined trigger
> conditions), alerts filters out the irrelevant data in the listener
> code.  It then translates the filtered metric data into the format
> suitable to alerts and forwards it for alert evaluation (via the Java
> API).  Additionally, data can be published to the bus HawkularAlertData
> topic, and that data goes straight into alert processing, currently
> without filtering, although that may change.
> 
> So, Events data could be published and picked up via the bus today by
> sending to the HawkularAlertData topic.   Of course there is also a rest
> endpoint for sending in data.  Alerting currently supports 3 types of
> "primitive" data: numeric, availability and string, which are used in
> the various condition types.
> 
> But more likely we'd want something like you suggest, something
> analogous to the listener we have on HawkularMetricData, add a listener
> for published events, filter them as needed, and forward relevant events
> for evaluation.  One question, I guess, is whether alerting on events
> requires a dedicated type, and dedicated condition types in alerting, or
> whether the current "primitives" are sufficient.
> 
> For example, in RHQ, alerting on logging events could involve match on
> log level, the logfile path, and/or the actual log entry text. We don't
> have support for that kind of condition evaluation today in alerting.
> We'd rather have to distill it down to a single string datum and a regex
> test, for example.
> 
>  >  Do we want the alerts engine to have that capability? i.e. as part
> of the trigger definition, we offer the ability to define a bus
> topic/queue/selector to feed the alert engine?
> 
> So, I don't think we want to incorporate data sources/streams into our
> trigger definitions but rather, as Lucas says, insulate the engine and
> keep it cleanly separated from the bus.  Keeping the
> reception/filtering/translating of event data in the hawkular (i.e.
> glue) code.
> 
> Regards,
> Jay
> 
> 
> On 5/12/2015 11:50 AM, Gary Brown wrote:
> > Hi Lucas
> >
> > I'd just started looking at hawkular-alerts-bus :)
> >
> > Just wondering how complex the configuration may become in the glue, if it
> > is used to wire up the components but also potentially has to apply
> > filters - but we can see what is possible.
> >
> > Regards
> > Gary
> >
> > ----- Original Message -----
> >> Hi Gary,
> >>
> >>> I believe currently the alerts engine does not subscribe to the bus for
> >>> events, so events need to be supplied to the alerts engine explicitly?
> >>>
> >> Today, alerts component listens from the bus for data alerts.
> >>
> >> Also, these data is "filtered" from metrics, in the meaning that not "all"
> >> data coming from metrics is insteresting for alerts, so in the "glue" we
> >> have a component to filter from one topic and put the data that is
> >> consumed
> >> for alerts.
> >>
> >> I guess that for Events we can do a similar approach.
> >>
> >>
> >>> Do we want the alerts engine to have that capability? i.e. as part of the
> >>> trigger definition, we offer the ability to define a bus
> >>> topic/queue/selector to feed the alert engine?
> >>>
> >> The trigger definition is more generic, it doesn't matter from alerts
> >> domain
> >> from which "source" a data is provided.
> >>
> >> The data model that alerts engine is expecting is here:
> >>
> >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data
> >>
> >> Perhaps, we can add more data types if needed for inference processes.
> >>
> >>> Or should the "event store" allow a listener to be defined (in the glue)
> >>> that
> >>> could supply events to the alert engine - but then this slightly
> >>> separates
> >>> the alert definition into two parts - the bit bridging the event store
> >>> and
> >>> alert engine, and the trigger definition on how the event should be
> >>> processed.
> >>>
> >> I'm +1 to separate the bus integration layer aspect from the pure alerts
> >> inference.
> >>
> >> Today, we have the same separation and the "glue" code lives here:
> >>
> >> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-bus
> >>
> >> As we identified a "filtering" preliminar tasks that is not part of
> >> inference
> >> itself.
> >>
> >> In the other hand, having this separation we can maintain or goal to have
> >> an
> >> scenario with metrics+alerts and without bus dependencies.
> >>
> >> Regards,
> >> Lucas
> >> _______________________________________________
> >> hawkular-dev mailing list
> >> hawkular-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >>
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> >
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>