Index  •  Intro  •  Basics of software monitoring  •  Standard Monitors  •  FAQ  •  Help  •  JavaDoc  •  Download

Tutorial 1: Detailed monitoring guide  •  Tutorial 2: HttpSessionListener  •  Tutorial 3: MySQL replication  •  Tutorial 4: Java Garbage Collection

Free online databases of MIB's and OID's are readily available.

Management Information Base (MIB) is one of those terms, which can mean one of several things. In general "a MIB" refers to group of management objects, all relating to the same general management task. This is more strictly a "MIB module" or "MIB file". "The MIB" of an agent or management tool is the collection of all MIB modules known to that particular application. An Object ID (OID) is a way of identifying a particular management object, as a sequence of numerical sub-identifiers.

There's also a distinction between a "management object" (hrProcessorLoad, ifInOctets, etc.) which refers to the abstract idea, and an "instance" of this object (sysName.0, ifInOctets.3) which refers to a particular value for that object. OIDs are used to identify both of these in exactly the same way. This distinction makes life very difficult without very expensive SNMP management tools.

Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables.

SCALAR

One scalar metric that is quite easy to understand is tcpCurrEstab with OID of 1.3.6.1.2.1.6.9. It represents number of established TCP connections. To obtain the value of this metric just attach ".0" at the end of the OID and call get() SNMP API method (1.3.6.1.2.1.6.9.0). Nothing tricky here…

TABULAR

One tabular metric that is quite easy to understand is CPU load. It is buried down in a hierarchy of metrics at this location: iso(1). org(3). dod(6). internet(1). mgmt(2). mib-2(1). host(25). hrDevice(3). hrProcessorTable(3). hrProcessorEntry(1). hrProcessorLoad(2). This name can be encoded using path-like structure, where each level is separated by the ".". Thus hrProcessorLoad is also known as 1.3.6.1.2.1.25.3.3.1.2. Each number in OID represents a node in the hierarchy of OID's.

Lets use SNMP management tool. We start it up, plug in 1.3.6.1.2.1.25.3.3.1.2 and click getSubtree(). I happen to have a dual CPU box, each CPU having hyper-threading. For my machine tool returns this values:

• 1.3.6.1.2.1.25.3.3.1.2.2 has value 23
• 1.3.6.1.2.1.25.3.3.1.2.3 has value 17
• 1.3.6.1.2.1.25.3.3.1.2.4 has value 23
• 1.3.6.1.2.1.25.3.3.1.2.5 has value 17

As you can see, each returned value for hrProcessorLoad (23, 17, 23, 17) has it's own OID (2, 3, 4, 5). Even if these OID's look very similar, they are very different. OID 1.3.6.1.2.1.25.3.3.1.2 represents management object hrProcessorLoad, but OID 1.3.6.1.2.1.25.3.3.1.2.3 represents an instance (value) of this management object. Types and instances kind of thing...

Do not assume that 2, 3, 4, 5 are CPU indexes. We have seen cases when one entry had ".1" and next one had ".16783". Scary... The best thing is too assume that (2, 3, 4, 5) are just unique identifiers. Accordingly, one should not attempt to work with OID instances as one would work with arrays.

You might think this way: "I have 4 CPU's, so I need to make 4 OID's by attaching 0, 1, 2, 3 at the end of hrProcessorLoad OID." Nop... This strategy is very dangerous and is not reliable. It might work for some SNMP object, but it does not in general. It is better to rely on OID of management objects. From here one needs to conduct a walk, recording values of specific OID instances that are found. Here is how to do it:

1. call getNext() for the hrProcessorLoad using 1.3.6.1.2.1.25.3.3.1.2
2. check OID of the returned object, its OID musts start with 1.3.6.1.2.1.25.3.3.1.2, or it is not an instance of hrProcessorLoad
3. record hrProcessorLoad value
4. call getNext() using OID of the returned object

It is quite a beauty. Do not you think?