-
1. Re: snmp-adaptor get/set and a basic MIB
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?
-
2. Re: snmp-adaptor get/set and a basic MIB
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 -
3. Re: snmp-adaptor get/set and a basic MIB
I just commited a sample MIB file (varia/src/resources/jmx/examples) to head, which holfs the values from snm-getvalues.xml
-
4. Re: snmp-adaptor get/set and a basic MIB
"dimitris@jboss.org" wrote:
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 -
5. Re: snmp-adaptor get/set and a basic MIB
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! -
6. Re: snmp-adaptor get/set and a basic MIB
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? -
7. Re: snmp-adaptor get/set and a basic MIB
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.
-
8. Re: snmp-adaptor get/set and a basic MIB
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. -
9. Re: snmp-adaptor get/set and a basic MIB
"rfriedman@jboss.com" wrote:
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. -
10. Re: snmp-adaptor get/set and a basic MIB
I started an oid wiki page.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossOIDs -
11. Re: snmp-adaptor get/set and a basic MIB
Would it be possible to emmit SNMP traps for cold start/down and memory threshold concerning the AS?
-
12. Re: snmp-adaptor get/set and a basic MIB
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. -
13. Re: snmp-adaptor get/set and a basic MIB
I guess one should use the enterprise specific trap (7) and use trap sub-ids for various event types.
-
14. Re: snmp-adaptor get/set and a basic MIB
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.