[Hawkular-dev] scope of the agent design

[Lukas Krejci]

On Tuesday, March 17, 2015 16:50:59 Thomas Heute wrote:
> I don't think we are on the same page regarding the focus of the
> project/product.
> 
> Hawkular is targeted toward Red Hat Middleware management, for
> infrastructure management there are gazillion other solutions.
> We need "some" basic infrastructure management, for those basic needs a
> user shouldn't need to maintain a solution made of multiple puzzle pieces.
> 
> Look at NewRelic or ruxit those are dead simple to install and to start
> monitoring.
> 

As great as ruxit is, it requires to run their agent as root, forcing itself 
into ld.so.preload and modifying selinux policies. That gave me a bit of 
shivers (https://answers.ruxit.com/questions/286/).

I thought Red Hat does things the UNIX/microservice way - integrating tools 
that do 1 thing and do it well. Hence my focus on integration.

I do hope we are on the same page, though. I was maybe a bit loud at stressing 
the integration aspect because I saw the tendencies to write yet another RHQ 
agent. IMHO, that is something we should try to avoid/minimize if possible 
(and I am not saying there won't be usecases requiring it - I just think it 
should not be the first choice when trying to implement something).

The good thing about integrating with 3rd party monitoring is that we get what 
they are able to monitor "for free" (where free is the cost of keeping 
ourselves compatible with the 3rd party tool ;) ) which enables our users to 
reuse the monitoring they most probably have already set up and only upgrade 
the server-side to a hopefully much more capable thing that Hawkular will be.

As I said already below, I think it is worth pursuing the in-process 
management where possible as that should avoid the pitfalls/usability problems 
we ran into with RHQ agent.

The proportion of work on in-process management versus the integration with 
3rd party tools vs out-of-process "full" agent is of course a function of 
priorities and project/product focus. I just wanted to try and persuade people 
that relying on there being an "Hawkular agent" is IMHO not the best solution 
to our overall "agent-side" architecture. It probably will be a part of the 
picture, but it should not be required, IMHO.

> Thomas
> 
> On 03/17/2015 04:17 PM, Lukas Krejci wrote:
> > 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 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