8:47 a.m.
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, March 23, 2016 9:28:03 AM
Subject: [Hawkular-dev] using hawkular wildfly agent as a custom java agent
This is for Matt, but figured post here for public consumption.
The question was asked yesterday, "Can we use the Hawkular WildFly Agent to
monitor other things other than WildFly?"
My question should have been more:
"Do we have plans to have other Agents than just the WildFly one"
For me, being able to gather metrics from a WildFly server is really awesome, but when I
am dealing with multiple systems I am going to want to be able to manage all those metrics
in the same place.
Currently its possible for a user to custom write their own component to interface with
the Hawkular Metrics server, but in this case it seems like we are asking all our users to
continuously write their own agents. Which is not very user friendly and causes a bunch of
duplication of effort.
It would be awesome to be able to provide more agents that would be simple to setup and
configure for different systems.
If I am mostly running a bunch of different Java application, including WildFly, its going
to be really tough to convince me to use Hawkular if its only going to monitor a subset of
my systems. I would be much better off using Jolokia or something similar which can
monitor all or most of my applications.
I gave one answer, but forgot there is a second alternative.
====
The first answer that I gave is that you can use the Hawkular Wildfly Agent
to collect JMX data via Jolokia interface. There is an integration in the
agent that lets you define your resource and metric metadata and your
JMX/Jolokia servers. As an example, see here:
https://github.com/hawkular/hawkular-agent/blob/b52529823ca3c54d0b8b4aa56...
You define where your JMX servers are via the <remote-jmx> managed server
like this:
<remote-jmx name="Remote JMX" enabled="false"
resourceTypeSets="MainJMX,MemoryPoolJMX"
url="http://localhost:8080/jolokia-war"/>
OK, that's the JMX integration. Maybe useful, maybe not. But I mention it
just in case.
Having the agent running in an EAP instance be able to monitor other jolokia end points is
cool. But I don't really understand why this isn't a more standalone java
application. I would think it would be much more useful to be able to have a standalone
java agent which could run on the same system which is exposing the jolokia endpoint. Say
I am only running Tomcat servers and I don't want to run Wildfly just to be able to
gather the metrics from Tomcat.
====
The second alternative I forgot to mention was the ability for any component
running in WildFly to obtain a Hawkular Agent proxy via JNDI and use that
proxy that store inventory and metrics into the Hawkular Server.
There is an example WAR module in the agent git repo that demonstrates how to
obtain the proxy via JNDI and how to store inventory and metrics - see here:
https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-a...
This is just a simple WAR with a servlet. But it shows how a component can
get the agent proxy via JNDI here:
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
Here's code that shows the servlet doing things like sending metrics, avail,
and creating resources:
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
No one is using this yet. So there may be issues I am not aware of, but we
have integration tests that show this working.
This was put together with the anticipation of someone asking for this
capability - that is, "can the agent be used to collect metrics for other
things other than WildFly". Essentially, this just gives you a skeleton Java
agent that you can extend to collect your own metrics and inventory. So you
can write a WAR or EAR, deploy it in any WildFly that has an agent
subsystem, and your EAR/WAR can be used as an "agent" for your custom stuff.
Again, maybe useful, maybe not. But I mention it just in case.
Being able to expose custom metrics is extremely important. Awesome that we have the
ability to do that with the agent currently :)