7:40 p.m.
On Mar 13, 2017, at 1:18 PM, John Mazzitelli <mazz(a)redhat.com>
wrote:
> Thanks for the info. Sorry to be annoying and ask the same question over and
> over, but what is missing from the remote management protocol that WildFly
> already provides?
Nothing is "missing" from it per-se. As a workaround, the agent is going
through this remote management protocol so it can do its thing. One feature I don't
think I mentioned is the agent can monitor remote WildFly (and Jolokia) servers - I use
that feature to monitor its co-located local WildFly server. Its local WildFly simply
looks like a remote server and it monitors it as such. So the javaagent, even though it is
running co-located in the same VM as the WildFly Server, is talking over the remote
management endpoint to its WildFly server as a workaround for this inability to obtain a
local client.
However:
1) It requires the user to configure the remote management endpoint simply so it can be
monitored by an agent that is already running co-located in the VM. I already envision the
customer asking "Tell me again why I need to configure the remote management
interface so its javaagent can talk to it?". The customer should actually be able to
disable the remote endpoint entirely (perhaps to lock it down and disallow jboss-cli
access?) and have this agent still work - since it really doesn't need to (or at least
should not have to) talk to the remote endpoint.
2) It requires the agent to be told what this endpoint is - if the user actually bound
the remote endpoint to a non-default IP (not 127.0.0.1) or non-default port (not 9990),
then they have to make sure they also configure the agent to tell it where the remote
endpoint is. Potential place for user-error if they forget to do that. I suppose the agent
could read standalone.xml to find out what the mgmt address/port is but a) what if its not
standalone.xml? Maybe the user started with a different config? What if its not standalone
but deployed in domain mode? Must look at a different config file. b) now the agent has to
know how to parse standalone.xml. This can all be avoided if we just didn't have to go
over the remote endpoint.
3) Seems inefficient to have to go over a remote endpoint (even if its over a loopback
device) when the agent should just be able to make intra-VM Java API calls to do this.
Thanks John,
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.
-Jason