2:58 p.m.
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> 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