Как узнать mib устройства

Объяснение SNMP MIB и OID

SNMP имеет несколько компонентов под поверхностью, которые позволяют передавать информацию о производительности обратно конечному пользователю. Агенты SNMP, SNMP менеджеры, MIBS, и OIDs все работают вместе, чтобы сделать эти переводы возможными. В этой статье мы рассмотрим, что такое MIBS и OID, и что они делают. Однако, прежде чем мы это сделаем, мы должны посмотреть, что такое SNMP.

Что такое SNMP?

SNMP или Простой протокол управления сетью это хорошо известный сетевой протокол, который находится на уровне приложений. Протокол SNMP восходит к 1989 году и был создан для того, чтобы устройства могли обмениваться информацией друг с другом по сети. Сегодня SNMP используется для мониторинга устройств с поддержкой SNMP и посмотреть, как их производительность задерживается. Архитектура SNMP состоит из менеджеров SNMP и агентов SNMP.

Отношения между менеджером SNMP и агентом SNMP основаны на сообщениях и командах. Эти сообщения бывают разных форм. Некоторые из сообщений, которыми обмениваются эти два компонента, перечислены ниже:

Смотрите также: SNMP объяснил

Что такое MIB?

MIB или База управленческой информации представляет собой отформатированный текстовый файл, который находится в диспетчере SNMP и предназначен для сбора информации и ее упорядочения в иерархическом формате. Менеджер SNMP использует информацию из MIB для перевода и интерпретации сообщений перед их отправкой конечному пользователю..

Что такое OID?

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

Они часто изображаются в виде дерева. OID форматируется в виде строки чисел, как показано ниже:

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

Каждый из этих номеров предоставляет вам соответствующую информацию. Например:

OID почти всегда начинаются с одинаковой последовательности чисел; 1.3.6.1.4.1. Мы рассмотрим, что означают эти цифры, более подробно ниже:

В большинстве случаев OID будут предоставляться поставщиком, у которого вы приобрели устройство.

SNMP получает запросы и ловушки SNMP

В случае прерываний SNMP агент SNMP автоматически уведомляет диспетчер SNMP о значительном событии на устройстве. Ловушки важны, потому что они отправляются менеджеру SNMP без опроса. Следовательно, ловушки помогают держать пользователя в курсе изменений внутри устройства..

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

Как использовать MIB и OID

Как мы уже говорили выше, каждое сетевое устройство с поддержкой SNMP будет иметь свою собственную таблицу MIB со многими различными OID. В большинстве MIB так много OID, что было бы практически невозможно записать всю информацию. Вместо того, чтобы делать это вручную, вы должны использовать инструмент мониторинга сети, такой как Монитор производительности сети SolarWinds или Paessler PRTG Сетевой монитор.

Монитор производительности сети SolarWindsСкачать 30-дневную бесплатную пробную версию

Сетевой монитор Paessler PRTGСкачать 30-дневную бесплатную пробную версию

Инструменты мониторинга SNMP предназначены для сбора данных из MIB и OID для представления в удобном для понимания формате. Запросы на получение и прерывания SNMP предоставляют сетевым мониторам необработанные данные о производительности, которые затем преобразуются в графические дисплеи, диаграммы и графики. Таким образом, MIB и OID позволяют вам контролировать несколько устройств с поддержкой SNMP из одного централизованного местоположения..

MIB и написание собственных MIB

Одна из интересных вещей о MIB заключается в том, что Вы можете создавать свои собственные MIB. Когда вы покупаете новое устройство, вы не ограничены использованием MIB, которые поставляются из коробки. Тем не менее, чтобы создать свой собственный MIB вам нужно знать, какие объекты вы хотите включить в него. Вы можете записать это в виде списка. После того, как вы написали список объектов, вам нужно определить место MIB в более широкой иерархии OID..

MIB и OID: винтики в машине

Хотя предпосылка SNMP относительно проста, архитектура временами может быть обманчиво сложной. Важно помнить, что отношения SNMP Manager и SNMP Agent гарантируют, что пользователь может контролировать несколько устройств из одного места..

При загрузке инструмента сетевого мониторинга агенты SNMP отправляют данные со всей сети. Информация, которую вы видите на экране, подается из прерываний SNMP и запросов Get. Вы можете просматривать эти данные в форме графиков и диаграмм, но эти данные фактически записываются в MIB и идентифицируются с помощью OID..

Данные в MIB идентифицируются с помощью OID, поэтому сетевые мониторы могут получать точную информацию, которая им нужна. Без ID получить запросы было бы невозможно, потому что инструмент мониторинга не смог бы найти переменные в MIB. MIB и OID являются неотъемлемой частью архитектуры SNMP. Эти два компонента жизненно важны для того, чтобы вы могли контролировать сетевую инфраструктуру и выполнять диагностику.

Смотрите также: Руководство по UDP (протокол дейтаграмм пользователя)

Источник

Как читать 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, и будет существовать скорее всего на всех устройствах. Он читается так:

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, поэтому давайте разберёмся как их читать.

Как читать 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 устройства

Для корректного опроса коммутатора по SNMP нужно обратиться к ветви MIB по числовому имени, уникальному идентификатору OID. Его можно узнать используя соответствующее прошивке коммутатора дерево значений SNMP, в текстовом виде это MIB-файлы.
Скачать MIB для коммутатора D-link можно на ftp сервере d-link:

http://ftp.dlink.ru/pub/Switch/

Для просмотра скачанного файла требуется MIB-браузер. Рассмотрим работу с MIB-файлами на примере iReasoning MIB Browser.
При запуске программы появляется окно изображенное на рисунке 1.

Рисунок 1.

Для загрузки MIB нужно выбрать раздел File → Load MIBs (или нажать сочетание клавиш Ctrl+L), появится окно выбора MIB-файлов (рисунок 2).

Рисунок 2.

После выбора нужного файла необходимо нажать кнопку Open. Для просмотра требуется раскрыть дерево, находящееся в левой части окна браузера (рисунок 3).

Рисунок 3.

Каждый объект имеет свой уникальный числовой идентификатор OID, для получения необходимого OID можно раскрыть соответствующую ветвь MIB или воспользоваться поиском выбрав раздел Edit →Find in MIB Tree (или нажав сочетание клавиш Ctrl+F) (рисунок 4).

Рисунок 4.

После нахождения нужного объекта, его OID отображается в соответствующем поле, так же доступно описание выбранного объекта (рисунок 5).

Рисунок 5.

Значение по OID можно получить как через сам iReasoning MIB Browser (раздел Operations), так и через командную строку.

Например, получим по SNMP версию программного обеспечения коммутатора DES-1210-28. Для этого найдём в MIB дереве ветвь Compan, а в ней sysFirmwareVersion. Далее в поле Address требуется ввести ip адрес коммутатора, нажать кнопку Operations →Get и в поле Result Table отобразится запрашиваемый параметр.

Рисунок 6.

Источник

Руководство по командам Net-SNMP

Mark Silinio
последнее обновление 21/04/05
Оригинал: silinio.webhost.ru

Что про что

Примечания по переводу:

Содержание:

snmptranslate: анализ OID’ов в MIB деревьях

snmpget: получение информации с удалённого хоста

snmpgetnext: получение информации следующего OID’а

Команда snmpgetnext похожа на snmpget, с тем лишь различием, что возвращает OID и его значение, следующее в MIB-дереве за тем, что указано в качестве аргумента:

Так, snmpgetnext может использоваться для последовательного просмотра OID’ов просто путём указания в аргументе последнего полученного OID’а:
Фактически команда snmpwalk, рассматриваемая ниже, делает то же самое за один раз!
В отличие от snmpget, snmpgetnext возвращает значение для OID’а, написанного без индекса(см. про snmpget выше). В таком случае с snmpgetnext не будет возникать ошибки, т.к. вы получаете значение следующей переменной независимо от того, указан ли индекс для переменной в аргументе команды:

snmpwalk: серия snmpnext комманд за раз

Команда snmpwalk автоматически выполняет серию snmpnext команд внутри заданного OID’ом диапазона. К примеру, если вы хотите получить всю информацию, хранящуюся в MIB группе system, используйте следующую команду:

snmptable: отображение SNMP-таблицы

Команда snmptable отображает SNMP таблицу в разбитом на колонки виде. Рассмотрим данные sysORTable. В отличие от команды snmpwalk, отображающей данные в виде длинного списка, snmptable форматирует вывод в удобном для чтения виде (иногда, как в примере ниже, вывод может быть весьма широк):

Но вы можете менять ширину выводимой таблицы:

snmpset: изменение OID’ов

Как вы могли видеть, мы успешно изменили значение OID’а ucdDemoPublicString.0.
Заметьте, что в случае, когда вы не имеете права на изменение(запись) объекта, сообщения об ошибке различны для SNMPv1 и SNMPv2c:

В SNMPv1 отсутствуют описания ошибок, но это исправлено в SNMPv2c. Весьма рекомендуется использовать SNMPv2c вместо SNMPv1, но ещё более лучшим вариантом будет SNMPv3 как в плане безопасности, так и в плане сообщений об ошибках,- SNMPv3 будет рассмотрен чуть позже.

snmptrap: посылка и принятие TRAP’ов, реагирование на них

При её получении snmptrapd выведет такой текст на экран: Формат INFORM’ов SNMPv2 отличен от формата TRAP’ов SNMPv1 и выглядит подобным образом: Это определение аналогично TRAP’у SNMPv1 что рассматривали выше. Так выглядит вызов INFORM’а SNMPv2:

получаем такой вывод от snmptrapd : и такой вывод нашей handler-программы:

вызов нашей enterprice specific TRAP’ы даёт такой вывод handler-программы:

Отправка и приём TRAP’ов и INFORM’ов для SNMPv3

TRAP’ы и INFORM’ы более гибки при использовании SNMPv3 благодаря отличной реализации базы пользователей. Сообщения SNMPv1 и SNMPv2c, использующие community-строки, выдают информацию любому пользователю. SNMPv3 отклоняет запрос, если пользователь отстутствует в базе пользователей SNMPv3. Всё просто, не так ли? За исключением одной небольшой проблемы: база пользователей приложения SNMPv3 описывает пользователей парой значений в виде имени пользователя(называемого «securityName») и идентификатора данного SNMP приложения, с которым осущевствляется связь(зовётся «engineID»). Обычно когда вы используете приложения Net-SNMP(snmpget, snmpwalk и пр.), они сами находят engineID и используют имя пользователя, engineID и пароль в базе пользователей на основе engineID удалённого приложения. Потом будет проще
SNMPv3 INFORM’ы

Вывод будет аналогичен предыдущему примеру.
Далее должно идти долгое объяснение про v3 engineID, INFORM’ы, TRAP’ы, обнаружение engineID, секретные ключи, пароли, локальные ключи и пр. Всё это безобразие занимает 18223 строк текста в RFC 2570-2575, потому не будем повторяться здесь.

Использование локальных MIB-файлов

Работает!
Ещё один момент: вы можете набрать эту команду другим способом(такой набор наиболее предпочтителен и рекомендуется ведущими разработчиками Net-SNMP):

Опции специфичные для SNMPv3

Рассмотрим детальнее вывод последней команды.
— Каждый пользователь имеет имя(securityName), тип аутентификации(authProtocol), тип privacy(privProtocol), а также ключи аутентификации(authKey) и privacy(privKey).
— Аутентификация происходит путём подписывания отправляемого сообщения с помощью authKey. authProtocol на сегодняшний день может быть MD5 или SHA, тогда как authKeys и privKeys генерируются из парольной фразы длиной не менее 8-ми символов
— Аутентификация происходит с применением пользовательского privKey для шифрования данных отсылаемого сообщения. privProtocol может быть AES или DES.
Сообщения могут быть отосланы неаутентифицированными, аутентифицированными, или аутентифицированными и зашифрованными в зависимости от значания securityLevel.
Таблица ниже описывает, как все эти значения могут быть указаны в командной строке. Вы также можете прописать значения по умолчанию в файл

Примеры
Пример запроса без аутентификации (как минимум, требуется указать имя пользователя):

Запрос с аутентификацией:

И наконец, запрос с аутентификацией и шифрованием:

Конечно же они все выглядят похоже т.к. работают подобным образом. Но хост в примерах выше позволял использовать любой уровень аутентификации. Хосты, что вы будете настраивать, должны иметь более жёсткие правила безопасности и иметь хотя бы authNoPriv уровень при настройке VACM контроля доступа. И в завершении, пропишем snmp.conf подобным образом: Таким образом все аргументы, используемые нами ранее в командной строке, будут автоматически браться из этого файла:

Опции влияющие на формат вывода

Несколько примеров использования этой возможности:

-On
Данный флаг позволяет выводить OID’ы в числовом формате вместо текстового:

-Oe
Этот флаг определяет, нужно ли показывать обяснение(перед числом в скобках) полученного числового значения:

-Ob
Многие SNMP таблицы используют в качестве индекса строки. Затем строки транслируются в OID сегменты для выполнения SNMP запроса. Давайте попробуем разобраться в этом на следующем примере. Рассморим OID usmUserEntry:

Источник

Пытаемся сделать мониторинг по SNMP действительно простым

Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.

Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:

Шаг 1: добавляем MIB-файлы

Прежде всего необходимо разобраться с MIB-файлами. Описание логики связей между элементами данных и их синтаксиса было в SNMP реализовано при помощи этих файлов с целью уменьшения нагрузки на сеть и упрощения реализации агентов. Пользователи, однако, далеко не всегда хотят разбираться с их внутреннем устройстве.

Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:

Во время загрузки файлов происходит их автоматическая компиляция. Встроенный редактор MIB-ов с подсветкой синтаксиса имеется лишь на случай появления MIBов, не соответствующих спецификации. Пользоваться им нужно крайне редко.

Шаг 2: подключаем SNMP-устройство

В случае построения классической системы мониторинга этот шаг обычно не требуется, так как все устройства добавляются в систему автоматически во время периодического обнаружения устройств (network discovery). Тем не менее, во время добавления обнаруженных сканированием сети устройств выполняются примерно те же шаги:

Шаг 3: изучаем снимок устройства

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

В этом снимке сосредоточена практически вся суть нашего подхода к работе с данными SNMP. Прежде всего, он всегда содержит «под рукой» все реальные данные устройства. При этом все данные считываются только один раз, последующий опрос идет только по важным метрикам. Полное перечитывание снимка устройства производится раз в сутки, для снижения нагрузки на сеть его можно вообще отключить. Снимок устройства опционально сохраняется в БД при перезапуске системы мониторинга.

Обычно не требуется прибегать к помощи каких-либо внешних утилит когда требуется найти подходящие данные для мониторинга по их описаниям в MIB-файле или значениям. Все данные уже сгруппированы по MIB-файлам, однако можно сгруппировать их и по иерархии OID-ов:

Чтобы посмотреть подробное описание любой метрики или таблицы, содержащееся в MIB-файле, достаточно навести мышкой на описание или значение метрики. Во всплывающей подсказке также виден тип данных SNMP и полный OID:

Если метрика может принимать одно из нескольких числовых значений, описанных в MIB-файле текстовыми константами, в снимке устройства сразу показывается соответствующая текущему значению константа. Полный список констант и их числовых значений доступен через контекстное меню:

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

Но наибольшую пользу наш метод работы с данными SNMP приносит при обработке таблиц. Каждая SNMP-таблица показывается в снимке устройств как отдельная метрика табличного типа:

Редактирование данных в таблицах можно производить прямо по время просмотра, например для отключения сетевого интерфейса достаточно поменять значение поля ifAdminStatus в соответствующей строке.

При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:

Если имеется несколько связанных друг с другом таблиц, например использующих внешние индексы или расширение (augmentation), система автоматически обрабатывает все внутренние связи и сводит данные связанных таблиц в одно целое. В большинстве случаев пользователи даже не подозревают о существовании таких сложностей. Вот, например, как выглядит таблица hrSWRunPerfTable:

На уровне MIB файла эта таблица представляет из себя два столбца (hrSWRunPerfCPU и hrSWRunPerfMem), расширяющие таблицу hrSWRunTable. В снимке устройства эти таблицы уже объединены, что облегчает анализ данных, построение отчетности и диаграмм, настройку хранения и т.д.

Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.

Шаг 4: настраиваем периоды опроса и сроки хранения

AggreGate Network Manager является одновременно платформой и коробочным продуктом, поэтому в большинстве случаев после автоматического или ручного добавления устройства периоды опроса и сроки хранения метрик уже преднастроены для всех метрик и таблиц, которые система «понимает», т.е. показывает на инструментальных панелях и анализирует на предмет необходимости генерации тревожных сообщений.

Откорректировать настройки опроса (синхронизации) и хранения метрики можно через ее контекстное меню, либо через настройки аккаунта (для всех метрик сразу).

В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate. На тему создания каналов статистики, которые перекладывают метрики и части таблиц в кольцевую БД, будет отдельная статья.

Шаг 5: переходим к обработке и визуализации данных

Когда данные собираются и сохраняются в БД сервера, можно приступать к их использованию для дела, то есть для мониторинга и управления ИТ инфраструктурой. Контекстное меню любой метрики в снимке устройства предоставляет доступ к визардам, позволяющим начать настройку тревог, отчетов, графиков, запросов, инструментальных панелей, и других средств анализа и визуализации.

При помощи этих средств настраивается влияние метрик и таблиц на общесистемные операции поиска причин отказов, анализа производительности, планирования и инвентаризации, управления конфигурациями, и других функций системы. Попутно «рисуются» различные интерфейсы:

В результате

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

При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.

Безусловно, нам еще есть над чем поработать. Требуется улучшение механизмов выбора индивидуальных метрик, чтобы избежать даже единократного опроса целых MIBов. Есть необходимость исключения из опроса индивидуальных строк и столбцов SNMP-таблиц. Нам интересно было бы услышать и о других недостатках процесса настройки SNMP-мониторинга в нашей системе.

А поподробнее?

Эта статья вообще не касается получения, обработки и отправки ловушек SNMP, работы по SNMP v3, и многих других аспектов.

Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP, который состоится 26 мая 2015 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи SNMP.

Источник