Before I answer the Karaf-related questions, just note that JON plugins are not compatible with Hawkular WildFly Agent - so there is no way to get JON plugins to run in the agent, even if the agent can run in a Karaf container. The Hawkular WildFly Agent can be useful if you have WildFly subsystem extensions that you want to monitor and they emit all the data you want to monitor. For example, we can monitor Undertow (things like number of web requests processed) because it exposes everything via the WildFly management model/DMR API (e.g. anything you can get out of the JBoss CLI, the Agent can monitor). The agent also has the ability to monitor values from JMX MBean attributes if you expose things that way (we do not today support JMX operations, but that should be doable - we support DMR operations, I suspect adding JMX operation support will be done in a similar way). But the main point of the Hawkular WildFly Agent is to monitor WildFly subsystems over the WildFly management model API. JMX (and Prometheus) endpoints were just a thrown-in feature set because it was thought those use-cases might be required in the future. If, however, you need more functionality than that, it would probably be best to write your own agent (what Hawkular calls a "feed" - I tend to use the words "feed" and "agent" interchangeably) and you just send the data you want using your own code over the Hawkular REST APIs - you can write stuff to Hawkular Inventory and Hawkular Metrics using their REST APIs from your own feed, rather than trying to plug it into the Hawkular WildFly Agent. In other words, it works differently than JON did - in JON, you HAD TO plug into the agent to get your data into the JON Server - but Hawkular provides a way for people to write their own agents ("feeds") - you aren't limited to having to plug into any other agent infrastructure (i.e. you aren't forced to plug into the Hawkular WildFly Agent if it doesn't make sense - you can write your own and just send your own data and inventory to Hawkular Server via REST). OK, that said, your questions: It is nothing more than a normal subsystem extension like any other subsystem in EAP/WildFly (like the messaging subsystem, or undertow, or the transaction subsystem). You will see an agent specific <subsystem> element in standalone.xml where you configure it. So when you start EAP, the agent subsystem and its service starts like any other. Since the agent is nothing more than a standard ol' WildFly subsystem extension, all of its startup and configuration is done via the WildFly extension API (e.g. it gets its config from standalone.xml, it persists its config there, it gets its security details from standalone.xml's security domains, the agent's runtime service is a WildFly Extension, etc. etc. It is heavily dependent upon the WildFly API). To answer the question directly, see the "extension" Java package - most but not all of the WildFly specific code is in there): https://github.com/hawkular/hawkular-agent/tree/master/hawkular-wildfly-a... The WildFly Extension service class (the main agent class that contains the startup code for the agent) is here: https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a... I honestly have no idea what is involved in porting this over to run in another container. As I said earlier, Hawkular is designed to have multiple kinds of agents/feeds talking to it, so we didn't try to implement the agent to be portable to run in other containers (this is also why we call it the Hawkular *WildFly* Agent - it runs inside WildFly and monitors it). It was just assumed a new kind of feed ("agent") would be implemented for any new container we want to manage. For example, such a thing is happening with vert.x - there is a vert.x agent that was prototyped by Thomas Segismont. I really don't know. :) We did not give OSGI packaging any thought. As I say, the thinking originally was if you want to have an agent running in an OSGI container, we just assumed someone would write a Hawkular feed for that. Quantify "a lot". :) Here's the WildFly module.xml which shows the modules the agent subsystem asks WildFly to pull in as its dependencies: https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a... --John Mazz ----- Original Message ----- > Hi, > > I've been talking to Heiko about getting the Hawkular agent to work on Karaf > for the Fuse team. > > Currently there's number of JON plugins for Fuse that collect metrics and > expose operations through JMX for the components that are being monitored > (Karaf, Camel, SwitchYard, CXF, ActiveMQ, Fabric, etc). There's a few > components that are also shipped on top of EAP (Camel, SwitchYard) that > would need to be monitored as well, but I think I'd like to get the Karaf > portion finished first. > > I'd like to create OSGI bundles for the parts of the hawkular-agent that we > need, maybe create a features file for installing the agent, and then figure > out a way to get the agent started so we could collect some data. Could > someone help point me in the right direction? I've got a bunch of questions > .. > > Would it be beneficial to OSGI-enable hawkular-agent by turning the JARs it > creates into OSGI bundles? > > Thanks for your help in advance - look forward to working with you on this. > > Tom > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev >

On Thu, Aug 11, 2016 at 7:47 AM, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: +1, this will become important after we have wildfly under our belts.