[Hawkular-dev] scope of the agent design

[John Doyle]

+1, we want to be up and running very rapidly, even if that means in a limited fashion.

~jd

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