SNMP MIBs и как их готовить
Доброго времени суток, читатель.
Предыстория
Установка MIBs
Стандартные
MIBs обычно распространяются в виде архива с пачкой файлов. Многие из них, составленные в iana и ietf, повторяются в каждом архиве, но передаются для совместимости.
Для работы в системе по умолчанию (конкретно для Debian) они должны лежать примерно в /usr/share/mibs
Для начала установим стандартные mibs в систему.
В файле конфигурации /etc/snmp/snmp.conf включить нужные. Пример:
mibs :ALL включает все, что не совсем хорошо. Рекомендую для каждого оборудования иметь папку с mib’ами, т.к. они могут отличаться из одной прошивки к другой.
Частный случай
После распаковки структура следующая:
Программное обеспечение
D-View
Net-SNMP
Возвращаюсь к тому, с чего начинал пост:
Мы скачали архив с MIBs и будем использовать утилиту snmptranslate из пакета Net-SNMP. Для удобства складываем все mibs в одну директорию, но это все равно не хватает:
Чтобы долго не мучатся скопируем недостающие файлы из mibs коммутатора des-3200 с опцией не перезаписывать существующие. И здесь мы уже получаем положительный результат:
Теперь, когда трансляция работает, можно вкусить всю прелесть иерархии OIDs. Для этого есть флаги:
Примеры использования
Можно просканировать все mibs и увидеть, что swL2macNotifyInfo есть и на других коммутаторах
Подводные камни D-Link
Здесь мы видим, что иерархия не сложилась до конца.
После исправления становится так:
Если не указать конкретный MIB, то получим ошибки в других mibs
Еще пример
Еще бонус в виде команды snmptable
Итого
В данный момент, я перевожу OID SNMP Traps с коммутаторов в понятный для оператора формат. Это послужит основой для системы регистрации событий на оборудовании. Использовать MIBs в приложении мы не собираемся по причине непереносимости и не универсальности. Думаю подавляющее большинство библиотек используют для трансляции OID системные базы MIBs и конфиг /etc/snmp/snmp.conf (их использует Net-SNMP, а библиотека обращется к последнему), а глобально включать эти модули MIBs мы не хотим. Эти данные можно использовать для экспериментов и добиться более универсального варианта по использованию MIBs, но для меня этого достаточно.
UPD:
Полезные ключи:
-TB ищет в MIBs Object Name по regexp
-On выводит Object ID
Примеры:
Как читать MIB и OID
Общая информация
Знание протокола 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
Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:
| 1 | iso | International Organization for Standardization (ISO) |
| 3 | identified-organization | Схема определения организации согласно ISO/IEC 6523-2 |
| 6 | dod | United States Department of Defense (DoD). Эта организация изначально занималась стандартизацией протокола |
| 1 | internet | Интернет |
| 2 | mgmt | IETF Management |
| 1 | mib-2 | База OID для спецификации MIB-2 |
| 1 | system | Характеристики системы |
| 5 | sysName | Имя системы |
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. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:
| 4 | private | Частные проекты |
| 1 | enterprise | Частные организации |
| 343 | intel | Этот номер закреплён за компанией Intel |
| 2 | products | Продукты |
| 19 | modularsystems | Серверы линейки Modular System |
| 1 | multiFlexServer | Тип сервера Multi-Flex Server |
| 2 | components | Компоненты |
| 10 | chassis | Контейнер для информации об аппаратном блоке |
| 206 | fans | Вентиляторы |
| 1 | fanFruTable | Таблица вентиляторов |
| 1 | fanFruEntry | Информация о вентиляторе |
| 16 | fanFruInletTemperature | Температура возле вентилятора |
| 1 | датчик возле первого вентилятора |
Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.
Как читать MIB
При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
Строка в описании объекта fans
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
Видим, что его индекс=16. Таким образом, 206.1.1.16 — содержит список всех температурных датчиков возле вентиляторов системы и, соответственно, 206.1.1.16.1 — номер первого из них. Сколько их всего узнаем позже. Теперь выясним адрес объекта chassis, в котором находятся только что найденные нужные нам параметры. Так, сквозной поиск строки «chassis OBJECT-IDENTITY» по всем MIB файлам приводит нас к другому MIB’у:
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
Далее находим и остальное:
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и online. Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь NuDesign Visual MIBuilder.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Быстрое обнаружение поддерживаемых SNMP-устройством MIB-модулей
При внедрении систем мониторинга и управления IT-инфраструктурой часто приходится сталкиваться с «нестандартными» устройствами. Нередко про такое устройство наверняка известно только то, что оно поддерживает SNMP. Подключение его к проекту придется начать с ответа на вопрос о том, какую информацию о себе оно предоставляет. Обычно для этого проводится полный опрос устройства, и полученные данные анализируются на предмет выявления полезной информации… Но тут, как говорится, есть нюансы. В этой заметке я расскажу об одном таком — о разработанном нами алгоритме быстрого определения «поддерживаемых» устройством MIB-модулей.
Зачем это надо?
Данных на устройстве может быть довольно много. Например, маршрутизатор Cisco 2600, с которым я немного поэкспериментировал в процессе написания этой статьи, выдает более 12-ти тысяч значений. 
И, надо сказать, это далеко не предел.
В связи с этим возникает пара проблем: как в этой куче информационного богатства отыскать именно полезные/нужные данные, и как это сделать за разумное время?
Решение первой лежит на поверхности: в соответствии с древней стратегией «разделяй и властвуй» надо разбить все собранные значения на относительно небольшое количество категорий, каждую из которых оценить на предмет полезности. Ответ на вопрос «как и на какие категории разбивать данные?» в данном случае тоже достаточно очевиден — все (ну, или практически все) данные до нас рассортировали по MIB-модулям, куда обычно складывают описания логически связанных между собой элементов данных (переменных).
Стандартный способ разбиения SNMP-данных в AggreGate Network Manager — по MIB-модулям.
Таким образом, подзадача выделения нужной информации сводится к отображению полученных данных на MIB-модули (связь осуществляется по идентификатору переменной — OID-у).
Существует много инструментов, делающих что-то подобное. И все они (по крайней мере, все известные нам) выполняют полный опрос устройства.
Так, к примеру, работает утилита MIB Walk в составе Engineer’s Toolset от SolarWinds, которая ту же «киску» с моего компьютера опрашивает 3,5 – 4 минуты. Вроде бы, это и не так много. Но надо учесть, что это не самое «большое» устройство, и что доступно мне оно по слабо загруженной локальной сети. В условиях настоящего «боевого» проекта, где присутствует серьезный трафик, а устройство находится в другой сети, время полного опроса может вырасти на порядки. И пока идет такой опрос, специалист, в чьи обязанности входит подключение устройства, так или иначе отвлечется, что называется «потеряет контекст», и сюда придется добавить время на «возвращение к задаче» (что нередко оказывается значительным довеском). Надо также учесть, что таких устройств в серьезном проекте часто бывает много — в некоторых случаях нам приходилось изучать по 2 – 3 десятка устройств. В конечном итоге набегает значительная величина.
Так или иначе, но и наши собственные специалисты по внедрению систем мониторинга, и самостоятельно настраивающие систему пользователи в какой-то момент стали часто упоминать ожидание завершения полного опроса SNMP-устройств в качестве одного из факторов, существенно «тормозящих» работу. И пришлось изобретать способ, позволяющий сократить время бесполезного ожидания. В итоге, мы придумали и реализовали в своей системе следующий алгоритм.
Алгоритм быстрого обнаружения доступных на SNMP-устройстве MIB-модулей
Даны список MIB-модулей и SNMP-устройство
Требуется определить, «поддерживается» ли этим устройством каждый из данных MIB-модулей.
Такая формулировка сразу ставит вопрос: Что значит «MIB-модуль поддерживается устройством»?
MIB-модуль представляет собой описание некоторого набора SNMP-переменных. В свете этого логично звучит следующий ответ на вопрос: будем считать, что MIB-модуль поддерживается, если хотя бы одна описанная в нем переменная присутствует на устройстве.
Замечание: Есть небольшая сложность: одно и то же значение может быть описано в разных MIB-ах. Ниже мы это учтем.
Из данного определения напрямую вытекает идея оптимизации: если мы нашли на устройстве одну переменную из некоторого MIB-модуля, остальные переменные данного модуля можно исключить из опроса. Поскольку переменные MIB-модуля чаще всего идут довольно большими блоками, мы можем не просто заметно, а, как показывает практика, радикально сократить количество данных, которые нам нужно будет получить от устройства. За счет этого снизится и время опроса.
Таким образом, мы не «гуляем» (WALK) по устройству, а буквально несемся по нему большими скачками.
Помня о высокой «кучности» OID-ов в MIB-модуле, можно слегка улучшить алгоритм за счет предварительного «прореживания» исходного списка OID-ов: если некоторая последовательность OID-ов относится к одному MIB-модулю (или, в более общем случае, к одному множеству MIB-модулей), то нет смысла проверять их все — запрос GET_NEXT к первом из них в любом случае выдаст либо один из этой группы, либо покажет, что данный блок данных на устройстве отсутствует.
Результаты
На рисунках представлен результат обнаружения MIB-модулей на упомянутом выше маршрутизаторе Cisco.
Начало списка обнаруженных модулей:
А это — его последняя страница:
Как видим, обнаружено 64 MIB-модуля. Кстати, время работы алгоритма: 1–2 секунды.
На следующем скриншоте — результат обнаружения на «нестандартном» устройстве Hirschmann Railswitch RSB20.
Две последних записи представляют «кастомные» MIB-модули, поставляющиеся с этим устройством.
«Вживую» процесс обнаржения MIB-модулей на Hirschmann-е можно увидеть в нашем ролике про подключение нестандартных устройств (гурманов может заинтересовать англоязычная версия). Правда вся магия с MIB-ами остается за кадром и укладывается в двух–трех секундный отрезок, но зато станет понятен наш подход к работе с SNMP-устройствами.
Ordnung muß sein. Ordnung über alles (18+)
Инструменты пользователя
Инструменты сайта
Боковая панель
Навигация
Линкшэринг
socialite Display:icon facebook twitter
ALARM!
Добавить новую страницу
Реклама
Содержание
Как читать MIB и OID
Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB.
Общая информация
Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):
Object Name — имя объекта, уникальная константа для всего MIB, однозначно соответствующая определённому OID.
MIB — это структурированный текстовый файл или несколько файлов, которые содержат информацию о всех объектах устройства. Объектом может быть какая-нибудь настройка или параметры системы. У каждого объекта есть свой набор полей, таких как тип данных, доступность (чтение, запись), статус (обязательный, необязательный), текстовое название настройки. Также объект может содержать другие объекты.
Как читать OID
Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:
| 1 | iso | International Organization for Standardization (ISO) |
| 3 | identified-organization | Схема определения организации согласно ISO/IEC 6523-2 |
| 6 | dod | United States Department of Defense (DoD). Эта организация изначально занималась стандартизацией протокола |
| 1 | internet | Интернет |
| 2 | mgmt | IETF Management |
| 1 | mib-2 | База OID для спецификации MIB-2 |
| 1 | system | Характеристики системы |
| 5 | sysName | Имя системы |
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. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:
| 4 | private | Частные проекты |
| 1 | enterprise | Частные организации |
| 343 | intel | Этот номер закреплён за компанией Intel |
| 2 | products | Продукты |
| 19 | modularsystems | Серверы линейки Modular System |
| 1 | multiFlexServer | Тип сервера Multi-Flex Server |
| 2 | components | Компоненты |
| 10 | chassis | Контейнер для информации об аппаратном блоке |
| 206 | fans | Вентиляторы |
| 1 | fanFruTable | Таблица вентиляторов |
| 1 | fanFruEntry | Информация о вентиляторе |
| 16 | fanFruInletTemperature | Температура возле вентилятора |
| 1 | датчик возле первого вентилятора |
Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.
Как читать MIB
При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
Строка в описании объекта fans
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
Далее находим и остальное:
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.
Теперь, зная как читать MIB’ы и OID’ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.
Как читать MIB и OID
Содержание
Общая информация
Знание протокола SNMP, предназначенного для управления и наблюдения за устройствами в сети, очень полезно при диагностики здоровья всей системы. С его помощью администратор может автоматизировать сбор статистики с ключевых узлов: коммутаторов, маршрутизаторов, компьютеров и других устройств поддерживающих этот протокол. В этой статье мы рассмотрим на примерах, как понимать и использовать ключевое понятие в SNMP протоколе — базу данных MIB. [1]
Для начала кратко опишем некоторые важные термины протокола SNMP (Simple Network Managment Protocol):
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
Вышеприведённый OID (1.3.6.1.2.1.1.5) для объекта sysName построен целиком на стандартном MIB, и будет существовать скорее всего на всех устройствах. Он читается так:
| 1 | iso | International Organization for Standardization (ISO) |
| 3 | identified-organization | Схема определения организации согласно ISO/IEC 6523-2 |
| 6 | dod | United States Department of Defense (DoD). Эта организация изначально занималась стандартизацией протокола |
| 1 | internet | Интернет |
| 2 | mgmt | IETF Management |
| 1 | mib-2 | База OID для спецификации MIB-2 |
| 1 | system | Характеристики системы |
| 5 | sysName | Имя системы |
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. Четыре первых мы уже расшифровали выше, остальные поясняются следующим образом:
| 4 | private | Частные проекты |
| 1 | enterprise | Частные организации |
| 343 | intel | Этот номер закреплён за компанией Intel |
| 2 | products | Продукты |
| 19 | modularsystems | Серверы линейки Modular System |
| 1 | multiFlexServer | Тип сервера Multi-Flex Server |
| 2 | components | Компоненты |
| 10 | chassis | Контейнер для информации об аппаратном блоке |
| 206 | fans | Вентиляторы |
| 1 | fanFruTable | Таблица вентиляторов |
| 1 | fanFruEntry | Информация о вентиляторе |
| 16 | fanFruInletTemperature | Температура возле вентилятора |
| 1 | датчик возле первого вентилятора |
Вся описательная информация находится как раз в текстовых файлах MIB, поэтому давайте разберёмся как их читать.
Как читать MIB
При работе с удалённой системой по SNMP протоколу все запросы происходят через OID, отражающий положение объекта в дереве объектов MIB. Все OID системы можно получить просканировав устройство, например командой snmpwalk:
К сожалению, иногда команда не успевает вытащить все переменные, так как на некоторых устройствах их сильно много и защита от DOS атак срабатывает раньше, блокируя доступ на некоторое время. Поэтому данные иногда удобней получать частично, лишь для определённой ветки:
Однако, полученные цифровые значения часто не раскрывают своего предназначения, поэтому, возникает обратная задача: узнать какой OID у интересующего нас объекта. Для этого придётся изучать MIB устройства.
Так, для того чтобы узнать температуру в корпусе Intel Modular Server, возмём MIB описывающего параметры вентиляторов системы и делаем в нём поиск слова temperature, находим объект fanFruInletTemperature и смотрим его описание. Вот нужный нам фрагмент:
Строка в описании объекта fans
говорит о том, что описанный объект будет расширять объект (являться веткой в дереве объектов) chassis, имея в нём индекс 206, а следующий объект fanFruTable в свою очередь будет расширять объект fans, представляя в нём ветку с индексом 1, также fanFruEntry будет первой веткой у объекта fanFruTable. В параметрах fanFruEntry и содержится интересующий нас fanFruInletTemperature.
Запоминаем адрес ветки: 206.1.1, начиная от объекта chassis. Теперь ищем далее в файле описание объекта fanFruInletTemperature:
где мы узнаём, что он содержится в объекте components. Далее сквозной поиск строки «components OBJECT-IDENTITY» (нужно учесть, что пробелов между словами может быть разное количество) даёт строчку:
Далее находим и остальное:
Записывая все полученные ID объектов получаем полный OID для температурных датчиков: 1.3.6.1.4.1.343.2.19.1.2.10.206.1.1.16
Теперь можно узнать их значения, заодно выяснив и их количество:
По приведённому несложному алгоритму можно прочитать любой MIB, главное получить его, что, к сожалению, не всегда возможно.
Для облегчения работы с MIB файлами существует множество программ как платных, так и бесплатных, в том числе и on-line (см. раздел Ссылки). Любой поисковик на запрос MIB browser выдаст много полезных ссылок. Я пользуюсь iReasoning MIB Browser, но не потому, что он лучше других, а просто я попробовал его первым и он мне вполне понравился.
Теперь, зная как читать MIB’ы и OID’ы администратору будет легче использовать и донастраивать системы мониторинга здоровья системы, такие как Zabbix, MRTG, PRTG, Cacti и т.п.
