как узнать oid snmp устройства

Как читать 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 и т.п.

Источник

Руководство по командам 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:

Источник

Zabbix Documentation 5.4

Sidebar

Table of Contents

3 Обнаружение SNMP OID’ов

Обзор

В этом разделе мы выполним обнаружение SNMP на коммутаторе.

Ключ элемента данных

Обнаружение SNMP OID’ов поддерживается начиная с Zabbix сервера/прокси 2.0.

Для настройки правила обнаружения, выполните следующее:

Все обязательные поля ввода отмечены красной звёздочкой.

OID’ы для обнаружения добавляются в поле SNMP OID в следующем формате: discovery[<#МАКРОС1>, oid1, <#МАКРОС2>, oid2, …,]

где , … допустимые имена низкоуровневых макросов и oid1, oid2… являются OID’ами способными сгенерировать осмысленные значения для этих макросов. Встроенный макрос содержит индекс обнаруженного OID, который применяется к обнаруженным объектам. Обнаруженные объекты группируются по значению макроса .

Для понимания того, что мы имеем в виду, давайте выполним несколько раз snmpwalk на нашем коммутаторе:

И зададим SNMP OID равным: discovery[<#IFDESCR>, ifDescr, <#IFPHYSADDRESS>, ifPhysAddress]

Теперь это правило будет обнаруживать объекты с макросом <#IFDESCR>равным WAN, LAN1 и LAN2, макросом <#IFPHYSADDRESS>равным 8:0:27:90:7a:75, 8:0:27:90:7a:76, и 8:0:27:2b:af:9e, макросом <#SNMPINDEX>равным индексам обнаруженных OID 1, 2 и 3:

Если обнаруженный объект не имеет указанный OID, тогда по этому объекту соответстующий макрос пропускается. Например, если у нас есть следующие данные:

Тогда, в случае SNMP обнаружения discovery[<#IFDESCR>, ifDescr, <#IFALIAS>, ifAlias] вернется следующая структура:

Прототипы элементов данных

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах элементов данных:

Опять же, вы можете создать столько прототипов элементов данных, сколько необходимо:

Прототипы триггеров

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах триггеров:

Прототипы графиков

Следующий скриншот иллюстрирует каким образом мы можем использовать эти макросы в прототипах графиков:

Результат нашего правила обнаружения:

Обнаруженные объекты

Когда сервер выполнит правило обнаружения, будут созданы реальные элементы данных, триггеры и графики на основе значений, которые вернет правило обнаружения SNMP. В настройках узла сети эти объекты будут иметь префикс с оранжевой ссылкой на правило обнаружения, с которого пришли эти объекты.

Источник

Создание пользовательских OID для мониторинга систем на Caché с помощью SNMP

TEST>zw x
x= [2@metrics.snmp.Metrics]
+—————— general information — | oref value: 2
| class name: metrics.snmp.Metrics
| reference count: 2
+—————— attribute values — | ExecutedSpeed = 1155679
| GloRefSpeed = 171316
| KeyExpirationDate = «2014-10-11»
| KeyLicenseUnits = 100
| RoutineLoadSpeed = 186
| Sessions = 1

TEST>d ^%SYSMONMGR
1. Выбираем пункт 5, Manage Application Monitor.
2. Выбираем пункт 2, Manage Monitor Classes.
3. Выбираем пункт 3, Register Monitor System Classes. Наблюдаем за компиляцией:

Экспорт в XML начался в 08/18/2014 16:00:51
Экспортируемый класс: Monitor.Sample
Экспорт успешно завершен.

Загрузка началась в 08/18/2014 16:00:51
Загрузка файла /opt/intersystems/ensemble/mgr/Temp/45DDB3FppRHCuw.stream как xml
Импорт класса: Monitor.Sample
Компиляция класса: Monitor.Sample
Компиляция программы:: Monitor.Sample.G1.MAC
Компиляция таблицы: Monitor.Sample
Компиляция программы: Monitor.Sample.1
Загрузка успешно завершена.

4. Выбираем пункт 1, Activate/Deactivate Monitor Class
Class??
Num MetricsClassName Activated
1) %Monitor.System.AuditCount N
…
15) metrics.snmp.Metrics N

Class? 15 metrics.snmp.Metrics
Activate class? Yes => Yes

5. Выбираем пункт 6, Exit
6. Еще раз выбираем пункт 6, Exit
7. Выбираем пункт 1, Start/Stop System Monitor
8. Выбираем пункт 2, Stop System Monitor
Stopping System Monitor… System Monitor not running!

9. Выбираем пункт 1, Start System Monitor
Starting System Monitor… System Monitor started
10. Выбираем пункт 3, Exit
11. Выбираем пункт 4, View System Monitor State
Component State
System Monitor OK
%SYS.Monitor.AppMonSensor

3. Создаем пользовательский MIB
Пользовательский MIB создается с помощью методов класса MonitorTools.SNMP. Для примера PEN (Private Enterprise Number) возьмем фиктивныЙ, 99990, впоследствии PEN нужно зарегистрировать в IANA. Посмотреть уже зарегистрированные номера можно здесь. Например, PEN InterSystems имеет номер 16563.
16563
InterSystems
Robert Davis
rdavis&intersystems.com
Для создания MIB-файла мы будем использовать класс MonitorTools.SNMP, в частности, метод CreateMIB(). Этот метод принимает на вход 10 аргументов:

Собственно, создание MIB-файла:

%SYS>d ##class(MonitorTools.SNMP).CreateMIB(«Monitoring»,«TEST»,99990,42,«fiction»,«fict»,«fiction»,«ISC-TEST»,,1)
Create SNMP structure for Application — Monitoring
Group — Metrics
ExecutedSpeed = Integer
GloRefSpeed = Integer
KeyExpirationDate = String
KeyLicenseUnits = Integer
RoutineLoadSpeed = Integer
Sessions = Integer

Create MIB file for Monitoring
Generate table Metrics
Add object ExecutedSpeed, Type = Integer
Add object GloRefSpeed, Type = Integer
Add object KeyExpirationDate, Type = String
Add object KeyLicenseUnits, Type = Integer
Add object RoutineLoadSpeed, Type = Integer
Add object Sessions, Type = Integer
MIB done.

В каталоге /mgr/TEST появился новый MIB ISC-TEST.mib.

Маленькую статью по конфигурационному файлу snmpd.conf в дополнение к ману можно посмотреть на cyberciti. Вот наша конечная настройка:

]# yum install net-snmp
[root@server

Рестартуем в Linux демонов snmpd и snmptrapd. Стартуем ^SNMP сервис для начала работы SNMP-субагента от Caché:
%SYS>d start^SNMP

5. Проверяем, что наши, только что созданные, пользовательские OID’ы доступны.
Это можно сделать с помощью snmpwalk — покажем OID, отображающий количество CSP-сессий:

В файле ISC-TEST.mib указана последовательность наших OID:

FictMetricsR ::=
SEQUENCE <
fictExecutedSpeed Integer32,
fictGloRefSpeed Integer32,
fictKeyExpirationDate DisplayString,
fictKeyLicenseUnits Integer32,
fictRoutineLoadSpeed Integer32,
fictSessions Integer32
>

Соответственно, например, число сессий — это последний OID 1.3.6.1.4.1.99990.42.1.1.1.6. Можно сравнить с количеством сессий, показываемых SMP-дашбордом:

6. Добавляем наши OID’ы в стороннюю систему мониторинга.
Например, возьмем Zabbix. Документацию по Zabbix можно найти здесь. По инсталляции и настройке Zabbix конкретно на CentOS можно посмотреть здесь. Zabbix был выбран как система, позволяющая не только рисовать графики, но и мониторить Plain Text (в нашем случае, это срок действия лицензии и мощность лицензии по пользователям). После добавления наших 6-ти метрик к Items нашего локального хоста и создания 4-х графиков и 2-х PlainText параметров (как элементов screen) видим такую картину (приведен пример небольшой «живой» системы):

Вверху — информация о том, когда лицензия заканчивается, и сколько мы имеем лицензионных слотов. Графики говорят сами за себя.

7. Добавляем запуск системного монитора в нашей области TEST при старте системы
Есть неплохой документ об использовании пользовательских рутин, срабатывающих при старте и остановке Caché. Называются они соответственно %ZSTART и %ZSTOP.
Что нас во всем этом интересует, так это чтобы при старте поднимать в пользовательской области TEST системный монитор (^%SYSMONMGR). По умолчанию этот монитор стартует только в области %SYS. Соответственно, рассматривать будем только программу ^%ZSTART. Исходник %ZSTART.mac (создаем и сохраняем ее в области %SYS).

Рестартуем (по возможности) Caché, чтобы убедиться, что сбор SNMP-статистики после рестарта Caché продолжается.
На этом все. Возможно, у кого-то будут замечания по выбору параметров мониторинга или коду, но задача ставилась показать возможность такого мониторинга в принципе, а добавить нужный параметр или отрефакторить код всегда можно в дальнейшем.
Спасибо за внимание!

Источник