[Hawkular-dev] scope of the agent design

[Thomas Heute]

On 03/16/2015 08:58 PM, Lukas Krejci 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.

We also need auto-discovery to fill-in the inventory. It's not just a 
flow of data but we need to know how those "feeds" are related.

Thomas

>
>>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev