2:29 a.m.
This is a big point.
I can see pros and cons on it.
First thing it comes to me is that metrics has a stateless nature meanwhile alerts is
stateful.
So a first coupling would work for a single node but when we want to scale our troubles
can start as the design in clustered scenarios is completely different and a single .war
won't help IMO.
I don't think our current design is bad, in the context of the HAWKULAR-1102 and
working in a demand publishing draft we are addressing the business issues that triggered
this discussion.
But I would like to hold this topic for a future architecture face to face meeting, to
discuss it from all angles as we did on Madrid.
(Counting with a face to face meeting in a reasonable timeframe, of course).
Lucas
----- Mensaje original -----
De: "John Sanda" <jsanda(a)redhat.com>
Para: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Enviados: Lunes, 15 de Agosto 2016 16:45:28
Asunto: Re: [Hawkular-dev] metrics on the bus
We use JMS in large part because metrics and alerts are in separate WARs (I
realize JMS is used for other purposes, but I am speaking strictly about
this scenario). Why not deploy metrics and alerts in the same WAR and
altogether bypass JMS? As data points are ingested, we broadcast them using
an Rx subject to which both metrics and alerts subscribe. We could do this
is in away that still keeps metrics and alerts decoupled as they are today.
We would also have the added benefit of having a stand alone deployment for
metrics and alerts.
On Aug 10, 2016, at 9:37 AM, Jay Shaughnessy < jshaughn(a)redhat.com > wrote:
Yes, in fact I should have made it more clear that this whole discussion is
bounded by H Metrics and H Alerting in the H Services context, so limiting
this to HS/Bus integration code is what we'd want to do.
On 8/10/2016 4:06 AM, Heiko W.Rupp wrote:
Someone remind me please.
That bus-sender in/or hawkular-metrics is not an
internal detail of metrics, but rather sort of
'external add-on'?
If so, the logic to filter (or create many subscriptions)
could go into it and would not touch the core metrics.
Metrics would (as it does today) forward all new data-
points into this sender and the sender can then decide
how to proceed.
_______________________________________________
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