1 2 Previous Next 17 Replies Latest reply: Aug 11, 2006 10:07 AM by Bogdan Sturzoiu RSS

snmp-adaptor get/set and a basic MIB

Dimitris Andreadis Master

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

  • 1. Re: snmp-adaptor get/set and a basic MIB
    Dimitris Andreadis Master

    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
    Heiko Rupp Master

    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
    Heiko Rupp Master

    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
    Heiko Rupp Master

     

    "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
    Dimitris Andreadis Master

    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
    Heiko Rupp Master

    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
    Scott Stark Master

    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
    Richard Friedman Newbie

    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
    Heiko Rupp Master

     

    "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.

  • 11. Re: snmp-adaptor get/set and a basic MIB
    misge Newbie

    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
    Dimitris Andreadis Master

    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
    Heiko Rupp Master

    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
    Dimitris Andreadis Master

    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.

1 2 Previous Next