[Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

Tue Nov 10 11:52:06 EST 2015

----- Original Message -----
> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, November 9, 2015 4:51:47 PM
> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
> 
> 
> I guess what Stefan is trying to figure out is whether it makes sense
> and is useful to have Metrics use Alerts basically as a 3rd party tool,
> such that a potential Metrics client can focus on using Metrics and not
> worry about interacting with Alerts directly.   The proposal to me looks
> like an attempt to identify one of possibly many Metrics "events" that a
> user may be interesting in setting up for notification, in this case via
> a webhook.  So here we have proposed a MetricReported event (or was it
> MetricValueChanged?).  I don't know exactly what other events would be
> useful, but perhaps there are a lot of Metrics happenings that a client
> may want to be notified of.  It's not necessarily true that a client
> could do this by using the two tools independently, if in fact Metrics
> is adding hooks in its own processing to identify these "listenable
> events". But I don't get the feeling this is the proposal on the table,
> at least not for this first proposal.  Instead, I think to handle
> MetricReported the idea may have been to just create a trigger that
> looks for the specific metric data coming in and to fire an alert. In
> which case it is perhaps not as useful to have Metrics set it up, but
> it's still maybe a step towards Metrics coming up with some sort of
> useful API that would leverage Alerts for its impl.

Interesting idea to have other event types, not just metric insertions; that is definitely something to explore. You are correct, the goal of this phase is not explore those ideas, but this is a required precursor. We need to make a first attempt on inter-component communication.

> 
> As for deployment, it seems to me that a prepackaged Metrics+Alerts+Bus,
> that could [eventually] be replicated/clustered, would be good.  It
> could handle use cases where data is persisted and then pushed to the
> bus (like in hawkular), and then filtered and grabbed by alerts via a
> topic consumer. And it could handle REST interaction.  And it could
> offer the ability to leverage co-located clients as well.

Excellent point! That is the exact goal, to deliver a Metrics+Alerts package that can be used in environments where other features of Hawkular are not relevant. And vice-versa, there might be features implemented by this combined package that will never ever be relevant to Hawkular. We afford this kind of flexibility because of the microservice approach we took. That is why the decision to split everything into components was made, right?

> 
> By the way, there is still the integration component I put together a
> while ago, that is completely independent of this discussion. It's an
> external alerter that is both a client of metrics and alerts, and
> generates alerts based on the results of aggregate queries performed
> against metrics.

I would prefer to port all that functionality to the architecture we decide through these discussions. 

> 
> 
> On 11/9/2015 12:48 PM, Thomas Segismont wrote:
> > Le 09/11/2015 18:10, Stefan Negrea a écrit :
> >> Hello Thomas,
> >>
> >> So far there is no concrete proposal, only why things should not be done;
> >> which equates to inaction. I am not the most imaginative person on the
> >> planet so I might fail on that front, but I think the plan that I
> >> proposed had some cohesion and it was forward looking.
> >>
> >>
> >> Here is a good course of action:
> >> 1) Propose something new; completely new or partially new
> >> 2) Get the majority of the group (Metrics + Alerts teams) to agree on the
> >> path
> >> 3) Create the plan to accomplish it and lead the group to implement the
> >> plan
> > I understand the goals of your proposal. I'm simply opposed to
> > re-writing what already exists, unless it is proven that it is broken.
> >
> > Given the stress you rightfully put on moving fast, improving the
> > existing system seems like a reasonable approach.
> >
> > Now maybe you didn't know the features are already there, but they are.
> >
> >>
> >> Thank you,
> >> Stefan Negrea
> >>
> >> ----- Original Message -----
> >>> From: "Thomas Segismont" <tsegismo at redhat.com>
> >>> To: hawkular-dev at lists.jboss.org
> >>> Sent: Monday, November 9, 2015 10:43:26 AM
> >>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
> >>>
> >>> Le 09/11/2015 16:48, Stefan Negrea a écrit :
> >>>> Hello,
> >>>>
> >>>> That document uses what is already implemented as a base. Phase 0 (a
> >>>> prototype phase) should take the current implementation to the next
> >>>> level.
> >>>> All the things in the document where logical increments to what we have
> >>>> today. The goal was to have a quick Phase 0 to build something that we
> >>>> can
> >>>> get feedback on.
> >>> The use case detailed in the example is already possible with a Hawkular
> >>> server.
> >>>
> >>> I don't understand what taking the "current implementation to the next
> >>> level" means.
> >>>
> >>>> As for the requirements, there are no requirement and there will
> >>>> probably
> >>>> be very little requirements. There is no external entity to give us some
> >>>> requirements at this stage. If you consider that what is proposed in the
> >>>> document is wrong, I open to suggestions. However, I caution against
> >>>> inaction or slow action.
> >>>>
> >>> The use case detailed in the document is fine. But there's no need to
> >>> prototype an integration if it already exists.
> >>>
> >>>> Whatever we do should follow two basic principles:
> >>>> 1) Fast phase, 2-3 weeks of development
> >>>> 2) Build something simple that enables more complicated features in the
> >>>> future
> >>>>
> >>> I have yet to see a feature which requires to rebuild a new integration
> >>> mechanism.
> >>>
> >>>> More replies inline below ....
> >>>>
> >>>>
> >>>> Thank you,
> >>>> Stefan
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Thomas Segismont" <tsegismo at redhat.com>
> >>>>> To: hawkular-dev at lists.jboss.org
> >>>>> Sent: Monday, November 9, 2015 9:16:48 AM
> >>>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase
> >>>>> 0
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Phase 0 is already implemented:
> >>>>> - Metrics can receive data over HTTP
> >>>>> - Metrics can publish inserted data to the bus
> >>>>> - Webhooks can be created/configured via the Alerts API
> >>>>> - Alerts is able to consume data from the bus
> >>>> That is not what the document states as goals for Phase 0. As the
> >>>> document
> >>>> is written what you described is a prerequisite for Phase 0.
> >>>    From Google docs:
> >>> "This document has two parts. First are the details about how to
> >>> exchange data between the two services. And then, there is a description
> >>> of a simple feature that can showcase the integration."
> >>>
> >>> 1. Data exchange between the two services is already implemented.
> >>> 2. The user facing feature is already possible with a Hawkular server.
> >>>
> >>> So phase 0 is over. Period.
> >>>
> >>>>> I can't see why we need to expose an endpoint in Metrics API to setup a
> >>>>> set of conditions in Alerts. The Alerts API does the job.
> >>>> Disconnected APIs are not an integrated solutions. Just as an example,
> >>>> the
> >>>> are issues with the maturity of the APIs on both ends. Until we go
> >>>> through
> >>>> the exercise of trying to integrate the two in a user facing feature we
> >>>> will not see the differences or be able to provide something meaningful
> >>>> to
> >>>> users.
> >>> What does disconnected mean? That they are not implemented by the same
> >>> software component? In this case it's not a problem.
> >>>
> >>> The webhook API won't be more mature because it's re-written from Alerts
> >>> into Metrics. Maybe I missed your point.
> >>>
> >>> Integration of Alerts and Metrics has been demonstrated and used this
> >>> very afternoon at Devoxx by Clément in the vertx workshop. I'd bet no
> >>> attendee (other than Juca) did notice there was 2 software components
> >>> behind the service.
> >>>
> >>> Truth is the scenario described in the document lacks an integration
> >>> test. I believe this could be added to:
> >>> https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test
> >>>
> >>>>> Do you already know the use cases for Phase 1?
> >>>> There are no requirements, and probably there will be no requirements in
> >>>> the next month (or even more). That is not the way to approach this.
> >>>    From my POV, the way to approach this is to write documentation and
> >>> tests for all the awesome features which already work but people
> >>> (including in our community) aren't aware of.
> >>> _______________________________________________
> >>> 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
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 