Re: [Hawkular-dev] scope of the agent design

On Monday, March 16, 2015 15:42:19 John Sanda wrote: >> On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: >> >> On 16 Mar 2015, at 20:07, John Sanda wrote: >>> For monitoring purposes, do we really need to write an agent? Should >>> we just leverage existing tools/libraries? I previously cited three >> (Re)using all those tools is fine and certainly desired, but the issue >> is less >> about what some random tool uses to collect metrics inside an app, but >> rather how to access and transport them. Using JMX like in the good ol' >> days is certainly a way. Or using the Jolokia Java agent. But still >> someone >> needs to talk to them. > Accessing and transporting the data is already answered to a large degree. > That is the primary reason I brought it up in the first place. Another > aspect to consider is that different types of monitoring agents lend > themselves better to different scenarios. I think that focusing more on > integration with existing agents/collectors gives us a better chance of > being able to use the best tool for a particular situation. +1 That's why I was advocating for "no agent at all" a couple of days ago. Frankly, that was a little bit too radical and not thought through. You articulated the point I wanted to make much better. On the "agent side" there are more than plenty of tools that are already in use. We should first try to find ways of integrating with these tools and only when none of pre-existing stuff implements our usecase (in a good enough way) we should look to implement an "agent" of our own. It is my current (most probably naive) understanding that those agents should be small tools for particular jobs (or maybe extensions to existing tools), not some "heavy" agent in the RHQ sense. Better yet, in addition to integration with existing metric-collection tools, I think we could write some "integration libraries" for some popular languages (bash, java, python, ...) that would enable easy integration of hawk metrics into existing software or enable users to write new "feeds" (because "agent" is a too overloaded term) on their own. These feeds could be any of the 3 types you mentioned and we wouldn't actually care on the server side.

>> Writing a subsystem for inside Wildfly to actively report/submit data >> is in fact an (embedded) agent. Not a general purpose one. >> >> We already have converters from collectd, gmon and a few other >> protocols into Hawkular(-metrics). So yes, they should all be allowable >> as input. >> >> And then we will have more specialized use cases that most probably go >> much >> further than just submitting some metrics to the Hawkular(-metrics) >> server. >> In this case some more specialized code may be needed too. >> _______________________________________________ >> 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