11:08 a.m.
Right now, the Hawkular WildFly Agent runs as a WildFly subsystem extension - which means
it must run in EAP.
To avoid this requirement, I refactored the agent code [1] so it can be run using a
standard VM javaagent (using the VM argument -javaagent).
This means the agent need not run as a subsystem extension, in fact, it can run in any VM
(non-EAP/WildFly based). Just pass in the -javaagent command line argument to your VM and
you got an agent. You have a Karaf container in a JVM exposing metrics via JMX? You can
use this. You got a vert.x server in a JVM exposing metrics via JMX? You can use this.
This new agent's config file is a single YAML file that mimics virtually the same
settings as you see today in the agent's <subsystem> XML in standalone.xml.
Like the EAP-based agent, this new agent can still:
* collect DMR metrics and inventory from any EAP 6.4, EAP 7.x, or WildFly 10+ servers -
local or remote.
* collect JMX metrics and inventory from any remote Jolokia endpoint or local JMX
MBeanServer
* receive websocket messages from a Hawkular Server (if running in full Hawkular mode)
* run in metrics-only mode where it only stores data to Hawkular-Metrics and does not
connect via websocket to the server nor stores inventory to H-Inventory
* Talk to the Hawkular Server and remote DMR/JMX endpoints via SSL/https using defined
security-realms/keystores
Unlike the EAP-based agent, this new agent:
* does NOT have a CLI (jboss-cli.sh is the EAP-based agent's CLI)
* does NOT have a built-in configuration persistent mechanicm (EAP-based agents can
persist their config changes to standalone.xml when those changes are made via the WildFly
management interface - because the javaagent is completely independent, it has nothing
like this for its YAML config).
* does NOT integrate with the lifecycle of any EAP/WildFly running in the same VM (in
other words, if you ask to "reload" the EAP server, the javaagent knows nothing
about that and won't also itself reload. Remember, this javaagent is now completely
independent of any co-located EAP/WildFly server).
In addition, if your JVM is installed in OpenShift, you can get the nice option of putting
the javaagent's YAML config in a config map and mount it so your javaagent can access
it. This means you can edit your javaagent YAML directly in the OpenShift UI :)
I still need to see how well this supports the disabling/enabling of metrics on the fly
from the websocket commands (e.g. I will need to add the ability to change the YAML config
to persist the settings, that is not done yet - the EAP-based agent got this support for
free - its config changes go into standalone.xml).
Other than persisting changes to the YAML file, I believe this javaagent will work
essentially the same as the current agent (indeed, the core agent engine is identical -
its the same code). Just have to make sure the websocket commands can work considering
there is a YAML config backing the settings and not standalone.xml.
I need people's feedback on this. Thoughts? If you want to try it, you can build it
from my PR right now using the README [2] and the instructions [3].
--John Mazz
[1] https://github.com/hawkular/hawkular-agent/pull/302
[2]
https://github.com/jmazzitelli/hawkular-agent/blob/refactor-core/hawkular...
[3] Instructions to build using the PR and test it by collecting EAP metrics:
1) Build it:
$ git clone git@github.com:hawkular/hawkular-agent.git
$ cd hawkular-agent
$ git checkout -b jmazzitelli-refactor-core master
$ git pull https://github.com/jmazzitelli/hawkular-agent.git refactor-core
$ mvn clean install
2) Install it - assuming you have a base EAP 6.4 or 7.x or WildFly 10+ installed at
<eap.dir>
2a) Change this line in <eap.dir>/bin/standalone.conf:
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
to this:
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager"
2b) Inside that same <eap.dir>/bin/standalone.conf you add this line in the
appropriate place (you know where, just under where it sets JAVA_OPTS):
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager
-javaagent:$JBOSS_HOME/bin/hawkular-javaagent-*.jar=config=$JBOSS_HOME/standalone/configuration/real-config*.yaml,delay=10"
2c) Copy the binary/config files you built to that EAP / WildFly install:
cp
hawkular-agent/hawkular-javaagent/target/hawkular-javaagent-*-jar-with-dependencies.jar
<eap.dir>/bin
if EAP 7.x/WildFly 10+:
cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config.yaml
<eap.dir>/standalone/configuration
if EAP 6.4:
cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config-eap6.yaml
<eap.dir>/standalone/configuration
1:09 p.m.
New subject: agent running as a VM javaagent - non-EAP based solution
I still need to see how well this supports the disabling/enabling of
metrics
on the fly from the websocket commands (e.g. I will need to add the ability
to change the YAML config to persist the settings, that is not done yet -
the EAP-based agent got this support for free - its config changes go into
standalone.xml).
Just checked - the cmdgw command to update collection intervals won't work because it
is assuming the agent is always DMR-accessible which it no longer is. This won't be
hard to refactor that command to get it to work, but for now, this will not work when
running as javaagent - still works as normal with the subsystem agent.
2:04 p.m.
New subject: agent running as a VM javaagent - non-EAP based solution
> I still need to see how well this supports the
disabling/enabling of
> metrics on the fly from the websocket commands (e.g. I will need to add the ability
> to change the YAML config to persist the settings, that is not done yet -
> the EAP-based agent got this support for free - its config changes go into
> standalone.xml).
Just checked - the cmdgw command to update collection intervals won't work
because it is assuming the agent is always DMR-accessible which it no longer
is. This won't be hard to refactor that command to get it to work, but for
now, this will not work when running as javaagent - still works as normal
with the subsystem agent.
This is fixed now. Updating collection intervals and enabling/disabling metrics should now
work even when deployed at a javaagent.
At this point in time, I'm hard-pressed to think of a feature the WildFly Agent has
that the javaagent does not (short of the obvious "there is no CLI" and
"there is no installer" - but there is really nothing to install so that's
moot). If anyone plays with this (especially with CFME on the front end) let me know what
you find.
I'm sure I'm forgetting something, but right now, it looks like it is working
really well. I just have to build in itests for it (right now, all the WildFly Agent
itests still exist and pass, so I know I didn't break that).
3:50 p.m.
I've been testing this out for the past day, and this is fantastic. I
have it attached to Karaf pushing metrics to Hawkular and it looks like
it's working very well. I'm trying it on SpringBoot next, but if it works
on Karaf, I'm not sure why it wouldn't work on SpringBoot.
Things I'd like to contribute back possibly if they sound interesting :
- delay (the delay X seconds is useful, but I'd like to have a way of
polling to see if the MBeans are registered yet, and then starting the
agent)
- size of javaagent : it looks like the JAR is about 24MB, I might look
into seeing if there's a way of slimming that down. For our purposes,
we're only really interested in JMX support, so I'm going to see if I can
build a profile that filters out the DMR stuff and their dependencies for a
smaller fat JAR
- optional log integration with Karaf?
On Thu, Mar 9, 2017 at 3:04 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
> > I still need to see how well this supports the
disabling/enabling of
> > metrics on the fly from the websocket commands (e.g. I will need to
add the ability
> > to change the YAML config to persist the settings, that is not done
yet -
> > the EAP-based agent got this support for free - its config changes go
into
> > standalone.xml).
>
> Just checked - the cmdgw command to update collection intervals won't
work
> because it is assuming the agent is always DMR-accessible which it no
longer
> is. This won't be hard to refactor that command to get it to work, but
for
> now, this will not work when running as javaagent - still works as normal
> with the subsystem agent.
This is fixed now. Updating collection intervals and enabling/disabling
metrics should now work even when deployed at a javaagent.
At this point in time, I'm hard-pressed to think of a feature the WildFly
Agent has that the javaagent does not (short of the obvious "there is no
CLI" and "there is no installer" - but there is really nothing to install
so that's moot). If anyone plays with this (especially with CFME on the
front end) let me know what you find.
I'm sure I'm forgetting something, but right now, it looks like it is
working really well. I just have to build in itests for it (right now, all
the WildFly Agent itests still exist and pass, so I know I didn't break
that).
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:48 a.m.
On 9 Mar 2017, at 22:50, Thomas Cunningham wrote:
I've been testing this out for the past day, and this is
fantastic.
I have it attached to Karaf pushing metrics to Hawkular and it looks
like
it's working very well. I'm trying it on SpringBoot next,
Awesome
Things I'd like to contribute back possibly if they sound
interesting
:
Yes. We need to move quickly, so contributions are very
welcome.
build a profile that filters out the DMR stuff and their dependencies
for a smaller fat JAR
This is certainly a good idea and we should perhaps
even try to see if that would work for WildFly.
But if WildFly needs DMR, then we also need to consider
the creation process of container images, as one
can't just put a Rhel-atomic+Java+Hawkular-javvagent-jmx
image out there and use it with WildFly, so there would
be an need for two images, which complicates
things.
6:57 a.m.
Try the turing test, replace it in hServices and see what happens.
On 3/9/2017 3:04 PM, John Mazzitelli wrote:
>> I still need to see how well this supports the
disabling/enabling of
>> metrics on the fly from the websocket commands (e.g. I will need to add the
ability
>> to change the YAML config to persist the settings, that is not done yet -
>> the EAP-based agent got this support for free - its config changes go into
>> standalone.xml).
> Just checked - the cmdgw command to update collection intervals won't work
> because it is assuming the agent is always DMR-accessible which it no longer
> is. This won't be hard to refactor that command to get it to work, but for
> now, this will not work when running as javaagent - still works as normal
> with the subsystem agent.
This is fixed now. Updating collection intervals and enabling/disabling metrics should
now work even when deployed at a javaagent.
At this point in time, I'm hard-pressed to think of a feature the WildFly Agent has
that the javaagent does not (short of the obvious "there is no CLI" and
"there is no installer" - but there is really nothing to install so that's
moot). If anyone plays with this (especially with CFME on the front end) let me know what
you find.
I'm sure I'm forgetting something, but right now, it looks like it is working
really well. I just have to build in itests for it (right now, all the WildFly Agent
itests still exist and pass, so I know I didn't break that).
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:13 a.m.
On 8 Mar 2017, at 18:08, John Mazzitelli wrote:
In addition, if your JVM is installed in OpenShift, you can get the
nice option of putting the javaagent's YAML config in a config map and
mount it so your javaagent can access it.
I still need to see how well this supports the disabling/enabling of
metrics on the fly from the websocket commands (e.g. I will need to
add the ability to change the YAML config to persist the settings,
that is not done yet - the EAP-based agent got this support for free -
its config changes go into standalone.xml).
This needs to differentiate openshift/non-openshift, so the
immutable+in-container flags would still be in action.
I think in OpenShift you could listen on the edit config map
event like Hosa does and then trigger a config reload.
There is https://github.com/fabric8io/kubernetes-client
that should already have the necessary functionality.
4:34 a.m.
Adding Thomas, as this could be interesting for Fuse on Karaf if we proceed
with this javaagent.
On Wed, Mar 8, 2017 at 6:08 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
Right now, the Hawkular WildFly Agent runs as a WildFly subsystem
extension - which means it must run in EAP.
To avoid this requirement, I refactored the agent code [1] so it can be
run using a standard VM javaagent (using the VM argument -javaagent).
This means the agent need not run as a subsystem extension, in fact, it
can run in any VM (non-EAP/WildFly based). Just pass in the -javaagent
command line argument to your VM and you got an agent. You have a Karaf
container in a JVM exposing metrics via JMX? You can use this. You got a
vert.x server in a JVM exposing metrics via JMX? You can use this.
This new agent's config file is a single YAML file that mimics virtually
the same settings as you see today in the agent's <subsystem> XML in
standalone.xml.
Like the EAP-based agent, this new agent can still:
* collect DMR metrics and inventory from any EAP 6.4, EAP 7.x, or WildFly
10+ servers - local or remote.
* collect JMX metrics and inventory from any remote Jolokia endpoint or
local JMX MBeanServer
* receive websocket messages from a Hawkular Server (if running in full
Hawkular mode)
* run in metrics-only mode where it only stores data to Hawkular-Metrics
and does not connect via websocket to the server nor stores inventory to
H-Inventory
* Talk to the Hawkular Server and remote DMR/JMX endpoints via SSL/https
using defined security-realms/keystores
Unlike the EAP-based agent, this new agent:
* does NOT have a CLI (jboss-cli.sh is the EAP-based agent's CLI)
* does NOT have a built-in configuration persistent mechanicm (EAP-based
agents can persist their config changes to standalone.xml when those
changes are made via the WildFly management interface - because the
javaagent is completely independent, it has nothing like this for its YAML
config).
* does NOT integrate with the lifecycle of any EAP/WildFly running in the
same VM (in other words, if you ask to "reload" the EAP server, the
javaagent knows nothing about that and won't also itself reload. Remember,
this javaagent is now completely independent of any co-located EAP/WildFly
server).
In addition, if your JVM is installed in OpenShift, you can get the nice
option of putting the javaagent's YAML config in a config map and mount it
so your javaagent can access it. This means you can edit your javaagent
YAML directly in the OpenShift UI :)
I still need to see how well this supports the disabling/enabling of
metrics on the fly from the websocket commands (e.g. I will need to add the
ability to change the YAML config to persist the settings, that is not done
yet - the EAP-based agent got this support for free - its config changes go
into standalone.xml).
Other than persisting changes to the YAML file, I believe this javaagent
will work essentially the same as the current agent (indeed, the core agent
engine is identical - its the same code). Just have to make sure the
websocket commands can work considering there is a YAML config backing the
settings and not standalone.xml.
I need people's feedback on this. Thoughts? If you want to try it, you can
build it from my PR right now using the README [2] and the instructions [3].
--John Mazz
[1] https://github.com/hawkular/hawkular-agent/pull/302
[2] https://github.com/jmazzitelli/hawkular-agent/
blob/refactor-core/hawkular-javaagent/README.adoc
[3] Instructions to build using the PR and test it by collecting EAP
metrics:
1) Build it:
$ git clone git@github.com:hawkular/hawkular-agent.git
$ cd hawkular-agent
$ git checkout -b jmazzitelli-refactor-core master
$ git pull https://github.com/jmazzitelli/hawkular-agent.git
refactor-core
$ mvn clean install
2) Install it - assuming you have a base EAP 6.4 or 7.x or WildFly 10+
installed at <eap.dir>
2a) Change this line in <eap.dir>/bin/standalone.conf:
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
to this:
JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager"
2b) Inside that same <eap.dir>/bin/standalone.conf you add this line in the
appropriate place (you know where, just under where it sets JAVA_OPTS):
JAVA_OPTS="$JAVA_OPTS
-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-javaagent:$JBOSS_HOME/bin/hawkular-javaagent-*.jar=
config=$JBOSS_HOME/standalone/configuration/real-config*.yaml,delay=10"
2c) Copy the binary/config files you built to that EAP / WildFly install:
cp hawkular-agent/hawkular-javaagent/target/hawkular-
javaagent-*-jar-with-dependencies.jar <eap.dir>/bin
if EAP 7.x/WildFly 10+:
cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config.yaml
<eap.dir>/standalone/configuration
if EAP 6.4:
cp hawkular-agent/hawkular-javaagent/src/test/resources/real-config-eap6.yaml
<eap.dir>/standalone/configuration
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2901
days inactive
2903
days old
8 comments
5 participants
participants (5)
-
Heiko W.Rupp -
Jay Shaughnessy -
John Mazzitelli -
Thomas Cunningham -
Thomas Heute