[Hawkular-dev] scope of the agent design

John Sanda jsanda at redhat.com
Mon Mar 16 16:19:41 EDT 2015


> On Mar 16, 2015, at 3:58 PM, Lukas Krejci <lkrejci at redhat.com> wrote:
> 
> On Monday, March 16, 2015 15:42:19 John Sanda wrote:
>>> On Mar 16, 2015, at 3:24 PM, Heiko W.Rupp <hrupp at redhat.com> 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.

I definitely agree that we should be thinking about integration libraries for different languages. We have a clear use case for Go already, and I think Python makes sense too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150316/db3b4acd/attachment-0001.html 


More information about the hawkular-dev mailing list