[wildfly-dev] a way to obtain local ModelController within javaagent?

[Thomas Heute]

On Mon, Mar 13, 2017 at 8:08 PM, John Mazzitelli <mazz at redhat.com> wrote:

> > Although I am more generally asking why an agent is needed at all. Why
> not
> > simply pull from the remote EAP node using a user that is setup for
> > monitoring? That would reduce the software installation and maintenance
> > overhead to just a configuration overhead.
>
> Can you clarify? Are you asking, "Why not have a single agent running
> "somewhere" and have it pull from a collection of remote EAP nodes?"
>
> In fact, this Hawkular Agent does support this kind of deployment (the
> Agent can be told to monitor N remote servers whether or not those remote
> servers are running on the same machine or somewhere else on the network).
>
> One issue with something like that is - most customers do not want to
> expose their remote management endpoints past the localhost boundary. In
> that case, this means the agent must be at least installed on the same
> machine as the EAP node itself even if it isn't running in the same JVM.
> But now they have to install two things - the agent and the WildFly -
> albeit on the same machine. If that is the case, why not just bundle the
> agent together with WildFly so you have a single distribution we can call
> "instrumented WildFly" that a user has to worry about installing? You run
> your instrumented Wildfly server normally but now you automatically get
> inventory/metrics uploaded and stored to CloudForms which can then
> immediately begin to manage it. No need to install and run a separate agent
> process.
>
> I would like to ask Thomas Heute to reply to this thread as he has more
> details about why we want it this way - he's dealt alot more with user
> requirements and the like.
>
> Thomas?
>
>
We need to support multiple projects, in multiple environments, for
different consumers.

Multiple projects:
   - Wildfly
   - Fuse on Karaf
   - Fuse on Wildfly
   - Infinispan on a modified Wildfly
   - Tomcat
   -...

Multiple environments:
   - Bare Metal / VM
   - OpenShift / docker containers

Different consumers:
   - ManageIQ that requires monitoring(Metrics/Alerting) and operations
(stop, reload, (un)deploy...)
   - Possibly OpenShift console (For metrics only, since the containers
would be considered immutable)

Our original route was to build specific agents for each project or at
least each "container" (vert.x, Karaf, Wildfly), but talking to Kevin (in
CC), he's concerned about the multiple agents for the different docker
containers (as much as we were concerned for other reasons as we need to
ask more to the various teams so that they can build/maintain their agents).

Then came the idea of the javaagent (or rather the idea that we could turn
our DMR/Wildfly specific subsystem into a very generic javaagent in a short
amount of time), the Fuse team (Thomas in CC) validated the approach, it
works for Fuse on Karaf and Fuse on Wildfly the same way, same
configuration AFAIK. It simplifies a lot the number of pieces to
release/maintain, the documentation, the quality...

About the agent. We very much prefer to have 1 agent per standalone Wildfly
for multiple reasons, one of those is that it's easy for a Wilfly user, add
the agent (+ their config + their deployments) and provision machines with
it. While if you have 1 agent for N Wildfly, it needs a way to discover the
new instances, or worse, need manual configuration changes.
For domain mode, we'd prefer to have 1 Wildfly per host (Or domain ? I
never remember) controller, the discovery of new node is not a problem in
this scenario, and then all the nodes of the EAP domain are using the same
monitoring configuration.

I hope this helps understanding the reasoning behind the initial ask.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170315/9536dc1d/attachment.html