Help with Drools JON/RHQ plugin
Edson Tirelli
etirelli at redhat.com
Wed Jul 13 12:41:36 UTC 2011
Hi John,
Thanks for the answers.
> Nice - can you tell me which H2 files you had to restore? Was it just
> one of those .db files or all of them?
Nuking that db file only did not work, so what I did was unzip the rhq distribution into a directory, finish the installation using the web interface as per the documentation, shutdown the server and tar/gz the whole directory. After each test, I just deleted the install directory and untar/gunzip'd the clean install again. Not as efficient, but it works for my tests here.
Regarding the discovery, I think for JMX derived plugins, it would be very nice if it would be possible to define additional criteria for the discovery process by configuration, without having to override the java classes. There might be several java processes running in a given box, but if you are looking for specific MBeans like I am, it would be easier if we could further filter it to show the user only the relevant ones.
Thanks so far,
Edson
---
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.redhat.com
----- Original Message -----
From: "John Mazzitelli" <mazz at redhat.com>
To: rhq-devel at lists.fedorahosted.org
Sent: Tuesday, July 12, 2011 11:29:03 AM
Subject: Re: Help with Drools JON/RHQ plugin
[I'm forwarding this to the rhq-devel mailing list - this is a good tech
discussion that should be made out in the open in the community]
Edson,
> In the end I was able to test the plugin by nuking the installation and re-installing after each change, as you suggested.
Nice - can you tell me which H2 files you had to restore? Was it just
one of those .db files or all of them?
> My questions are:
>
> 1. I would like to change it to make the plugin a top level server instead of running inside the JMX Server. Is it possible? How can I do it?
You can probably do this. In your plugin descriptor, just mimic what the
JMX descriptor has, tweeking as you need. In this case, you would not
need any "<runs-inside>" metadata.
You can probably reuse the JMX server component as well. Or at least
subclass it. Sounds like you want to override the discovery component so
it only detect things that has your MBean in it. So I would investigate
extending the JMX's plugin component "JMXDiscoveryComponent":
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/jmx/src/main/java/org/rhq/plugins/jmx/JMXDiscoveryComponent.java;hb=HEAD
Maybe write your own, or some how reuse the discover method:
org.rhq.plugins.jmx.JMXDiscoveryComponent.discoverResources(ResourceDiscoveryContext)
this method takes the process scan results (see the JMX plugin
<process-scan> for what its looking for in the operating system process
table - essentially it is looking for java executables). Sounds like you
want to do a little extra - you want to find all java VMs that have your
MBean in its platform MBean Server.
> 2. Related to above, I guess, how do I configure auto-discovery? My criteria is: any java process (JVM) that contains a DroolsManagementAgent MBean running should be discovered.
Right. See the JMXDiscoveryComponent class linked above for how you do
the first part. The JMX plugin is configured via <process-scan> metadata
to auto-discover java apps that are running. you'd then have to add your
own discovery code to look for whatever specific info you want to
further refine those results. In your case, you want to attach to that
java VM, peek in its platform MBeanServer and see if your MBean exists.
If it does, you'd return data for your discovered server. Otherwise,
you'd return nothing to indicate you found nothing.
> 3. I was able to configure all the metrics I want to collect, but how to I collect configuration data? I.e., things that were configured in the application and that rarely change, but that I want to keep track of and store as an historical audit trail in JON/RHQ. E.g. "Event Processin Mode = stream", "Assert Behavior = identity", "Max threads = 10".
Sounds like you want what we call a metric "trait". A trait is like a
metric but it can be any string (not just a double) and we track changes
to them over time (under the Measuerment tab, there is a subtab, I think
called "Traits"). It is assumed traits can change, but they change
rarely (less so then dynamic measurement data like "number of DB
connections" or "CPU utilization" or "free memory"). There are plenty of
examples of trait definitions in many of our plugins. See the agent
plugin or the jboss-as plugin or even the JMX plugin itself - look for
<metric> definitions that have dataType="Trait" attributes. One example
in the JMX plugin descriptor is:
<metric displayName="Heap Initial Size"
property="{HeapMemoryUsage.init}"
displayType="summary"
dataType="trait"
description="The amount of heap that the Java virtual
machine initially requests from the operating system"
units="bytes"/>
More information about the rhq-devel
mailing list