My previous post explains how you can use the Hibernate plugin to manage your Hibernate applications with Jopr. In reality, the Hibernate plugin is just a customized JMX plugin because, after all, everything you do in relation to monitoring Hibernate is through its Hibernate Statistics MBean.
So this begs the question, what if my own application has its own custom JMX MBeans? Can I use Jopr to manage and monitor those as well?
The answer is a most emphatic yes!.
Out-of-box, you already get the generic JMX plugin. This was designed to be extensible by other plugins. In fact, its where Jopr's JBossAS plugin, Tomcat plugin and Hibernate plugin all get alot of their functionality from! It stands to reason that you can do the exact same thing for your own MBeans as the Jopr development team does for JBossAS, Tomcat and Hibernate. There is even already an example custom JMX plugin Maven module that you can use as a starting point, should you want to write your own custom JMX plugin - see the actual code here which you can copy and customize for your needs. BTW: when I say "custom JMX plugin" - I mean a plugin that can manage your custom JMX MBeans. I do not mean to say this is a customized version of the out-of-box JMX plugin. In other words, the custom JMX plugin is not a replacement for the existing JMX plugin, its merely an extension to it.
Watch the demo I made to see how you can create your own custom JMX plugin for deployment in any RHQ or Jopr Server (btw: RHQ is where the entire plugin framework lives; because it is upstream to Jopr, your RHQ plugins are completely 100% compatible with Jopr as well - I'll continue to use the Jopr name, but suffice it to say, whenever I say "Jopr", you can assume the same holds true for RHQ). The source and binaries used by the demo are available for download, in case you want to try it yourself after watching the demo.
The generic JMX plugin is very flexible in the way you can extend it. That said, there is still plenty more we can probably do to enhance it. Allowing it to generically handle more data types for operation parameters and results and attribute values are just some of the low-hanging fruit in here - if only we had 25 hours in a day. If anyone is interested in getting started contributing to the RHQ project, that would probably be a very good place to start - its easy to understand and the places that need to be enhanced are localized to only one or maybe a couple Java classes. If you are willing to try this out, feel free to ask about this in our freenode chat room at #rhq or send a message to one of our forums.
Subscribe to:
Post Comments (Atom)
Thank you very much for your post.
ReplyDeleteBut why JOPR cannot retrieve the mbean values without creating a new plugin ?
We would like to use JOPR to monitor our J2EE infrastructure, but we get ~hundred of custom mbeans. It's difficult to convince our developpers to declare all mbeans in an XML file.
Is there another solution in a recent version of JOPR ?
We're using the RHQ V 3.0
Best regards.
What you are asking about is what we call "Dynamic Metadata". We have a design page on our wiki that talks about this exact feature. What we mean by "metadata" is information that describes things like: the names of the operations the resource supports, the number and type of parameters to those operations, the operation return values, the names and data types of the metrics they emit, etc. Essentially, everything you see in the RHQ plugin descriptor XML file is metadata describing the management capabilities of the managed resources.
ReplyDeleteWe call it "dynamic" because in some cases, you can determine what this metadata is at runtime, without having to statically code up this information in an XML file. In the case of JMX (as well as with other things, like QMF and some WebService based management APIs), you can simply make an API call to the resource and get this information at runtime even if you didn't know anything about it before you made the call.
We do not currently support this notion of "dynamic metadata". While it may seem trivial to support this (after all, the JConsole that comes with the SUN JDK has this out of box - but of course only for JMX compliant Java apps), it is not so trivial when you consider that one of the main requirements for us is to support managed resources that DON'T SUPPORT dynamic management APIs like JMX. Not only that, but this type information/metadata needs to be available even BEFORE we talk to (or even know about) running instances of managed resources. For example, to auto-discover a JBossAS server instance (and to KNOW its a JBossAS server instance) we have to know alittle about what makes a running process a JBossAS server! We need to know what pieces of data are required to even talk to a JBossAS server instance (aka "plugin configuration").
That said, there is a branch in our git repo that Alexander coded up where he did implement this kind of feature - up on the wiki, he describes some of this work. (he got his Masters degree based on this work). Its a prototype and hasn't been through any rigorous peer review or testing to bring it to GA quality, however, I hear good things about it from Heiko.
Its possible that someone will (or should) take Alexander's work and bring it to completion, eventually merging that feature into master for a future release of RHQ. There is nothing scheduled, but if someone in the community wants to take that job on, please feel free to do so. You can get help from the RHQ team on IRC at #rhq (@freenode) or our rhq-devel mailing list.
(BTW: Jopr has been rolled upstream into the RHQ project - hence why we no longer talk about "Jopr" but instead we now always refer to RHQ even when talking about the original Jopr plugins - see the FAQ for more on that)
Hi,
ReplyDeleteI am using Jon-server-2.4.0, and i trying to write custom jmx plugin for wso2 esb on top of jon jmx plugin. I am able successfully deploy your demo jmx plugin and see results on jon server console. Can you suggest how to access a jmx port service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi which requires credentials admin/admin to connect.
Thanks,
Hareesh, Yakkala.
If you are extending the JMX Server resource itself, and you require username/password, you have to define <plugin-configuration> with username and password properties - look at how the JMX Server resource defines these itself (principal and credentials) to see an example (this is from the jmx plugin descriptor):
ReplyDeleteclick here for the jmx plugin descriptor
If you are injecting a service resource into a top JMX Server resource (that is, your resource is going to be a child of a JMX Server resource), then you just have to set the principal/credentials plugin configuration properties for that parent JMX Server resource (go to the GUI and see the Inventory connection properties for that JMX Server that is in inventory and set the user/password there).
I recommend that you subscribe to the mailing list rhq-devel and post questions on this there, as I'm not sure if I made enough sense for you to understand the above :). The rest of the community can help you out. Here's a link for the mailing list information:
rhq-devel mailing list info