[Hawkular-dev] Event Store

Lucas Ponce lponce at redhat.com
Fri May 8 05:08:50 EDT 2015



----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Friday, May 8, 2015 10:57:52 AM
> Subject: [Hawkular-dev] Event Store
> 
> Hi
> 
> As discussed yesterday, we need a general event store that can persist
> relevant events off the bus. However we didn't decide where this
> functionality should reside, whether in an existing component or in a new
> component.
> 
> Although it could be provided as a separate component, I am not sure we have
> any use cases where it would be used independent of the bus, so think it is
> probably best to include it as additional functionality within the Bus
> component.
> 
> Agree/disagree?
> 

In terms of archicture I would suggest to follow a similar architecture discussed for metrics/alerts/inventory.

A main component with this persistence/Java API dependencies and then to a Listener/CDI/TBD (glue) project that integrate the component with the Bus, so then if needed, component could work without Bus dependencies.
Perhaps we don't have an isolated use case without kettle/bus but I think that in that way we can unify the picture.


> The other issues are:
> 
> - how to determine which events should be persisted, as we may want some
> events to trigger further processing by subscribers on the bus, but not
> necessarily be stored for historic analysis.
> 
> - for the event store we will need to know the type of the event being stored
> 
> So one possible solution to both these issues is, if the 'type' of the event
> is provided (possibly as a header value), then it will be persisted?
> 
> Then within Elasticsearch, we can use the tenant/persona as the Index (to
> truly segment the data) and the event type to ensure different information
> types are partitioned/indexed appropriately.
> 
> Thoughts?
> 


In the meeting there was introduced ElasticSearch product/project but I would like to focus first in the requirements, in what we need, I know that metrics have their own querying requeriments, and also alerts and inventory.
So, before to introduce the product, I would like to get more info about what kind of filtering do we need (perhaps we can use elastic search in other areas) so, it could be interesting to discuss first, to see pros/cons also from architecture/dependencies and also to share with the other components how we are resolving today these aspects.

> Regards
> Gary
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


More information about the hawkular-dev mailing list