Snmp что это простыми словами
Протокол управления SNMP
Для регулирования устройств в IP-сетях нередко применяется SNMP. Эта аббревиатура расшифровывается как Simple Network Management Protocol. По сути, это стандартизированный интернет-протокол, который помогает отследить используемые сетевые устройства: маршрутизаторы, адаптеры, коммутаторы и т. д. Основное условие, чтобы оборудование было включено через IP и использовали определенное программное обеспечение.
Разберемся, как работает протокол SNMP, из каких компонентов он состоит и какие версии используются.
Подробнее о протоколе
SNMP является протоколом прикладного уровня, который необходим для обмена информацией между несколькими сетевыми машинами. Это не просто приложение, а свод используемых правил, который является частью модели TCP/IP. Протокол контролируется и управляется IETF.
При помощи протокола сисадмин может выполнять мониторинг сети, чтобы оценить ее производительность и изменить конфигурацию устройств. Поэтому SNMP стал довольно распространен и его применяют в сетях любого типа и объема. Причем чем больше сеть, тем лучше удается использовать функционал приложения. Он позволяет не только просматривать, но и управлять сетью через единый интерфейс.
Основное преимущество протокола – наличие интерфейса с автоматическими оповещениями и другими командами. Это избавляет от необходимости ручного ввода всех команд.
Архитектура
Разобравшись в вопросе, что такое SNMP, можно перейти к рассмотрению его архитектуры. Она состоит из следующих компонентов:
1. Сетевая станция управления.
Подробнее поговорим о каждом элементе. Начать стоит с сетевой станции управления, или Network Management Station. Именно NMS позволяет отслеживать используемые устройства, анализировать сведения, собранные мастер-агентами, определять производительность системы и создавать графические отчеты на основе полученных данных. Встроенный менеджер используется для прямой связи с агентами протокола.
2. Агенты.
Эта группа компонентов включает в себя ряд подгрупп. Начнем с мастер-агентов, которые служат для связи сетевых менеджеров и субагентов. Они анализируют поступающие запросы и отсылают их субагентам, затем получают информацию, создают ответ и отсылают его менеджеру.
Если запрос некорректен, неверно сформулирован или информация закрыта для доступа, то мастер-агент отправляет уведомление об этом.
Другой вид агента – это субагент. Он представляет собой специальное программное обеспечение, которое поставляется вендором вместе с сетевой машиной. Субагент получает запросы от мастер-агента и потом обратно пересылает ему собранную информацию. Соответствующий субагент используется вместе с отдельным управляемым компонентом.
3. Управляемые компоненты.
Представляют собой подключенные к сети компьютеры и устройства или специальное ПО, имеющее встроенный субагент. К числу устройств могут относиться коммутаторы, маршрутизаторы и серверы, а также современные гаджеты. Что касается ПО с субагентами, то к нему относят антивирусные программы, серверы резервного копирования и т. д.
Также в качестве компонентов протокола SNMP стоит выделить MIB и OID. Первый термин обозначает базу управляющей информации, в ней содержатся сведения об оборудовании. Каждая сетевая машина имеет свою таблицу с MIB-данными, в ней – данные о состоянии картриджа (у принтеров), о поступающем трафике (у коммутатора) и т. д.
OID представляет собой идентификатор объекта. MIB снабжается своим уникальным ID, который и позволяет идентифицировать устройство. OID существует в числовом виде, по сути – это числовой аналог существующего пути к файлу.
Принципы работы
Теперь подробнее поговорим о назначении и принципе действия протокола SNMP. Изначально протокол разрабатывался как инструмент для управления глобальной сетью. Однако благодаря гибкой структуре удалось приспособить SNMP для всех устройств сети и осуществлять контроль, наблюдение и настройки при помощи единой консоли. Все это послужило распространению протокола и его активному применению.
Работа SNMP строится на обмене информацией между менеджерами и агентами. Этот процесс осуществляется посредством протокола UDP. Реже используется TCP или протокол MAC-уровня.
В SNMP используется семь различных вариантов PDU, которые отвечают за получение данных с устройства, изменение или присваивание новых сведений, уведомления об ошибках, извлечение данных и т. д.
PDU состоит из конечного набора полей, в которых прописывается нужная информация. В частности, это поля:
Функционирование SNMP подразумевает использование специальных сетевых портов. По умолчанию – это UDP-порты 161 и 162. Запросы поступают на порт SNMP 161. Далее с него отправляется ответ менеджеру. При отправке запроса он идентифицируется при помощи ID, что в дальнейшем позволяет связать запрос менеджера с поступившим ответом.
Порт 162 отвечает за прием ловушек агента. При использовании DLTS и TLS агент использует для пересылки сообщений порт 10162, а менеджер – 10161.
Мы подошли еще к одному важному элементу, который необходим для функционирования SNMP. Речь о ловушках, которые представляют собой способ коммуникации. Агент использует ловушки (Trap) в тех случаях, когда нужно сообщить менеджеру о каком-либо событии. Делается это по той причине, что менеджеры нередко отвечают за определенное количество устройств и несколько управляемых компонентов, поэтому не всегда могут вовремя отследить возникновение ошибки.
При получении ловушки, то есть уведомления, менеджер может выбрать нужное действие. Уведомления, которые присылает ловушка, обозначаются цифрами от 0 до 6. Код ошибки указывает на группу, к которой относится неполадка.
В SNMP используется два вида ловушек – помимо Trap, это еще и Inform. Разница в том, что второй тип ловушек предполагает подтверждение менеджера о ее получении.
Особенности применения
SNMP позволяет сисадмину работать с различными приложениями и облачными сервисами. Протокол имеет функционал для выполнения следующих операций:
Существующие версии
Разработано три версии протокола, которые получили соответствующие названия – SNMPv1, SNMPv2c и SNMPv3. Все они активно используются даже сегодня, однако самой распространенной остается вторая версия. Расскажем о каждой разновидности подробнее:
Вопросы безопасности
Протокол SNMP создавался в те времена, когда угроза взлома и несанкционированного доступа к данным была практически нулевой. Поэтому разработчики не уделяли этой проблеме особого внимания. Версия SNMPv1 практические не имеет защиты от взлома, чем могут воспользоваться злоумышленники.
Вторая версия разрабатывалась с учетом анализа предыдущих недочетов и ошибок протокола. Эта версия SNMP стала более безопасной, однако на деле ее сложно назвать самой стабильной и надежной.
Практически все ошибки безопасности удалось решить только в третьей версии. Для обеспечения безопасности в протоколе применяется несколько моделей: Community-based, Party-based и User-based Security.
Выводы
Сегодня протокол SNMP является наиболее простым и эффективным методом сбора и передачи данными между сетевыми устройствами, мониторинга и управления их работой. Особенно актуальным применение такого протокола является при совмещении устройств, функционирующих на разном ПО и выпущенных разными вендорами. SNMP прост в работе, достаточно надежный, а самое главное – полностью бесплатный для использования. Этим не может похвастать практически ни один существующий набор правил.
Остались вопросы по работе SNMP? Специалисты Xelent обязательно ответят на них – оставьте заявку на сайте или свяжитесь с нами по указанным телефонам.
Протокол SNMP – что это такое и как использовать для мониторинга
Расшифровать аббревиатуру SNMP можно как Simple Network Management Protocol, то есть «простой протокол сетевого управления». Этот стандарт является одним из самых часто встречающихся при управлении устройствами в сети. В большинстве случаев этот протокол может быть использован в случаях, когда требуется контролировать исполнение на устройствах подключенных к сети заданных администратором требований. Данные, которые входят в обмен в рамках SNMP представляются в виде переменных. Благодаря им появляется возможность описания настройки управляемого объекта. Благодаря управляющим приложениям могут подаваться запросы, а в некоторых случаях и указываться переменные.
Возможности протокола
Основной особенностью данного протокола является удаленная настройка устройств в сети с помощью главного компьютера без использования стороннего ПО. В ходе управления сетевыми процессами можно проводить работу не только с определенными процедурами, но и наблюдать за производительностью в целом, проводить мониторинг ресурсов, а также определять возникающие неполадки в инфраструктуре. Поэтому протокол SNMP пользуется большой популярностью среди системных администраторов.
Основные составляющие SNMP
Самые распространенные составляющие:
Информация из объекта будет отправляться на управляющую программу, которая будет интерпретировать ее по заданным алгоритмам. На подчиненном устройстве существует программа агент, предназначенная для организации сбора информации по определенному устройству. Если нужно – программа (ПО) может транслировать эту информацию в формате, адаптированном к особенностям SNMP.
Сама система обеспечения взаимодействия между объектами в сети позволяет администратору работать сразу со многими управляющими программами. Это дает возможность полностью контролировать функционирование инфраструктуры. В сетях могут быть установлены сразу несколько типов такого ПО.
Самым важным элементом считается база управляющих сведений “MIB”. Этот элемент нужен для того, чтобы описать структуру базы данных (БД), что необходимо при обмене информацией в ходе администрирования девайсов. Такая БД дает возможность сохранить данные о компонентах, которые активируются на устройстве для управления им.
Главной составляющей базы являются идентификаторы типа OID, которые позволяют задавать переменные, определяемые и считываемые благодаря SMNP.
Возможности управляющих программ
Такой тип программ дает право на управление группами различных девайсов, расположенных в одном сетевом пространстве. Управляющая программа может работать только в том случае, если ее приложение-агент установлен на всех подчиненных устройствах. Приложение отправляет на сервер администратора нужные данные с помощью SNMP. На главном ПК в это же время функционирует программа-менеджер, которая отвечает за обработку поступающих с приложений-агентов сведений.
Примеры программного обеспечения
Существуют подобные программы, которые адаптированы к использованию на ОС Windows и Solaris. Рассмотрим некоторые из них.
Пакет SNMP от Castle Rock Computing
Это безопасная система сетевого управления, обеспечивающая постоянное наблюдение для всей сети.
Основные характеристики продукта:
Интерфейс программы:
Polygon SNMP Manager
Программа предназначена для контроля и управления сетевыми устройствами с использованием протокола SNMP.
SNMP Explorer
Утилита для исследования и мониторинга предназначенная для агентских систем. Она предоставлена в стиле проводника в MIB, который открыт на агенте. Имеет самый простой интерфейс из всех представленных, но также и самая сложная в использовании.
Особенности работы базы данных MIB
Главный процесс во время работы MIB – адресация переменных. Происходит она с учетом строения определенного элемента протокола. MIB имеет структуру в виде дерева, состоящую из совокупности элементов за каждым из которых закреплен уникальный ID.
В рамках базы MIB имя переменной отражает адрес до нее, начиная от корневого каталога. В структуре переменной могут храниться разнообразные данные, такие как продолжительность функционирования девайса. В MIB могут содержаться ветви с которыми может работать множество устройств, а также ветви, которые добавляет компания-разработчик, либо компания в которой проходит внедрение.
Перед введением структуры базы данных в работу нужно присвоить уникальный номер созданному набору переменных. Благодаря этому инженеры или администраторы, работающие с мониторингом, могут создать новую ветвь в структуре, которая позволит разместить переменные только от своего подразделения.
Что такое OID
OID – ID объекта, необязательный атрибут сертификата, предоставляющий дополнительную информацию о владельце, ключах, или несущий дополнительные данные для сервисов, которые используют этот сертификат.
Чаще всего OID используют для управления доступами на основе ролей. К примеру, в сертификате можно указать владельца ключа и информацию о нем. Благодаря этому его можно будет идентифицировать во всех информационных системах, а также он сможет получить доступ к нужным данным, исключая запросы на предоставление разрешений. Это возможно в тех случаях, когда во всех информационных системах используется сертификат пользователя для авторизации и одинаково анализируется один и тот-же атрибут.
Что такое ловушка SNMP
SNMP-ловушка — знак, который подает девайс, поддерживающий протокол SNMP. Ее основное назначение – сообщать администратору о чрезвычайных происшествиях в сети.
Пример: отдельные типы источников бесперебойного питания посылают такие сигналы во время смены устройством типа питания на питание от аккумуляторов, а не от сети. В большинстве случаев это требует скорейших действий и потому сообщение отправляется устройством по протоколу SNMP самостоятельно. Также к таким ловушкам стоит отнести отдельные марки датчиков вскрытия помещений. Эти датчики возможно подключить к сети, если нужно получать сигнал об открытии дверей.
В службах Windows также существует служба с названием “Служба ловушек SNMP”, выполняющая те же функции. На компьютерах, которые не подключены к локальной сети она не используется, но обычно включена. Для ее отключения необходимо зайти в “Пуск – Панель Управления – Администрирование – Службы” и в открывшемся списке найти указанную службу. Кликнуть по ней правой кнопкой мыши (ПКМ), далее “Свойства”, затем сменить “Тип запуска” на “Отключена”.
Инсталляция и конфигурирование SNMP
Инсталляция службы
Необходимо сделать следующее:
Затем перейти к службам Windows и проделать следующее:
Пытаемся сделать мониторинг по 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.
Почему SNMP это не очень просто?
Читаем документацию
The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and
minimizing the amount of traffic generated by the network management function.
Для тех, у кого сложности с английским языком, имеется русский перевод:
Стратегия SNMP заключается в том, что мониторинг состояния сети с любым значимым уровнем детализации выполняется главным образом путем опроса из центра мониторинга. Ограниченное число незапрашиваемых сообщений (trap — прерывание) обеспечивает синхронизацию и активизирует опросы. Ограничение числа незапрашиваемых сообщений согласуется с задачами обеспечения простоты и минимизации трафика, создаваемого системой сетевого управления.
Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.
Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki.
Первые шаги
Помимо обязательного ознакомления с документацией, важно понимать, для чего мы все это делаем. В практике телекома, наиболее часто встречаются следующие задачи:
Задача SNMP-мониторинга выделяется на общем фоне требованием того, что опрашиваемого оборудования много или очень много. Предположим, что именно эту задачу нам и предстоит решать.
Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:
Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):
Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось — значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?
Подсчитали — прослезились
Не совсем. Вспоминаем о том, что нам предстоит выполнять много запросов. Давайте промеряем, сколько запросов мы можем выполнить в секунду? Внесем небольшое исправление в код:
И запустим его на выполнение:
Почти две с половиной тысячи запросов в секунду! Неплохо?
Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:
Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?
Будет несколько попыток доступа (в нашем коде мы задали 3) разделенных таймаутом (1000 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.
Идем на рекорд
Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.
Как перейти к асинхронному варианту? В нашем случае, довольно просто:
Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?
Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:
Проанализируем результат выполнения:
Мы успеваем сформировать 9174 запросов в секунду, а опрашиваемое устройство успевает обрабатывать запросы со скоростью 283 запроса в секунду. На большую часть запросов оно ответить не успевает (соответственно в логе остаются сообщения «Timeout exceeded»). Разумеется, это не будет проблемой когда мы начнем опрашивать большое количество устройств с разумным интервалом между запросами.
Идем далее
Мы научились получать по SNMP значения скалярных переменных. Но, помимо них, в SNMP есть еще и таблицы (например таблица интерфейсов на устройстве). Как они устроены? Посмотрим MIB-browser:
В OID mgmt.interfaces (1.3.6.1.2.1.2) мы видим скалярную переменную ifNumber (1.3.6.1.2.1.2.1), содержащую количество интерфейсов в таблице, а также набор столбцов. Каждый из столбцов имеет собственный OID. Например столбец содержащий числовой индекс ifIndex интерфейса имеет OID = 1.3.6.1.2.1.2.2.1.1.
Для того, чтобы получить значение этой переменной, необходимо добавить к OID-у индекс интерфейса (например для интерфейса с индексом 123 OID = 1.3.6.1.2.1.2.2.1.1.123). Но как нам получить индексы интерфейсов? Они совсем не обязательно идут по порядку! Например, на моей машине, таблица интерфейсов выглядит так:
Именно для этой цели был придуман запрос GETNEXT. Передавая в этот запрос префикс OID-а, мы получаем OID и значение следующей (в лексикографическом порядке) за этим префиксом переменной. Это означает, что передав префиксы OID-ов столбцов таблицы, мы получим OID-ы и значения первой ее строки. Чтобы получить следующую строку, надо выполнить еще один запрос, передав в него OID-ы, полученные предыдущим запросом. И так до тех пор, пока мы не просмотрим всю таблицу.
Разумеется, с учетом всего сказанного выше, нам следует минимизировать количество запросов (это также необходимо с учетом того, что в рамках одного запроса, согласно RFC, предоставляются консистентные данные, если мы запросим индекс и имя интерфейса двумя последовательными запросами, они возможно не будут соответствовать друг-другу). В рамках 1-ой версии SNMP, мы должны читать всю строку таблицы одним запросом.
Следует заметить, что довольно удобно то, что OID-ы скалярных переменных также представляют собой префиксы. Например, для переменной sysUpTime OID, на самом деле равен 1.3.6.1.2.1.1.3. Мы можем передать его в GETNEXT запрос и получить OID = 1.3.6.1.2.1.1.3.0 вместе с соответствующим значением. Это дает возможность запрашивать скалярные значения вместе с значениями столбцов таблиц, в одном запросе.
Запустив этот код на выполнение, мы получим следующий response:
Мы получили значение uptime-а, индекс первого интерфейса и его имя, закодированное строкой октетов в шестнадцатеричном представлении. Чтобы получить следующие строки, мы должны выполнять последовательные запросы, передавая ранее полученные OID-ы.
С учетом необходимости поддержки возможности асинхронной обработки, это может стать нетривиальной (но вполне решаемой) задачей. К счастью, во 2-ой версии SNMP были добавлены bulk-запросы, автоматизирующие получение табличных данных и минимизирующие количество отсылаемых при этом запросов. Внесем необходимые изменения в код:
Выполнив этот запрос, мы получаем все строки таблицы одним запросом:
Разумеется, если таблица содержит более затребованных 50-ти строк, вновь (как и для 1-ой версии SNMP) потребуется формировать запросы для получения последующих строк, передавая в них OID-ыполученные для последней строки.
О чем я не рассказал?
В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.
Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP — это не просто.