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

From: "Thomas Segismont" <tsegismo(a)redhat.com&gt; To: hawkular-dev(a)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

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(a)redhat.com&gt; >> To: hawkular-dev(a)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(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