<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 13, 2017 at 8:08 PM, John Mazzitelli <span dir="ltr"><<a href="mailto:mazz@redhat.com" target="_blank">mazz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Although I am more generally asking why an agent is needed at all. Why not<br>
> simply pull from the remote EAP node using a user that is setup for<br>
> monitoring? That would reduce the software installation and maintenance<br>
> overhead to just a configuration overhead.<br>
<br>
</span>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?"<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thomas?<br>
<br></blockquote><div><br></div><div>We need to support multiple projects, in multiple environments, for different consumers.</div><div><br></div><div>Multiple projects:</div><div> - Wildfly</div><div> - Fuse on Karaf</div><div> - Fuse on Wildfly</div><div> - Infinispan on a modified Wildfly</div><div> - Tomcat</div><div> -...</div><div><br></div><div>Multiple environments:</div><div> - Bare Metal / VM</div><div> - OpenShift / docker containers</div><div><br></div><div>Different consumers:</div><div> - ManageIQ that requires monitoring(Metrics/Alerting) and operations (stop, reload, (un)deploy...)</div><div> - Possibly OpenShift console (For metrics only, since the containers would be considered immutable)</div><div><br></div><div>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).</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>I hope this helps understanding the reasoning behind the initial ask.</div><div><br></div><div>Thomas</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div><br></div></div>