snmp-adaptor get/set and a basic MIB

[dimitris]

This is to discuss the work done on http://jira.jboss.com/jira/browse/JBAS-1454

[dimitris]

From a quick look at had it looks quite ok. Did you have to change something in the basic adapter? With what manager you tested?

[pilhuhn]

Dimitris,

Testing was with the mibbrowser from ireasoning (http://www.ireasoning.com/mibbrowser.shtml). But get requests were also tested by a customer of mine (who actually sponsored the work, but wants to stay unnamed) with Cacti and Nagios.

JBoss Group :) has the mib-prefix iso.org.dod.internet.private.enterprise.jboss assigned from Iana (Scott Stark is the contact). So the question is, whether the example settings from snmp-getvalues.xml should be moved into this space. Or is this already used by JBossON?

Cheers
Heiko

[pilhuhn]

I just commited a sample MIB file (varia/src/resources/jmx/examples) to head, which holfs the values from snm-getvalues.xml

[pilhuhn]

Did you have to change something in the basic adapter?

The changes basically all went to RequestHandlerSupport. In SnmpAgenService I only added a reconfigure() operation to enable rereading of the snmp-getvalues.xml without the need for a redeployment of the whole adapter stuff (which would imply sending some traps).

Heiko

[dimitris]

And I was wondering if the RequestHandlerSupport extension point would be enough. I'd like to have a closer look, when I get some free time.

Again, this is really cool Heiko, good stuff!

[pilhuhn]

The system group of MIB-2 (RFC1213) needs a systemOid as an identifier to uniquely identify the managed device

sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
network management subsystem contained in the
entity. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides an
easy and unambiguous means for determining `what
kind of box' is being managed. For example, if
vendor `Flintstones, Inc.' was assigned the
subtree 1.3.6.1.4.1.4242, it could assign the
identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
Router'."
::= { system 2 }

So the value should come from the Jboss-Prefix so.org.dod.internet.private.enterprise.jboss. I could imagine to have a sub-oid to determine the kind of jboss product (AS, cache, ...) where the agent is running on and a sub-oid to determine the version of the product.

Who is responsible for the mib subtree @ Jboss?

[starksm64]

Me, but we have done nothing to start to define a subtree to my knowledge. Need to check with ON to be sure they have not done anything. We should just start a wiki on a candidate subtree.

[richardfriedman]

Heiko,

I do not belieive there is anyone managing the snmp-subtree so suggestions very welcome. JBoss ON generates SNMP traps from configured alerts. The alerts can specify if they would like an SNMP trap generated and can specify the OID. Hence, it's really user-defined and should probably map to their own specific OID.

Instead of the definition of product should we just map the jmx domains under jboss?

So a generic approach might be
.jboss.jmx-domain.service.VERSION.property

Free memory would be
.jboss.system.ServerInfo.VERSION.FreeMemory

With that basis it might be easier to define the actual sub-tree.

[pilhuhn]

Instead of the definition of product should we just map the jmx domains under jboss?

Well, there are acutally two issues:
- identify the system in the mib-2 system group by delivering an oid to the caller in systemOid like in the quote above. I can imagine here something like
product ::= {jboss 1}
as ::= {product 1}
cache ::= {product 2}
hibernate ::={product 3}
and so on
and then have
as32 ::= {as 1}
as40 ::= {as 2}
as50 ::= {as 3}
cache13 ::= {cache 1}
cache14 ::= {cache 2}
and so on

The other thing is actually having one or more subtrees that define the
actual values like you describe it.

So a generic approach might be
.jboss.jmx-domain.service.VERSION.property

Free memory would be
.jboss.system.ServerInfo.VERSION.FreeMemory

With that basis it might be easier to define the actual sub-tree.

I think it is a good idea to have a subtree per jmx-Domain. I am not so sure if it makes sense to have an intermediate VERSION in the oid, as e.g. the free memory from jboss.system:type=ServerInfo is the same along all versions.

[starksm64]

I started an oid wiki page.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossOIDs

[misge]

Would it be possible to emmit SNMP traps for cold start/down and memory threshold concerning the AS?

[dimitris]

Coldstart is already there; shutdown should be easy by mapping the org.jboss.system.server.stopped notification by jboss.system:type=Server.

Memory thesholds, there is already a MemoryMonitor service. If I remember ,the problem is the adapter will map every notification type to the same oid, so you can't distinguish 'memory low' from 'memory back to normal' (except from the string message).

This is something I wanted to look at, i.e. make the produced oid dynamic, somehow.

[pilhuhn]

I guess one should use the enterprise specific trap (7) and use trap sub-ids for various event types.

[dimitris]

Sure. The problem is (currently) notification x.y.z maps to n.n.n.n, but the MemoryMonitor is an experiment to produce the same notification type, with a different "state" discriminator, to indicate a state change to an alarm condition that can go e.g. from normal->warning->critical->cleared->normal. In other words, this alarm/notification has an associated state.

This is different than producing an x.y.z.alarm notification to indicate the alarm and x.y.z.clean notificatino to indicate the clearance.

see:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ActiveAlarmTable
http://wiki.jboss.org/wiki/Wiki.jsp?page=AlarmManager

So what's needed is a more configurable way for specifying that an attribute's oid will be generated (rather than static). And while there, it's nice to think about a way to actually specify a different type mapping, e.g. a long maps to X snmp type, now the mapping is hardcoded.