"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.

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.

Hi, You mean something like this? https://github.com/burmanm/gather_agent (Python Agent writing to RHQ Metrics with pluggable inputs). I actually used this code in one IoT platform to read statistics from one device and write them to one server. There's lots of similar projects though which are more full featured (like Diamond). These are very easy to extend, for example Golang is terrible in that sense. - Micke ----- Original Message ----- From: "John Mazzitelli" <mazz(a)redhat.com&gt; To: "Matt Wringe" <mwringe(a)redhat.com&gt;, "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Wednesday, March 23, 2016 4:03:55 PM Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent > "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." :-) _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

----- Original Message ----- > From: "John Mazzitelli" <mazz(a)redhat.com&gt; > To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org&gt; > 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 :) _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "Jay Shaughnessy" <jshaughn(a)redhat.com&gt; To: hawkular-dev(a)lists.jboss.org Sent: Monday, March 28, 2016 10:59:05 AM Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent 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 > : ----- 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" 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 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 _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> On Mar 30, 2016, at 10:23 AM, Matt Wringe <mwringe(a)redhat.com > <mailto:mwringe@redhat.com>> wrote: > > ----- Original Message ----- >> From: "Jay Shaughnessy" <jshaughn(a)redhat.com >> <mailto:jshaughn@redhat.com>> >> To:hawkular-dev@lists.jboss.org <mailto:hawkular-dev@lists.jboss.org> >> Sent: Monday, March 28, 2016 10:59:05 AM >> Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom >> java agent >> >> >> 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 > > Except this assumption is not necessarily correct. Hawkular, at least > Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. > > We are using Hawkular-Metrics in OpenShift > (https://github.com/openshift/origin-metrics) and there are other > potential integration points that are being looking into. If we only > want to handle the Wildfly/EAP case, then we really need to take a > good look and determine if these other integrations make sense or > not. Otherwise we should really start to look beyond just Wildfly/EAP > so that these integration can be handled better. We are actively working on other integration efforts, so we definitely need to look beyond WildFly/EAP.

On Mar 30, 2016, at 12:00 PM, Jay Shaughnessy <jshaughn(a)redhat.com&gt; wrote: On 3/30/2016 10:50 AM, John Sanda wrote: > >> On Mar 30, 2016, at 10:23 AM, Matt Wringe < <mailto:mwringe@redhat.com>mwringe@redhat.com <mailto:mwringe@redhat.com>> wrote: >> >> ----- Original Message ----- >>> From: "Jay Shaughnessy" < <mailto:jshaughn@redhat.com>jshaughn@redhat.com <mailto:jshaughn@redhat.com>> >>> To: <mailto:hawkular-dev@lists.jboss.org>hawkular-dev@lists.jboss.org <mailto:hawkular-dev@lists.jboss.org> >>> Sent: Monday, March 28, 2016 10:59:05 AM >>> Subject: Re: [Hawkular-dev] using hawkular wildfly agent as a custom java agent >>> >>> >>> 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 >> >> Except this assumption is not necessarily correct. Hawkular, at least Hawkular-Metrics, is not only being used just for Wildfly/EAP monitoring. >> >> We are using Hawkular-Metrics in OpenShift ( <https://github.com/openshift/origin-metrics>https://github.com/openshi... <https://github.com/openshift/origin-metrics>) and there are other potential integration points that are being looking into. If we only want to handle the Wildfly/EAP case, then we really need to take a good look and determine if these other integrations make sense or not. Otherwise we should really start to look beyond just Wildfly/EAP so that these integration can be handled better. > > We are actively working on other integration efforts, so we definitely need to look beyond WildFly/EAP. What I'm cautioning against is trying to build all feeds ourselves. In RHQ we used a lot of manpower to build and maintain a lot of agent plugins. There is goodness in providing interfaces and infrastructure that make integrating as easy as possible, and then trying to avoid doing all of the integration work as well. This is the model that is working for miq. We have two things going on here, one is the team charter to provide middleware mgmt via manageiq, using hawkular as the provider. We'll need agents/feeds to hook up to hawkular to report inventory and metrics which then make their way to miq. We've got the WFly/EAP agent and that seems like the likely place to invest the most for MW mgmt. Then we've got H Metrics, which to some degree has a life of its own. Certainly the integrations with metrics are important and as I said before, I think we're already doing the right things, and just like hawkular overall, making integration easy is our biggest win because it will allow others to build their own feeds. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev <https://lists.jboss.org/mailman/listinfo/hawkular-dev>

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.