Help with Drools JON/RHQ plugin
John Mazzitelli
mazz at redhat.com
Tue Jul 12 15:29:03 UTC 2011
[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