1 2 Previous Next 17 Replies Latest reply on Aug 11, 2006 10:07 AM by bsturzoiu

    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

        • 1. Re: snmp-adaptor get/set and a basic MIB
          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?

          • 2. Re: snmp-adaptor get/set and a basic MIB
            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

            • 3. Re: snmp-adaptor get/set and a basic MIB
              pilhuhn

              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
                pilhuhn

                 

                "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

                  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
                    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?


                    • 7. Re: snmp-adaptor get/set and a basic MIB
                      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.

                      • 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
                          pilhuhn

                           

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

                                • 13. Re: snmp-adaptor get/set and a basic MIB
                                  pilhuhn

                                  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

                                    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