I think we should limit ourselves to the Wildfly/EAP agent that we're
already working on, as EAP hosted app monitoring/mgmt is our bread and
butter. Past that we should provide infrastructure to help others hook
into the MW MIQ support. So basically, what we're doing so far seems
good to me. As attractive as it is to have one agent allow many feeds to
"plugin" we need to be wary of trying to have a single agent/feed do too
much, or we'll end up with the RHQ scenario of an agent that is too
heavy. And from a dev standpoint, like miq, we should in general leave
the feeds to be impl'd by those that want (or are required) to supply
data/inventory, in the way that they see fit. That community effort
will validate and improve our infrastructure, and help us maintain focus
on the core.
On 3/24/2016 5:27 AM, Thomas Segismont wrote:
Hi Matt,
Answers inline
2016-03-23 14:47 GMT+01:00 Matt Wringe <mwringe(a)redhat.com
<mailto:mwringe@redhat.com>>:
----- Original Message -----
> From: "John Mazzitelli" <mazz(a)redhat.com
<mailto:mazz@redhat.com>>
> To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@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"
Here is the list of reporters I know we're working on:
- hawkular-agent
- vertx-hawkular-metrics
- heapster plugin
- ptrans
- all language clients (hawkular-go, hawkular-ruby, ... etc)
There is a JIRA in Metrics for a Node plugin.
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.
This is not true. Many development platforms have plugins to report
data over the Graphite text protocol. The goal of the ptrans project
is to allow reuse of existing monitoring infrastructure by forwarding
data sent over widely used monitoring network protocols to the Metrics
HTTP interface.
It would be awesome to be able to provide more agents that would
be simple to setup and configure for different systems.
We already have a few projects (see above) but obviously there's a
limit in the number of reporters the core team can maintain. ptrans
lets us benefit from a wide ecosystem of independent metric collectors.
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.
Correct me if I'm wrong, but Jolokia is not a collection system. It is
an HTTP adaptor around JMX. I would argue that a great majority of
Java applications either:
- collect monitoring data with home-built systems and publish to JMX
- collect monitoring data with Dropwizard Metrics
In the former case, user can combine jmxtrans(or embedded jmxtrans)
with ptrans. In the latter, Dropwizard can be configured to send data
over the Graphite protocol to ptrans.
>
> 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 :)
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Thomas Segismont
JBoss ON Engineering Team
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev