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

[Stefan Negrea]

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Tuesday, November 10, 2015 4:09:15 PM
> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
> 
> - Start a Hawkular server
> - Use the REST resources under /hawkular/alerts to create a trigger for
> 'my_fancy_gauge'
> - Use the REST resources under /hawkular/alerts to create an external
> condition (my understanding is that such a condition will always
> evaluate to true if data is received)
> - Use the REST resources under /hawkular/alerts to create a webhook action
> - Use the REST resources under /hawkular/metrics to publish data

I was afraid of that answer. That was neither the spirit nor the intent of the proposal.

> 
> 
> Le 10/11/2015 22:36, Stefan Negrea a écrit :
> >
> >
> > Thomas, I will ask the same thing I asked John earlier. Can you then please
> > walk through how to implement the feature proposed in the document? I can
> > see how it can be done in the proposals I put in the document and
> > discussed so far. But looks like you might have a different alternative.
> > Do you mind explaining the alternative and walking through the design and
> > implementation?
> >
> >
> >
> > ----- Original Message -----
> >> From: "Thomas Segismont" <tsegismo at redhat.com>
> >> To: hawkular-dev at lists.jboss.org
> >> Sent: Tuesday, November 10, 2015 3:06:33 PM
> >> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
> >>
> >> Le 10/11/2015 18:09, John Sanda a écrit :
> >>>> After this long introduction, there are three main reasons the current
> >>>> solution needs improvements:
> >>>>>
> >>>>> 1) Addressability -> the current solution does not work in the
> >>>>> distributed environment because there is no clear way how to access the
> >>>>> public API of the services deployed. Let's say the installation spread
> >>>>> across 5 containers. How can I make a public API call from a Metrics
> >>>>> instance to an Alerts instance. There is no directory to know where the
> >>>>> Alerts or Metrics instances are deployed.
> >>> Addressability is provided by the messaging system. There is no need for
> >>> a
> >>> directory. You just to need to communicate with the messaging
> >>> server/broker. Beyond that there are a lot of features around
> >>> addressability and routing such as message selectors, message grouping,
> >>> hierarchical topics, and more.
> >>
> >> +1
> >>
> >>>
> >>>>> 2) Load distribution -> there is no clear way on how the load
> >>>>> distribution works or who is responsible for it.
> >>> Again, this is largely handled by the messaging system. Multiple
> >>> consumers
> >>> take messages from a queue where each message corresponds to work to be
> >>> done.
> >>>
> >>
> >> Right, load distribution is a feature of the messaging system. As for
> >> HTTP load balancing, there is hardware and software dedicated to this, I
> >> would avoid building an HTTP load balancer into the project.
> >>
> >>>>> 3) Availability of the existing public API -> There is no reason to
> >>>>> implement a new API just for the purposes of communicating between the
> >>>>> components. Given that we strive for this micro-service architecture,
> >>>>> the one and single public API should be the main method for
> >>>>> communicating between components for request-reply.
> >>> I do not think it is a given that we strive for a micro-service
> >>> architecture. It might make more sense in an OpenShift environment, but I
> >>> don’t think it necessarily does in general.
> >>>
> >>>
> >>>>> We might need to extend what we have but the public API should be front
> >>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other
> >>>>> method), the public API interface should be available over all the
> >>>>> channels. Sure there might be difference on how to make a request in
> >>>>> JMS
> >>>>> vs HTTP (one with temporary queues, and the other with direct http
> >>>>> connections) but the functionality should be identical.
> >>> I don’t know that I agree with this. Suppose we decide to offer an API
> >>> for
> >>> inserting metric data over UDP to support really high throughput
> >>> situations. Are you suggesting for example that the operations we provide
> >>> via REST for reading metric data should also be available via the UDP
> >>> API?
> >>> And since the motivation for a UDP API is performance/throughput, we
> >>> might
> >>> event want to a more compact request format than JSON.
> >>>
> >>> Lastly and most importantly, if you want push for an alternative
> >>> communication mechanism between components in H-Metrics and H-Alerts,
> >>> then
> >>> you push for the same across all of Hawkular because it does not make to
> >>> have to support two different mechanisms.
> >>
> >>
> >> The public API (JSON over HTTP) is how the users must interact with the
> >> Hawkular platform. It is the unique entry point for the users.
> >>
> >>
> >> It's has been agreed during the project inception to make Hawkular
> >> components talk to each other via the bus. It is not a trivial change to
> >> break this assumption: everything the bus provides (see above) will need
> >> to be re-implemented.
> >> That is why I am opposed to the change, unless it is proven that it is a
> >> limitation.
> >>
> >> _______________________________________________
> >> 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
>