9:03 a.m.
"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.
I'm thinking about writing a Python agent API - something like an Python skeleton or
something where someone can take a the Hawkular Python API and build around it to collect
all metrics without having to do so in a Java VM.
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.
Which is why I think having a Python agent API would be useful. No need to run a
heavyweight Java app like you would with the Hawkular WildFly Agent.
I know someone (Thomas S?) is writing a vert.x agent.
I don't know what other efforts are ongoing to write other agents.
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.
If all or most of your applications are exposing data via Jolokia, no reason why you
can't use the same Hawkular WildFly Agent.
You can configure one individual Hawkular WildFly Agent to collect data from multiple
WildFlys AND multiple Jolokia endpoints (which may or may not be WildFly servers - the
agent don't care - as long as its talking to a Jolokia endpoint that's good enough
for the agent. It would be a Tomcat server or whatever - if its got Jolokia, the Hawkular
WildFly Agent will monitor it.)
Of course, it would be a standalone Java app running along side of all of these ... i.e.
would NOT be running inside of your Tomcat apps... which is your next point...
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.
Yeah, in this case, sounds like you want an embeddable Java agent. Funny - because we had
this in RHQ/JON, but no one cared for it, no one wanted it, no one asked for it :) So we
dropped that a long time ago. When we built the Hawkular Agent, we took that past
experience and said, "why should we write a standalone agent when no one wants it?
Just write a WildFly subsystem and run it directly in WildFly and we get a Java container
with a CLI for free." :-)