SnmpAgent startup sequence

[dimitris]

(I moved this here from the Developer's list, Dimitris Andreadis)

When SnmpAgent is loaded in JBoss it read 3 files (managers.xml,
notifications.xml and mbeans.xml).
However, at that moment our application services haven't been
loaded by JBoss yet. As a result, I cannot specify these
services in mbeans.xml, because the services don't
exist yet.
How do I get around this chicken and egg problem? SnmpAgent
has to be first because it has to send a trap when our services
are started, but our services have to be there before SnmpAgent
because otherwise they aren't recognized by SnmpAgent when
mbeans.xml is parsed.
Or is there a way of registering a service with an already
running SnmpAgent when it is loaded?

Guy Thomas

[dimitris]

Currently SnmpAgent subscribes/unsubscribes for notifications during start()/stop() and it requires that the target mbeans are present.

The closest you can get is start SnmpAgent first and use a "depends" clause in his mbean descriptor, so that it starts immediatelly after the target mbeans. This will allow you to produce traps AFTER those mbeans are started. However, if you want to map the "starting/started" notification from those mbeans to traps, this is obviously not good.

The good news is that I plan to replace the SnmpAgent subscription mechanism with my new org.jboss.system.ListenerServiceMBeanSupport class, which solves the chicken/egg problem by monitoring for new mbeans and registering for events dynamically, AFTER start.

How much do you need this? I might make it for JBoss 3.2.4

Regards
/Dimitris

[paul-henri-spaak]

Hallo Dimitris,

We need this functionality rather urgently (as usual).

To get around the problem I tried to add the snmp agent as a listener in the postRegister method of ImportService (the broadcaster class), as shown below.

In server.log I get a message that there is no mapping for "jmx.attribute.change"???
Have I implicitly tried to change a value in the snmp agent?

Best regards,

Guy

-------------------------

public class ImportService extends ServiceMBeanSupport
implements ImportServiceMBean, NotificationBroadcaster, MBeanRegistration
{
...
public void postRegister(Boolean registrationDone) {
mBeanServer = (MBeanServer)MBeanServerFactory.
findMBeanServer(null).iterator().next();
try {
mBeanName = new ObjectName("jboss.scripts:service=OpslagImport");
mSnmpAgentName =
new ObjectName("jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor");

// check if SnmpAgent exists
mObjectSet = mBeanServer.queryMBeans
(new ObjectName("jboss.jmx:name=SnmpAgent,service=snmp,type=adaptor"),
null);
sLogger.info
("AGENT OBJECT NAME (derived from ObjectInstance): " +
((ObjectInstance)mObjectSet.iterator().next()).getObjectName());

mBeanServer.addNotificationListener
(mBeanName,mSnmpAgentName,null,null);
} catch (InstanceNotFoundException infe) {
infe.printStackTrace();
} catch (MalformedObjectNameException mone) {
mone.printStackTrace();
}
}
...

protected void startService ()
{
...
sendNotification
(new Notification(IMPORTSERVICE_REGISTRATION_NOTIFICATION, // String
this,
getNextNotificationSequenceNumber(),
System.currentTimeMillis(),
"ImportService started"));
}
}

[dimitris]

This is a good way to get around them problem, until the next JBoss version!

What happens is the SnmpAgent receives the Notification but doesn't know how to map it to SNMP. You need to make an entry in notifications.xml, for example


<notification-type>jmx.attribute.change</notification-type>
0
0
1.2.3.4.5.6.7
<var-bind-list wrapper-class="org.jboss.jmx.adaptor.snmp.agent.NotificationWrapperSupport">
<var-bind>
a:startTime
1.2.3.4.5.6.7.9
</var-bind>
<var-bind>
a:trapCount
1.2.3.4.5.6.7.6
</var-bind>
</var-bind-list>


The wrapper class is the one used to extract information from the emitted notification. The default one shown above understands the following tags:

Info coming from Notification baseclass:

Tag Explanation
n:message The JMX Notification message attribute
n:sequenceNumber The JMX Notification sequence number attribute
n:timeStamp The JMX Notification time stamp attribute
n:type The JMX Notification type attribute
n:all The JMX Notification in stringified form
n:class The JMX Notification class

Info coming from AgentServer itself
a:startTime The Agent instantiation time in stringified form
a:uptime The Agent uptime in msec
a:trapCount The Agent trap count attribute

Also if the Notification payload is a hashmap, we can extract attribute values as follows:

u:xxx it will use xxx as the key to extract the value.

You can define your own extractor class, but then it gets complicated...

Experiment with this and let me know

Cheers
/Dimitris

[paul-henri-spaak]

Dimitri,

"jmx.attribute.changed" is not the notification type I want to be handled
by the snmp agent.
In the sendNotifcation call in my code I specified
IMPORTSERVICE_REGISTRATION_NOTIFICATION as the notification type and
I specified a mapping for it in the notifications.xml file, but it wasn't handled.

When I added a mapping for jmx.attribute.changed I got the following
trap information in /var/log/syslog (NOT containing my own message "ImportService started"):

Feb 26 11:31:42 epsilon snmptrapd[29500]: 10.0.0.190: Warm Start Trap (0) Uptime: 0:22:36.88, .iso.2.3.4.5.6.7.9 = "Thu Feb 26 11:29:26 CET 2\004", .iso.2.3.4.5.6.7.6 = Counter64: 380, .iso.2.3.4.5.6.7.14 = "javax.management.AttributeChangeNotification", .iso.2.3.4.5.6.7.19 = "javax\.management.AttributeChangeNotification: source=jboss.scripts:service=OpslagImport seq-no=1 time=1077791502107 message=ImportService starting\ attributeName=State attributeType=java.lang.Integer oldValue=0 newValue=2 notificationType=jmx.attribute.change userData=null"

I want to be able to specify separate notification types and notification messages for each mbean (starting, stopping, ...).

Another problem I see at the moment is how to handle events that are
dealt with in classes that are not mbeans themselves but that are triggered
by an mbean. For example, the ImportService loads a bunch of classes that, among other things, handle the import of data for which it is important they arrive at regular intervals. What if they don't and I want to send a notification to the management station that there are no recent data anymore?

Best regards,

Guy

[dimitris]

Hi again,

I think you need to specify the actual value of the IMPORTSERVICE_REGISTRATION_NOTIFICATION constant both in your managers.xml and notifications.xml

e.g.

<monitored-obj>
<object-name>the-mbean-name</object-name>
<notification-type>the-actual-notification-type</notification-type>
<notification-type>another-actual-notification-type</notification-type>
...
</monitored-obj>
...

<notification-type>the-actual-notification-type</notification-type>
...

The message you see is from an AttributeChangeNotification send by JBoss to indicate the change to "starting" and then "started".

A restriction that do exists currently is that the specified notification-type -> snmp trap mapping is 1-1. So you can't have different mappings for different mbeans. You simply need to produce different notification types to alter the mbean mappings.

We've experimented by adding beanshell handlers to alter the mapping at runtime, based on the Notification data. This is not commited to the JBoss code, though.

The other problem you mention, essentially boils down to how you hook your POJOs to JMX. There are a few things you can do using open mbeans, but it is not simple.

The easiest solution is having your normal code wrapped by MBeans to control it's lifecycle, and have the normal classes expose some attribute that are exported by the MBean (e.g. time passed since last data update). Then you can configure monitor mbeans to poll the attribute periodically and throw Notification when some condition is met.

Hope that helps

Ciao
/Dimitris

[dhartford]

I'm gonna plead ignorance, and this may be a little off-topic, but can you get this SnmpAgent to send events/traps to something like OpenNMS? I've been trying to configure to at least watch the heartbeat event(5 sec intervals for testing) but no success. Newbie to OpenNMS 1.1.2/1.1.3-preview, so that may be the problem ;-)

-D