10:17 a.m.
On Tuesday, March 17, 2015 11:13:32 Heiko W.Rupp wrote:
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".
I think that is going to just depend on the usecase. It might be easier to
tell them "install Ganglia" if it provides just the monitoring capabilities
they need. It also might be easier to tell them use Hawkular agent.
Or they might have requirements that neither can meet.
Ah and as this does not cope well with WildFly 94 please install
collectd on top?
I am pretty much sure Hawkular will have the same kind of problems. RHQ had
them for sure because incompatibilities are pretty much unavoidable IMHO.
> 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.
In my mind, the most optimal feed is an in-process feed - no problems with
security, inter-process/network comms overhead, etc.
The way people do "small" monitoring IMHO, is to run many small scripts on
schedule. Even if there is a thousand of them, they run for a short period of
time so the load spreads nicely (usually, of course everything is a function
of scale as we know from RHQ ;) ).
Having 1 external process to do all monitoring, as we had in RHQ, has also its
pros - for one it is easier to estimate the monitoring "cost" by looking at
the memory and CPU consumption of the external agent.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev