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