Источник - http://sysadminwiki.ru/wiki/Как_читать_MIB_и_OID
(Первоначально статья была опубликована в журнале Системный администратор, январь 2011)

Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB.

Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):

MIB - Managment Information Base - база данных информации управления, хранящая информацию обо всех объектах (параметрах и настройках) устройства.

OID - Object IDentificator - числовой идентификатор объекта в дереве MIB.

Object Name — имя объекта, уникальная константа для всего MIB, однозначно соответствующая определённому OID.

MIB — это структурированный текстовый файл или несколько файлов, которые содержат информацию о всех объектах устройства. Объектом может быть какая-нибудь настройка или параметры системы. У каждого объекта есть свой набор полей, таких как тип данных, доступность (чтение, запись), статус (обязательный, необязательный), текстовое название настройки. Также объект может содержать другие объекты.

Есть стандартные MIB'ы, определяемые различными RFC и огромное множество MIB'ов от производителей оборудования, которые дополняют стандартные и могут быть взяты с сайтов этих компаний. Эти дополнения необходимы, чтобы описать специфические для устройства параметры. Можно также составить и свои MIB'ы, нигде их не регистрировать и успешно использовать.

Каждый объект в MIB имеет свой уникальный цифровой адрес OID и имя Object Name. SNMP менеджер, используя OID, способен считывать или устанавливать значение объекта. Например, адрес объекта (OID) содержащего наименование системы: 1.3.6.1.2.1.1.5, а его имя (object name): sysName. Так как всё общение между SNMP агентом устройства и SNMP менеджером (системой наблюдения или администратором) происходит через OID, то понимать, что они описывают, очень даже полезно. Имя объекта играет ту же роль в SNMP, что и DNS имя в ip сетях — более наглядное описательное представление набора чисел. Строго говоря в разных MIB'ах оно может представлять разные OID, хотя, те что описаны в RFC, по идее должны быть уникальными для всех.

Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:

OID специфичного объекта для конкретного устройства, дополненный своими MIB'ами, будет значительно длиннее. Вот пример OID датчика температуры у первого вентилятора в Intel Modular Server: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.1. Первые 7 параметров из стандартных MIB'ов, остальные 10 из MIB'ов Intel. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:

Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.

При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:

snmpwalk -c public -v2c 10.0.0.1

где

• -c public - обращение к сообществу (comminity) public, на многих устройствах оно существует по умолчанию и в режиме только для чтения;
• -v2c - использовать вторую версию протокола SNMP;
• 10.0.0.1 - IP адрес устройства.

К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:

snmpwalk -c public -v2c 10.0.0.1 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16

Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.

Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:

--
-- fans tree 
--

fans OBJECT-IDENTITY

STATUS current

DESCRIPTION

"Container for Fan specific information as 
well as all components logically contained 
within."

::= { chassis 206 }

fanFruTable OBJECT-TYPE

SYNTAX SEQUENCE OF FanFruEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"Each row describes a Fan FRU in the chassis
Current, this should include the 3 Fan FRUs 
(the two system Fan FRUs and the I/O Fan FRU)
All system FRUs rows will be present"

::= { fans 1 }

fanFruEntry OBJECT-TYPE

SYNTAX FanFruEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

".."

INDEX { fanFruIndex }

::= { fanFruTable 1 }

FanFruEntry ::=

SEQUENCE {
fanFruIndexIndex,
fanFruPresencePresence,
fanFruVendorDisplayString,
fanFruMfgDateDisplayString,
fanFruDeviceNameDisplayString,
fanFruPartIdromBinary16,
fanFruSerialNoIdromBinary16,
fanFruMaximumPowerPower,
fanFruNominalPowerPower,
fanFruAssetTagIdromBinary16,
fanFruPowerLedPowerLedStates,
fanFruFaultLedFaultLedStates,
fanFruOpCodeVersionDisplayString,
fanFruBootBlockVersionDisplayString,
fanFruNumOfFansINT32withException,
fanFruInletTemperatureINT32withException
}

Строка в описании объекта fans

::= { chassis 206 }

говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.

Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:

fanFruInletTemperature OBJECT-TYPE

SYNTAX INT32withException

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"FRU Inlet Temperature in Degrees Celsius"

::= { fanFruEntry 16 }

Видим, что его индекс=16. Таким образом, 206.1.1.16 - содержит список всех температурных датчиков возле вентиляторов системы и, соответственно, 206.1.1.16.1 - номер первого из них. Сколько их всего узнаем позже. Теперь выясним адрес объекта chassis, в котором находятся только что найденные нужные нам параметры. Так, сквозной поиск строки "chassis OBJECT-IDENTITY" по всем MIB файлам приводит нас к другому MIB'у:

chassis OBJECT-IDENTITY

STATUS current

DESCRIPTION

"chassis for the Multi-Flex Server product.
Container for chassis specific information 
as well as all components logically contained within."

::= { components 10 }

где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки "components OBJECT-IDENTITY" (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:

components OBJECT IDENTIFIER::= { multiFlexServer 2 }

Далее находим и остальное:

--
-- Path to our product
--

intelOBJECT IDENTIFIER ::= { enterprises 343 }
productsOBJECT IDENTIFIER ::= { intel 2 }
modularsystems OBJECT IDENTIFIER ::= { products 19 }
multiFlexServer OBJECT IDENTIFIER ::= { modularsystems 1 }

Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16

Теперь можно узнать их значения, заодно выяснив и их количество:

$ snmpwalk -c public -v2c 10.0.0.1 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16

iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.1 = INTEGER: 27
iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.2 = INTEGER: 26
iso.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16.3 = INTEGER: 19

По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.

Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.

Теперь, зная как читать MIB'ы и OID'ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.

On-line сервисы для чтения MIB:

• http://www.oid-info.com/get/ - поиск по OID с детальным пояснением всех узлов. Есть возможность расширить список своими MIB'ами. Можно посмотреть дерево объектов.
• http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en - поиск по OID и Object Name. Кроме стандартных, есть специфичные для Cisco MIB'ы