3:49 a.m.
When we started the hawkular efforts, I had in mind that the
components
would do minimum tasks as a library with REST/Java APIs and do them well.
Inventory would manage resources (user defined (an "application", a
cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
assign ids...
Metrics would store/aggregate/compact metrics (like it is today)
Alerts would define some alert definition "model" and run an engine to
define when to trigger an alert.
...
Hawkular project would then be a firm/comprehensive solution that are
using all those components, would proxy the APIs, add security there
(instead of in each component),...
But now I start to see that client aspect of the communication bus is
part of those components I think I understand the motivation for that
but not sure that this is what we really need. Am I the only one
thinking that the communication aspect should be left out of the
components ?
I think there is info that will be shared between components, so it's needed to define
a shared/common model between components.
For example, alerts component should "listen" from some point data/events to
evaluate when to trigger an alert.
In the first prototypes we are supposing that it will be a "MetricsTopic" in the
bus where alerts component can subscribe for this data.
This is a minimalist scenario.
But, also, yesterday we were discussing with Jay that we can have more complex scenarios,
where an alert definition can compare two periods of time (for example, if this week was
better than before), in this last scenario we can have requeriments to ask for aggregate
data, and transform it in some model that alerts can use to evaluate alerts conditions.
In this last scenario, it seems that an alert definition could ask for data to metrics
subsystem.
So, it would be nice if we can progress in the shared data between components to define
what it could be best design to implement these scenarios.
I would start with common data (for example, queues/topic identified, data format shared,
etc).
For instance in http://docs.hawkularinventory.apiary.io/ for the
DumbFeed, I don't think it's the role of the Metrics to send
notification to the bus, if we need more than collecting metrics then it
is a job for Hawkular IMO (who may proxy the metrics request and send
notification to the bus).
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev