Hi, I did take a look at the event admin solution. One question up front. Why do we need the logging collector with the event admin solution? If eventadmin is present all log entries should/could be posted directly via the eventadmin.
Regarding Topics and Indices, I don't think its a good idea to create multiple indices, but the topic can be used differently. Instead of sending karaf_events client.prepareIndex(indexName, "karaf_event").setSource(jsonObject .toString()).execute().actionGet(); the topic could be used instead client.prepareIndex(indexName, event.getTopic()).setSource(jsonObject .toString()).execute().actionGet(); That should be more like what you where expecting to achieve with the index. regards, Achim 2015-03-14 12:38 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > Hi Christian, > > it sounds good. Thanks for that. > > Maybe the only comment would be to be careful to not tight too much > collector and appender (I mean in term of data format). The purpose of > Decanter is to be very flexible and generic, and to be able to work with > other data than the JMX metric. For instance, we have plan to plug the > Camel Tracer as a Collector (to store Exchange in the appenders' backend), > CXF interceptor collector, etc. > > I like what you did and it makes lot of sense. I think we have to move > forward now on the "console" layer, it's in my bucket (any help/ideas are > welcome). > > Regards > JB > > > On 03/14/2015 12:07 PM, Christian Schneider wrote: > >> I just finished switching decanter to EventAdmin. >> https://issues.apache.org/jira/browse/KARAF-3613 >> >> The idea is to replace our own Dispatcher interface with the standard >> EventAdmin. >> >> Before my change a map of maps like this was transported: Map<Long, >> Map<String, Object>> events; >> The first step was to transport each event individually: Map<String, >> Object> event; . The key "timestamp" represents the creation time. >> I think it is no big issue to transport each event as the appenders do >> this anyway. >> >> The next step was to replace the Map<String, Object> with the EventAdmin >> Event which is similar and to use the EventAdmin interface instead of >> Dispatcher. >> >> The nice thing is that EventAdmin supports topics. So this allows for >> example to put the appender name of a log message into the topic. So >> appenders can listen >> to either the top level topic or a sub topic. Currently the appenders >> use the top level but we can change this easily. >> >> You can see the result in branch EventAdmin: >> https://git-wip-us.apache.org/repos/asf?p=karaf-decanter. >> git;a=tree;h=refs/heads/EventAdmin;hb=refs/heads/EventAdmin >> >> >> Possible enhancements: >> We could represent the mbean name as a topic. >> >> For the elatic search appender a nice enhancement would be to use >> diferent index names for the jmx and log topics. As the data is very >> different I think it makes sense to >> also use different ES indexes. >> >> I would be happy about your feedback. >> >> Christian >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
