This is another topic I have discussed with the JON/RHQ product team at
JBossWorld and via conference call; the notion of a finer grained plugin
model for RHQ.
RHQ and JON were initially designed to support standard, stock containers,
JBoss, Tomcat, etc... These containers have a consistency across the
Enterprise. We can count on every JBoss server to be, well, a JBoss
server no matter where it is deployed. It might have a few
customization's like Java startup options (-Dxxx) and a modified classpath
and few custom MBeans deployed, but bottom line, one JBoss or Tomcat
instance looks pretty much like any other instance.
The result is, from the server perspective, the plugin's are "pushed", or
at the agent side, the agent simply polls the JON server to periodically
pull any new or update plugins. The assumption being, that whatever is
running on the managed node is consistent with what is running everywhere
and all the registered plugins are pulled down to every agent attached to
the JON server instance.
As we have discovered here, JON/RHQ is also a potentially very powerful
tool for managing stand alone Java process as well. It's provisioning
mechanisms and ability to write custom plugins, in particular JMX plugins
makes it very attractive as a management platform for stand alone Java. We
code most of our services as Stand Alone using Spring IOC, thus no need to
host in a container.
The problem here is, the processes can all be very different from one
another, in particular, each set of processes may have a very unique set
of MBeans to manage that set. There is no high level of consistency from
instance to instance other than they are all running in a JVM. Therefore,
the global push (or from the agent perspective, the universal pull of
everything) kind of breaks down. If I have 250 stand alone JVMs, each
with a custom set of MBeans, each with it's own plugin to support those
MBeans, on each agent node, I get my plugin, but also get 249 other
plugins I have no interest in and lord knows what that does to my agent
JVM Heap or resource utilization?
Proposal would be the development of a new kind of plugin, the "private"
plugin, where you drop the plugin into the agent plugin deploy folder, not
the server, the agent reports the plugin to the server, the server exposes
it in inventory discovery, but the plugin only lives at the one agent it
was deployed to. What you end up with is the standard agent plugin that
is today "public", meaning it is blasted out to every agent the server
knows about, but another "private" one that handled and only exists on the
agent it was deployed to.
Not sure how much rework to the agent plugin system this would entail, but
it would make JON a much better tuned product to support large stand alone
Java environments like out.
David Webster
Union Pacific Railroad
Lead Architect-Web Infrastructure
Systems Engineering
Phone: (402) 544-1094 | Email: dawebster(a)up.com
Show replies by date
Wouldn't an alternative to this be to have a way for a plugin to dynamically add new
metrics and resource types similar to a dynamic MBean. In this way we could have a single
generic MBean plugin that could discover all MBeans in a JVM and present the MBeans
properties and operations as metrics and ops respectively. The admin could then choose
which metrics to schedule.
Currently a dev has to create an rhq-plugin.xml and package into a jar to manage a custom
MBean. There must be a better way than that! Many other monitoring tools allow browsing of
the MBean tree and the user can choose what MBeans to monitor.
Just a thought!
Sent from my BlackBerry® wireless device
-----Original Message-----
From: "David A. Webster" <DAWEBSTER(a)UP.COM>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 12:57:25
To: <rhq-devel(a)lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Alternate plugin handling
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
We've been talking about this capability for a few years now :) Its
called "dynamic metadata", we have some design around it and a grad
student actually did some work in this area (its in the nagios branch in
our public repo). Heiko has more info on the work that was done here. It
wasn't ready for merging into master, but the concepts were prototyped
and appeared to work.
Here's the wiki on the design:
http://rhq-project.org/display/RHQ/Design-Dynamic+Metadata
On 05/10/2011 02:55 PM, smillidge(a)c2b2.co.uk wrote:
Wouldn't an alternative to this be to have a way for a plugin to
dynamically add new metrics and resource types similar to a dynamic MBean. In this way we
could have a single generic MBean plugin that could discover all MBeans in a JVM and
present the MBeans properties and operations as metrics and ops respectively. The admin
could then choose which metrics to schedule.
Currently a dev has to create an rhq-plugin.xml and package into a jar to manage a custom
MBean. There must be a better way than that! Many other monitoring tools allow browsing of
the MBean tree and the user can choose what MBeans to monitor.
Just a thought!
Sent from my BlackBerry® wireless device
-----Original Message-----
From: "David A. Webster"<DAWEBSTER(a)UP.COM>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 12:57:25
To:<rhq-devel@lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Alternate plugin handling
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
Cool great minds think alike ;-)
I must take a look at that branch.
This would be a killer feature for a general Java monitoring and management tool. No more
days of tedium mapping MBean properties to xml descriptors.
It would also enable more sophisticated custom plugins to be developed that can
autodiscover metrics in a much richer way.
+1 from me for this in RHQ 5 ;-)
The next thing to do is convince the JBoss 7 team to use RHQ as the admin server and the
rhq agent as the node manager and I'll be very happy! Instead of reinventing the wheel
;-)
Sent from my BlackBerry® wireless device
-----Original Message-----
From: John Mazzitelli <mazz(a)redhat.com>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 15:27:28
To: <rhq-devel(a)lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Re: Alternate plugin handling
We've been talking about this capability for a few years now :) Its
called "dynamic metadata", we have some design around it and a grad
student actually did some work in this area (its in the nagios branch in
our public repo). Heiko has more info on the work that was done here. It
wasn't ready for merging into master, but the concepts were prototyped
and appeared to work.
Here's the wiki on the design:
http://rhq-project.org/display/RHQ/Design-Dynamic+Metadata
On 05/10/2011 02:55 PM, smillidge(a)c2b2.co.uk wrote:
Wouldn't an alternative to this be to have a way for a plugin to
dynamically add new metrics and resource types similar to a dynamic MBean. In this way we
could have a single generic MBean plugin that could discover all MBeans in a JVM and
present the MBeans properties and operations as metrics and ops respectively. The admin
could then choose which metrics to schedule.
Currently a dev has to create an rhq-plugin.xml and package into a jar to manage a custom
MBean. There must be a better way than that! Many other monitoring tools allow browsing of
the MBean tree and the user can choose what MBeans to monitor.
Just a thought!
Sent from my BlackBerry® wireless device
-----Original Message-----
From: "David A. Webster"<DAWEBSTER(a)UP.COM>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 12:57:25
To:<rhq-devel@lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Alternate plugin handling
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
The next thing to do is convince the JBoss 7 team to use RHQ as the
admin server and the rhq agent as the node manager and I'll be very happy! Instead of
reinventing the wheel ;-)
That train has left the station. Moot point even trying to argue for it.
Oh well I suppose we can't have everything. Always seemed sensible to me :-(
Sent from my BlackBerry® wireless device
-----Original Message-----
From: John Mazzitelli <mazz(a)redhat.com>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 15:56:23
To: <rhq-devel(a)lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Re: Alternate plugin handling
The next thing to do is convince the JBoss 7 team to use RHQ as the
admin server and the rhq agent as the node manager and I'll be very happy! Instead of
reinventing the wheel ;-)
That train has left the station. Moot point even trying to argue for it.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
Yes, this one approach we plan on pursuing, for custom MBean support. Two
related topics, but not entirely as there are merits to both, a generic,
"dynamic" MBean plugin and the ability to support a "private" plugin.
David Webster
Union Pacific Railroad
Lead Architect-Web Infrastructure
Systems Engineering
Phone: (402) 544-1094 | Email: dawebster(a)up.com
smillidge(a)c2b2.co.uk
Sent by: rhq-devel-bounces(a)lists.fedorahosted.org
05/10/2011 01:56 PM
Please respond to
rhq-devel(a)lists.fedorahosted.org
To
rhq-devel(a)lists.fedorahosted.org
cc
Subject
Re: Alternate plugin handling
Wouldn't an alternative to this be to have a way for a plugin to
dynamically add new metrics and resource types similar to a dynamic MBean.
In this way we could have a single generic MBean plugin that could
discover all MBeans in a JVM and present the MBeans properties and
operations as metrics and ops respectively. The admin could then choose
which metrics to schedule.
Currently a dev has to create an rhq-plugin.xml and package into a jar to
manage a custom MBean. There must be a better way than that! Many other
monitoring tools allow browsing of the MBean tree and the user can choose
what MBeans to monitor.
Just a thought!
Sent from my BlackBerry® wireless device
-----Original Message-----
From: "David A. Webster" <DAWEBSTER(a)UP.COM>
Sender: rhq-devel-bounces(a)lists.fedorahosted.org
Date: Tue, 10 May 2011 12:57:25
To: <rhq-devel(a)lists.fedorahosted.org>
Reply-To: rhq-devel(a)lists.fedorahosted.org
Subject: Alternate plugin handling
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel