What snmp trap OID for general purpose application messaging?

Question

Context: Java Application Sending SNMP

I'm a developer with very little knowledge of SNMP. We wrap our java application with a 'windows service wrapper' which has the ability (among other things) to send snmp messages upon a variety of (user-configurable) events.

The example script has three arguments. Two are well-defined (ip address network monitoring system and "message text").

The other, "OID of the trap" , seems less clear.

By default, the script receives an 'id' parameter then appends it to this value: "1.3.6.1.2.1.1.1.", i.e. so you if you pass in 'id=999', it will broadcast an snmp trap with oid:"1.3.6.1.2.1.1.1.999"

Here's a reference for the meaning of "1.3.6.1.2.1.1.1." : it gives a pretty strict meaning as to the body of the corresponding message.

http://www.alvestrand.no/objectid/1.3.6.1.2.1.1.1.html

OID value: 1.3.6.1.2.1.1.1

OID description:

sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 }

Additional Context

• the application server can expose server info with jmx and products exist to bridge jmx to snmp (i.e. expose amount of memory used, thread count etc). This usecase however is a little different: the java wrapper can send snmp messages based on 'state changes' of the application itself. Developers and admins would find this 'state change' info helpful.

• we're running a few application servers: some in jboss-tomcat, other in plain tomcat

• we're using cacti for the 'snmp receiving' side. I personally don't know if it can handle any 'arbitrary application messages'. I'm assuming it/we would log the messages in a mysql database (or similar) for later querying/reporting.

Resources

I've looked around and found resources such as this one (https://github.com/waynearmorize/drivesploit/tree/master/data/snmp/mibs) which lists the various 'pre-defined' OID's. I see a list of values for rdbms-related problems, but no generic "insert your application here".

Questions

• Should the developers-and-sysadmins simply come up with our own list of 'application id suffixes': i.e. "1" is "application starting" "2" is application abort "3" is "out of memory" etc, and append this value to the '1.3.6.1.2.1.1.1.'
• What are the rules? both "hard rules" (i.e. you will break it) and "soft" , 'keep these for consistency'?
• So what are the rules for 'making up' OID's?
• Is SNMP the right tool for the job? It sounds good to the newbie, but I may be missing something.
• Any tips for this particular realm (i.e sending snmp traps from applications )?

thanks in advance

Answer 1

• Should the developers-and-sysadmins simply come up with our own list of 'application id suffixes': i.e. "1" is "application starting" "2" is application abort "3" is "out of memory" etc, and append this value to the '1.3.6.1.2.1.1.1.'

Every OID has a globally unique purpose and meaning. For example, OID 1.3.6.1.2.1.1.2 is defined in SNMPv2-MIB. The numbers break down as iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysObjectID(2).

You can look up the meaning of selected (by Cisco) OIDs using the Cisco SNMP Object Navigator. Note that there is no requirement for all MIBs to be published so there's no central collection where you can look up an arbitrary OID. You can think of a MIB as a document for defining OIDs, their types and relationships. A MIB has a formal, machine parseable structure.

Organisations often request a Private Enterprise Number and then define their stuff under OIDs begining with 1.3.6.1.4.1.PEN. If you can't find a published standard that meets your use case you may want to do this.

---

From a purely technical point of view, you can issue a trap with any OID at all but this will defy the expectations of anyone analysing the received value.