Re: [Hawkular-dev] scope of the agent design
Hi,
Not to mention all the integration weight we'll have to carry. Keeping up with the
third party software versions and backwards compatibility is going to incur a huge cost in
terms of development hours. The same issue we had with building RHQ plugins for every
product.
Supporting software where we can send plugins for the third-party to "keep up"
is going to be easier for us (assuming we get some users for those - in which case there
might be community updates to some of those plugins to keep them working) than building
compatible APIs to our core. And in any case, those third-party agents will not provide us
the USP we want.
- Micke
----- Original Message -----
From: "Heiko W.Rupp" <hrupp(a)redhat.com>
To: hawkular-dev(a)lists.jboss.org
Sent: Tuesday, March 17, 2015 12:13:32 PM
Subject: Re: [Hawkular-dev] scope of the agent design
On 16 Mar 2015, at 20:58, Lukas Krejci wrote:
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.
What if the users does not have any of those tools installed?
Do we tell them "install Ganglia, but not the graphing, only the
monitoring".
Ah and as this does not cope well with WildFly 94 please install
collectd on top?
not some "heavy" agent in the RHQ sense.
Running many of the small tools in parallel also has a cost. Similar
to forking hundreds and thousands of shell commands.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev