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

Thomas Segismont tsegismo at redhat.com
Tue Nov 10 16:28:11 EST 2015


Le 10/11/2015 19:09, Lucas Ponce a écrit :
> It is a little bit hard to jump into this long threads but interesting.
>
> I am going to describe my thoughts if that can help (or not) into this discussion.
>
> I think before to get into low level details, it is good to discuss perhaps in some high level motivations as ThomasS commented, and that might help to check in we are everyone in the same page.
>
> Today (if I am not wrong) we have three/four main scenarios where our efforts are driven:
>
> - A standalone use of Hawkular Metrics (mainly for OpenShift).
>
> - Hawkular, a integrated project of several components/subproject (bus,accounts,metrics,alerts,inventory,agent,ui,new ones).
>
> - Hawkular BTM (not sure if this will be consumed as part of Hawkular as add-on, or a variant).
>
> - Hawkular DataMining module (not sure if this will be consumed as part of Hawkular as add-on, or a variant).
>
> It happens as our components are decoupled and can be consumed separately, so it could be valid if the same user that is using metrics in standalone can add alerts too to work together, but probably that user is not interested in the full Hawkular solution as it has developed its own security, feeds and inventory frameworks (or any combination).

Right. We need to make sure that, as Hawkular evolves, Alerts and 
Metrics continue to work together, even when other components are not 
involved (including accounts and Keycloack).

>
> So, for me, a legitimate question could be: "how easy it can be to put two components working together?".
>
> That I think is what we are discussing here.
>
> So, if a user can deploy a metrics.war and alerts.war in the deployments folder on a standard wildfly server, that could be interesting an attractive for everyone (or at least that I think is our main motivation for this discussion).
>
> And it can be worth to study what we need to do this, if we might have some limitation in terms of scalability
> (if any, which is something read but not discussed in deep, several strong statements about architecture but that needs to be ellaborated).
>
> If at the end, we reach to a conclusion that communication between components needs an extra effort, I have my conclusion clear: we need to go through Hawkular, not replicating things, or in other words, focus all efforst in a single solution that can be used in several scenarios.

As part of the migration to Wildfly 10, we will get rid of the ActiveMQ 
resource adapter and use the messaging capabilities offered in the 
container. So yes, when the migration is over, deploying Alerts + 
Metrics will be a matter of copying the archives to the deployments folder.


More information about the hawkular-dev mailing list