9:50 p.m.
On Mar 13, 2017, at 2:08 PM, John Mazzitelli <mazz(a)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?"
Right thats what I was asking.
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.
It’s very common for our users to do this (for example you can even create users which can
only do monitoring operations); so I’ll take it to mean that your understand is that
Hawkular’s prefer the call home approach, which is fair enough. I only ask since the
approach is being revisited again.
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 think thats a totally reasonable approach. The issue in the past was that the lifecycles
didn’t match (I can’t remember the details as to why). If things were to remain as a
subsystem that has an independent lifecycle, in the future it would be installable via the
wildfly provisioning tool (once available). That includes automating adding config blocks
as part of installation. If the lifecycles can match, and there is a reliable
compatibility contract for the protocol, then we could just merge the capability into the
core code.
If you go the agent route though then there is not much we can do to improve the usability
as our tooling isn’t going to be able to resolve the possible conflicts that arrive when
more than one thing wants to own the bootstrap of the server.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat