SNMP Informant Knowledge-base |
Article: 2005-004
Product: SNMP Informant
Subject: Explanation of how SNMP Informant does OID indexing
Our SNMP Informant PDH Agents (Standard, Advanced, SQL Server, Exchange, etc) are essentially a bridge between Microsoft Windows Performance Counters and SNMP. Basically, we provide what is available in the Windows Performance Monitor (Start\Settings\Control Panel\Administrative Tools\Performance Monitor) through SNMP. Some of these counters have instances (e.g., Processor, Process, etc.) and some do not (e.g., Memory, Objects, etc). All PDH counter instances are referenced as strings as you can see through the Windows Performance Monitor.
Now onto and explanation on what the numbers mean:
The SNMP Informant PDH agents use OCTET STRING (SIZE(0..64)) as the primitive types for the indexed entries. According to RFC 1212, variable length strings are to be represented with the length of the string, followed by the octet (we use ASCII) representation of each character. Using this description as a basis, the breakdown of SNMPv2-SMI::enterprises.9600.1.2.64.1.8.3.109.97.100 (example) is:
Value | Meaning |
9600 | wtcs (registered IANA Private Enterprise Name) |
1 | informant (product line) |
2 | advanced (product name) |
64 | processTable |
1 | processEntry |
8 | processIDProcess |
3 | The string is three bytes long (see RFC 1212 section 4.1.6 (3) below) |
109.97.100 | Mad (the process name/string itself) |
Some of the PDH instance names can be rather long so we limit it to 64 UTF-8 encoded characters to ensure we fall within the maximum length for an OID.
How do we come up with the index number that proceeds the instance? The short answer is that it is the length of the ASCII string. The long answer, according to RFC 1212 (http://www.faqs.org/rfcs/rfc1212.html), section 4.1.6 is described below. Note the bolded section (3):
4.1.6. Mapping of the INDEX clause
The INDEX clause, which may be present only if that object type corresponds to a conceptual row, defines instance identification information for that object type. (Historically, each MIB definition contained a section entitled "Identification of OBJECT instances for use with the SNMP". By using the INDEX clause, this section need no longer occur as this clause concisely captures the precise semantics needed for instance identification.)
If the INDEX clause is not present, and the object type corresponds to a non-columnar object, then instances of the object are identified by appending a sub-identifier of zero to the name of that object.
Further, note that if the MIB module does not contain a textual description of how instance identification information is derived for columnar objects, then the INDEX clause must be present.
To define the instance identification information, determine which object value(s) will unambiguously distinguish a conceptual row. The syntax of those objects indicate how to form the instance-identifier:
(1) integer-valued: a single sub-identifier taking the integer value (this works only for non-negative integers);
(2) string-valued, fixed-length strings: `n' sub-identifiers, where `n' is the length of the string (each octet of the string is encoded in a separate sub-identifier);
(3) string-valued, variable-length strings: `n+1' sub-identifiers, where `n' is the length of the string (the first sub-identifier is `n' itself, following this, each octet of the string is encoded in a separate sub-identifier);
Finally, there are three main reasons why we use strings to index the instances.
1) As you can tell from our agents, there are vast number of counters and objects available through PDH. All the PDH counters use strings to represent the object instances. To be consistent, we index the same instance strings in SNMP as available through PDH. It would have been possible to refer the Process table only though PIDs, but this would not have been consistent with all of our other counters.
2) You can use the same OID to refer to the same PDH Counter, Object, and Instance all the time. For example, the OID .1.3.6.1.4.1.9600.1.2.64.1.4.4.115.109.115.115 always refers to the % of User Process Time for the �smss� process. If PID numbers were used, then it would change each time the process is restarted, thus requiring you find the new PID number.
3) SNMP Informant PDH agents are a 3rd party replacement to the old outdated, unsupported, and buggy Microsoft PERFMIB agents available through the NT Resource Kit. To provide the easiest upgrade path from PERFMIB to SNMP Informant, we use OCTET STRING Indexes like PERFMIB to reference the PDH instances.
End of document