Если для общения по SNMP со своими «железками» вы начинаете поиск не в документации бренда а ищете mib файлы для нее, эта статья не для вас.
Ну а если слова SNMP, Net‑SNMP, snmpwalk, snmpget вам уже встречались, но открыв любой «*.mib» вы предпочитаете его закрыть и обратиться к какому либо из mib browsers - вам стоит это почитать.
Небольшое предисловие
Книга «Основы SNMP» издательства Символ (O»REILLY в оригинале), стояла на моей книжной полке много лет, иногда что то в ней смотрел, но первые главы с теорией были абсолютно непонятной тяжелой информацией. Пока не было реальной потребности, это было как читать о «сферическом коне в вакууме»
Лет 5 назад дошли руки до установки Zabbix в организации. И, если шаблоны для коммутаторов и маршрутизаторов легко поправил, меняя некоторые OID в зависимости от модели, выискивая их с помощью snmpwalk, то взявшись за только что установленные Системы Гарантированного Питания (СГП) Huawei ETP-48/200(60) понял, что без MIB файлов не обойтись. Шаблон Zabbix делал «с нуля».
Сопоставление web‑интерфейса:
и выгрузки всего дерева информации с помощью snmpwalk в файл не помогло, железка мне была незнакома совсем, аналогии не помогали. На github»e был найден HUAWEI‑SITE‑MONITOR‑MIB.txt, почти подходящий для наших СГП, но я и его, как сейчас понимаю, использовал бездарно — превратил в Excel файл вида OID <→ «его название».
Но мне все равно это сильно помогло, СГП я мониторю уже Zabbix»ом.
Стал вопрос о шаблоне для аппаратуры ВЧ связи ССТМ «ES100» (система связи и телемеханики), взгляд упал на вышеназванную книгу и теория вдруг оказалась очень понятной. (После создания то с нуля шаблона для Zabbix sic!)
Итак, как лучше “понимать” свои железки используя их MIB файлы
Я небуду расписывать с нуля что такое SNMP, OID, как установить snmpwalk, snmpget и т. п. Информации в сети предостаточно.
Здесь, на Хабре есть прекрасная статья SNMP MIBs и как их готовить где описан другой подход к «ковырянию» в MIB но там уже требуется понимание «что внутри у животинки»
Но, по порядку.
Говоря о разных параметрах устройств, поддерживающих SNMP, пользуются термином информация для управления. Но из чего она состоит и как представлена?
Для описания этого существует целый стандарт «The Structure of Management Information ver. 1/Структура информации для управления» (SMIv1, RFC1155) и дополнения для SNMPv2 (SMIv2, RFC 2578). Если не указано, я буду использовать определения SMIv2, он сейчас встречается гораздо чаще.
Определение управляемых объектов может содержать три атрибута:
Имя
Имя, или идентификатор объекта (OID - Object identifier) уникально определяет управляемый объект. Имена обычно бывают двух видов - цифровые и «удобочитаемые».
В любом случае имена получаются длинные и неудобные. В SNMP-приложениях делается очень много работы для того, чтобы помочь нам удобно ориентироваться в пространстве имен.
Тип и синтаксис
Тип данных управляемого объекта определяется при помощи части языка ASN.1 (Abstract Syntax Notation One). ASN.1 - это способ указать, как данные представляются и передаются между менеджерами и агентами в контексте SNMP. Преимущество ASN.1 заключается в том, что он независим от машины. Это означает, что компьютер с ОС Windows может связываться с любым Unix или мэйнфреймом и не беспокоиться о таких вещах, как порядок байтов.
Если интересны подробности, дальше Хабра ходить не нужно, вот очень подробная статья: ASN.1 простыми словами (кодирование типа REAL)
Кодировка
Конкретный управляемый объект кодируется в строку октетов с использованием правил «Basic Encoding Rules» (BER стандарта ASN.1). Правила BER определяют, как объекты кодируются и декодируются, чтобы их можно было транспортировать по среде передачи, например Ethernet.
Имена OID
Все объекты организованы в древовидную иерархическую структуру (только корень root обычно рисуется сверху). Идентификаторы (имена) объектов состоят из ряда целых чисел, определяемых узлами дерева и разделенных точками. Более удобочитаемая форма, состоящая из слов разделенных точками по сути тоже самое, только каждому узлу соответствует свое имя (слово) а наиболее часто употребляемые кусты (куски) дерева описаны одним именем:
так OID .1.3.6.1.2.1.1.2 вместо .iso.org.dod.internet.mgmt.mib-2.sysObjectID описывается как SNMPv2-MIB::sysObjectID (кстати запомните этот OID, к нему вернемся позже)
Начало дерева имен можно представить следующей картинкой
рисовал картинку не сам...
(да я взял ее в блоге компании Selectel, хорошая статья (https://selectel.ru/blog/snmp/) и это не реклама компании - статья просто хорошая
На таких рисунках чаще всего не отображают ветви ccitt(0) и joint(2), это следы зарождения SNMP еще до согласования с международной организацией по стандартизации ISO.
Вот определение поддерева internet и его поддеревьев на языке ANS.1 (именно на нем написаны все MIB файлы, в которых нам предстоит разбираться)
internet | OBJECT | IDENTIFIER | ::= | { iso org(3) dod(6) 1} |
|---|---|---|---|---|
directory | OBJECT | IDENTIFIER | ::= | { internet 1 } |
mgmt | OBJECT | IDENTIFIER | ::= | { internet 2 } |
experimental | OBJECT | IDENTIFIER | ::= | { internet 3 } |
private | OBJECT | IDENTIFIER | ::= | { internet 4 } |
directory сейчас не используется,
experimental зарезервирована для целей тестирования,
mgmt (management) определяет стандартный набор управляемых объектов интернета,
за объекты в private люди и организации отвечают сами.
Если запустить:
без указания какого либо OID, команда вернет все дерево, что найдет перебором по пути .1.3.6.1.2.1. это её поведение по умолчанию. Но это будет общая, стандартная информация, которая нам мало что расскажет о самой “железке”.
Все, что относится к конкретному оборудованию конкретного производителя находится в ветке enterprises и всю информацию из нее можно получить, запустив:
snmpwalk -v 2c -c MySeCrEt IP_addr_host .1.3.6.1.4.1.
или же “спросить поточнее” у самой железки, запросив вышеупомянутый мною OID:
snmpwalk -v 2c -c MySeCrEt IP_addr_host .1.3.6.1.2.1.1.2
вернет, например для Huawei ETP 48/200
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.2011.6.164.1.2
если вам необходимо получить информацию в числовом виде, используйте ключ -On (options numerical) команды snmpwalk, ответ будет
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.2011.6.164.1.2
Кстати вы заметили, что мы спрашивали OID .1.3.6.1.2.1.1.2
а получили OID .1.3.6.1.2.1.1.2.0?
Далее будет сказано подробнее, объекты в SMI могут быть одиночными (скалярами) или организованы в виде таблицы.
sysObjectID именно скаляр - и это является причиной частых ошибок при использовании snmpget
snmpget имеет тот же синтаксис что и snmpwalk но возвращает только один OID, тот что запрошен. Так что при изучении “железок” проще пользоваться snmpwalk, ну или с точностью “до нуля” указывать OID
Описание MIB
Изучать MIB лучше на конкретном примере. Я буду использовать части HUAWEI-SITE-MONITOR-MIB.mib, не самое очевидное может для вас, но тем интереснее - понять что то, с чем не связаны
начнем с заголовков:
HUAWEI-SITE-MONITOR-MIB DEFINITIONS ::= BEGIN
IMPORTS
huaweiUtility
FROM HUAWEI-MIB
OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
Integer32, Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
-- September 15, 2010 at 11:00 GMT
hwSiteMonitorMIB MODULE-IDENTITY
LAST-UPDATED "201103040000Z" -- March 04, 2011 at 00:00 GMT
ORGANIZATION
"Huawei Technologies Co.,Ltd."
CONTACT-INFO
"Floor 5, Block 4, R&D Building,
Huawei Longgang Production Base,
Shenzhen, P.R.C.
http://www.huawei.com
Zip: 518129."
DESCRIPTION
"Site Monitor MIB defines MIB objects which provides load and backup management,
patch management NMS interfaces.
The current version is V1.01"
REVISION "201103040000Z" -- March 04, 2011 at 00:00 GMT
DESCRIPTION
"Add hwAcOffLongTimeAlarmTraps, hwAcOffLongTimeAlarmResumeTraps"
REVISION "201010310000Z" -- October 31, 2010 at 00:00 GMT
DESCRIPTION
"Huawei site monitor mib V1.00"
::= { huaweiUtility 164 }любой MIB файл начинается с импорта из других MIB, (посмотрите на досуге SNMPv2-TC или SNMPv2-CONF вы увидите что такое хорошо структурированная информация),
контактной информации, описания, версий и т.п. и определяет отправную точку этого MIB файла, его положения в дереве.
hwSiteMonitorMIB ::= { huaweiUtility 164 }
и, зная числовое обозначение 1.3.6.1.4.1.2011.6.164 даже не имея под рукой HUAWEI-MIB я могу предположить, что:
huaweiUtility ::= { huaweiMIB 6 }
huaweiMIB ::= { enterprises 2011 }
насчет названия huaweiMIB я могу ошибаться, но смысл понятен.
Далее следует описание текстовых обозначений. Они введены только в SMIv2 и позволяют создавать управляемые объекты более абстрактно.
--
-- Textual conventions
--
DisplayString ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Description."
SYNTAX OCTET STRING (SIZE (1..64))
RowStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Description."
SYNTAX INTEGER
{
active(1),
notInService(2),
notReady(3),
createAndGo(4),
createAndWait(5),
destroy(6)
}Вообще все текстовые обозначения могут быть следующих типов:
Типы текстовых обозначений
обозначение | описание |
DisplayString | Строка символов NVT ASCII не более 255 символов |
PhysAddress | Адрес физического уровня или уровня среды в виде OCTET STRING |
MacAddress | MAC-адрес для IEEE 802 в каноническом формате (с наименьшим значащим битом в начале). В виде 6 октетов |
TruthValue | Булевые значения true или false |
TestAndIncr | Используется чтобы избежать одновременного изменения одного объекта двумя станциями управления |
AutonomousType | OID используемый для определения субдерева с дополнительными определениями |
VariablePointer | Указатель на конкретного представителя объекта например ifDescr для интерфейса 3. В этом случае будет OID ifDescr.3 |
RowPointer | Указатель на строку таблицы. Например ifIndex.3 указывает на третью строку ifTable |
RowStatus | Используется для управления созданием и удалением строк в таблице, так как в SNMP не предусмотрено выполнение этих действий средствами самого протокола, оно создано для обеспечения целостности таблицы когда строка обновляется более чем одним менеджером. Команды и переменные состояний определяются следующими значениями: active(1), notInService(2), notReady(3), createAndGo(4), createAndWait(5) и anddestroy(6) |
TimeStamp | Измеряет время между последней загрузкой системы и каким-либо событием |
TimeInterval | Измеряет период времени в сотых долях секунды. Любые целочисленные значения в диапазоне 0 - 2 147 483 647 |
DateAndTime | OCTET STRING для представления даты и времени |
StorageType | Тип памяти используемой агентом: other(1), volatile(2), nonVolatile(3), permanent(4) и readOnly(5) |
TDomain | Тип транспортной службы |
TAddress | Адрес транспортной службы. Размер определен от 1 до 255 октетов |
Теперь подробнее о синтаксисе определений объектов. Общий вид следующий:
<имя> OBJECT-TYPE
SYNTAX <тип данных>
UnitsParts <дополнительно, см. Дополнения в определении объекта в SMIv2>
MAX-ACCESS <см. Дополнения в определении объекта в SMIv2>
STATUS <см. Дополнения в определении объекта в SMIv2>
DESCRIPTION
“Текстовое описание, характеризующее этот объект”
AUGMENTS { <имя таблицы> }
::= { <Уникальный OID, определяющий этот объект> }
Атрибут SYNTAX обеспечивает определение управляемых объектов. Типы данных просто способ определить какой вид информации может содержать управляемый объект. Эти типы аналогичны тем, которые можно встретить в языках программирования, например C
Типы данных, определенные в SMIv1
Типы данных | Описание |
INTEGER | 32-битное число, используемое для перечисляемых типов данных. Например статус - исправен(1), неисправен(2), тестируется(3). Ноль(0) не должен использоваться в соответствии с RFC 1155 |
OCTET STRING | Строка из нуля или более октетов (байт) обычно используемая для представления текстовых строк а иногда и физических адресов |
Counter | 32-битное число от 0 до 232 - 1 (4 294 967 295). При достижения максимума сбрасывается в 0 и стартует сначала. Используется для отслеживания такой информации, как количество отправленных и полученных пакетов на интерфейсе и т.п. При нормальной работе значение никогда не уменьшается. При перезагрузке стартует с 0 |
OBJECT IDENTIFIER | Строка разделенных точками чисел, представляющая управляемый объект в дереве объектов. Например 1.3.6.1.4.1.9 OID частной структуры Cisco Systems |
NULL | В настоящее время не используется |
SEQUENCE | Определяет списки содержащие ноль или более других типов данных ASN.1 |
SEQUENCE OF | Определяет управляемый объект, состоящий из SEQUENCE (последовательности) типов данных ASN.1 |
IpAddress | 32-битный адрес IPv4. 128 битные адреса IPv6 не рассматриваются ни в SMIv1 ни в SMIv2 |
NetworkAddress | То же самое, что и тип IpAddress, но может представлять различные типы сетевых адресов |
Gauge | 32-битное число от 0 до 232 - 1 (4 294 967 295). Но в отличие от Counter может произвольно увеличиваться или уменьшаться но не может превзойти максимального значения |
TimeTicks | 32-битное число от 0 до 232 - 1 (4 294 967 295). Измеряет время в сотых долях секунды. При помощи этого типа измеряется время работы устройства. |
Opaque | Позволяет занести любую другую кодировку ASN.1 в OCTET STRING |
В SMIv2 добавлено еще несколько типов данных
Типы данных добавленные в SMIv2
Типы данных | Описание |
Integer32 | Тоже самое, что INTEGER |
Counter32 | Тоже самое, что Counter |
Gauge32 | Тоже самое, что Gauge |
Unsigned32 | Десятичные значения в диапазоне от 0 до 232 - 1 |
Counter64 | Аналогичен Counter32 но имеет максимальное значение 18 446 744 073 709 551 615, идеально подходит для ситуаций когда Counter32 за короткое время может достигнуть максимума и обнулиться |
И, наконец, мы дошли до описания оставшихся атрибутов объектов
Дополнения в определении объекта в SMIv2
Типы данных | Описание |
UnitsParts | Текстовое описание единиц (например секунды, миллиамперы и т.п.) используемые для представления объекта |
MAX-ACCESS | в SMIv1 имя этого атрибута ACCESS и он может быть read-only, read-write, write-only, not-accessible в SMIv2 может быть read-only, read-write, read-create, not-accessible и accessible-for-notify |
STATUS | в SMIv1 может быть mandatory (обязательный), optional (необязательный), obsolete (устаревший) в SMIv2 current, obsolete, deprecated (current то же самое что mandatory в SMIv1) |
AUGMENTS | В некоторых случаях полезно добавить в существующую таблицу столбец. Оператор AUGMENTS позволяет расширить таблицу, дополнив одним или несколькими столбцами, представленными каким-либо объектом. |
Этой теории вполне достаточно, чтобы понять весь MIB файл.
--
-- Node definitions
--
-- 1.3.6.1.4.1.2011.6.164.1
hwSiteMonitorMIBObjects OBJECT IDENTIFIER ::= { hwSiteMonitorMIB 1 }
-- 1.3.6.1.4.1.2011.6.164.1.1
hwSiteInfo OBJECT IDENTIFIER ::= { hwSiteMonitorMIBObjects 1 }
-- 1.3.6.1.4.1.2011.6.164.1.1.1
hwSiteSummary OBJECT IDENTIFIER ::= { hwSiteInfo 1 }
-- 1.3.6.1.4.1.2011.6.164.1.1.1.1
hwSiteId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Site ID, default value: 000,000.
Naming rule of the site device ID (six digits):
The first three digits indicate the device name and the last three digits
indicate the serial number (SN) of the device. If the last three digits are 000,
it indicates a virtual device. "
::= { hwSiteSummary 1 }В начале описывается объекты структуры hwSiteMonitorMIBObjects как составляющая hwSiteMonitorMIB и т.д. и наконец первый “настоящий” объект hwSiteId
как видите, это скаляр и
snmpget -v 2c -c MySeCrEt 10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.1
вернет
SNMPv2-SMI::enterprises.2011.6.164.1.1.1.1 = No Such Instance currently exists at this OID
поэтому, поняв из MIBа что это скаляр, мы выполняем
snmpget -v 2c -c MySeCrEt 10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.1.0
и получаем
SNMPv2-SMI::enterprises.2011.6.164.1.1.1.1.0 = STRING: "Mayak"
как видим, хотя объект и read-only, подрядчик при первоначальной настройке изменил на имя подстанции, или, что вероятнее, этот MIB не совсем от этой СГП
А вот пример отсутствия у нас дизеля, и он действительно не предусмотрен проектом СГП
-- 1.3.6.1.4.1.2011.6.164.1.1.1.9
hwSiteDGWorkStatus OBJECT-TYPE
SYNTAX INTEGER
{
idle(1),
working(2),
unknown(255)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"State of the diesel working state. It is an enumeration type:
If the enumeration value is 1, it indicates that the diesel is in the idle state;
If the enumeration value is 2, it indicates that the diesel is in
the working state;
If the enumeration value is 255, it indicates diesel operation status unknown. "
::= { hwSiteSummary 9 }snmpget -v 2c -c MySeCrEt 10.XX.XX.197 .1.3.6.1.4.1.2011.6.164.1.1.1.9.0
SNMPv2-SMI::enterprises.2011.6.164.1.1.1.9.0 = No Such Object available on this agent at this OID
С одиночными (скалярами) объектами разобрались, они все подобны.
Рассмотрим объекты таблицы.
Например батареи, которыми укомплектована СГП. Они имеют установочные параметры - имена, ID, пороги алармов по температуре. Батарей может быть от 0 до какого то числа.
(не бесконечности)
-- 1.3.6.1.4.1.2011.6.164.1.4.4
hwBattString OBJECT IDENTIFIER ::= { hwSiteBatterys 4 }
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1
hwBattStringConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF HwBattStringConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Battery string config table. Use this table to get battery string equipment ID
and equipment name, to set battery standard capacity and battery install time
as well. This table's index is hwBattStringConfigIndex, clone battery
string config table."
::= { hwBattString 1 }Объект hwBattStringConfigTable, обратите внимание, он not-accessible и snmpget c этим OID вернет No Such Object и добавление нуля к этому OID не поможет, это объект контейнер*(таблица)* , он не содержит данных, только другие объекты (строки таблицы), а точнее последовательность (sequence of) объектов типа HwBattStringConfigEntry - обратите внимание название ВСЕГДА с большой буквы, это название ТИПА ОБЪЕКТА, определяемого далее в MIB файле
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1
hwBattStringConfigEntry OBJECT-TYPE
SYNTAX HwBattStringConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Battery string config table entry."
INDEX { hwBattStringConfigIndex }
::= { hwBattStringConfigTable 1 }Объект hwBattStringConfigEntry одна КОНКРЕТНАЯ строка таблицы (название всегда с маленькой буквы) имеющая тип HwBattStringConfigEntry (название с большой буквы) и дальше следует описание самого типа, это по сути СПИСОК (SEQUENCE) столбцов, входящих в эту строку
HwBattStringConfigEntry ::=
SEQUENCE {
hwBattStringConfigIndex
Integer32,
hwBattStringEquipId
Unsigned32,
hwBattStringEquipName
OCTET STRING,
hwSetBattsTempUpperLimit
Integer32,
hwSetBattsTempLowerLimit
Integer32,
hwSetBattsTempMeasureUpperLimit
Integer32,
hwSetBattsTempMeasureLowerLimit
Integer32,
hwSetBattStdCapacity
Integer32,
hwSetBattInstallTime
OCTET STRING,
hwBattStringConfigRowStatus
RowStatus
}Дальше следуют описания объектов (столбцов) составляющих строку hwBattStringConfigEntry
Самый первый объект INDEX и он входит в состав всех объектов, составляющих hwBattStringConfigEntry
небольшое отступление: я раньше представлял себе “строение” SNMP “по человечески”, считал что если 1.1.1.2 например это какой то объект, то 1.1.1.2.1.5, 1.1.1.2.2.6, 1.1.1.2.3.7 это какие-то параметры (атрибуты) этого объекта (я жестоко ошибался),
а на самом деле:
164.1.4.4.1.1.4.2289
164.1.4.4.1.1.4.2290
164.1.4.4.1.1.5.2289
164.1.4.4.1.1.5.2290
это два параметра 164.1.4.4.1.1.4 и 164.1.4.4.1.1.5 двух объектов(строк) 2289 и 2290
так вот 2289 и 2290 - это и есть INDEX, присваивается в момент загрузки устройства и может измениться после перезагрузки
именно поэтому, если вы хотите, чтобы например интерфейсы не меняли в SNMP свой ifIndex рекомендуют прописывать в конфигурации:
на оборудовании Cisco: snmp-server ifindex persist
а на оборудовании Huawei: ifindex constant
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.1
hwBattStringConfigIndex OBJECT-TYPE
SYNTAX Integer32 (1..100)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Device table index of the battery string, which value range: 1 to 100."
::= { hwBattStringConfigEntry 1 }
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.2
hwBattStringEquipId OBJECT-TYPE
SYNTAX Unsigned32 (3001..3100)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Batteries device ID, can be configured by users. Value range: 003,001 to 003,100,
in which the first three digits specify the device type and the last three
specify the device SN."
::= { hwBattStringConfigEntry 2 }
Идентификатор оборудования hwBattStringEquipId, ранее в этом файле (я не показываю) были описаны группы оборудования: 1000 - Монитор, 2000 - Выпрямители, 3000 - Батареи и т.д. поэтому конкретные батареи в группе будут иметь идентификаторы 3001, 3002 и т.д
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.3
hwBattStringEquipName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..63))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Batteries device name, of the character string type, is used to specify
the batteries. Users can configure it.
Otherwise, the configured character can not be any other languages except English."
::= { hwBattStringConfigEntry 3 }Вот пример целочисленного объекта измеряемого в градусах по Цельсию, позволяющего хранить (в Integer объекте) до десятых долей градуса.
Как? Посмотрите описание, возвращаемое значение необходимо делить на 10:
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.4
hwSetBattsTempUpperLimit OBJECT-TYPE
SYNTAX Integer32 (-50..100)
UNITS "centigrades"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Upper threshold of the battery temperature alarm, can be configured by users.
Value range: -50 to 100, Unit: centigrade (°„C), and the value is an integer (.0)."
::= { hwBattStringConfigEntry 4 }А вот элемент возвращающий Ампер-часы (тоже integer но хранит до десятых долей)
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.8
hwSetBattStdCapacity OBJECT-TYPE
SYNTAX Integer32 (0..10000)
UNITS "Ah"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Set battery standard capacity, is an inherent attribute of the device.
Value range: 0 to 10000, unit: Ah, the value is an integer (.0). "
::= { hwBattStringConfigEntry 8 }
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.9
hwSetBattInstallTime OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..128))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Set battery install time, of the character string type,
can be configured by users.
Otherwise,
the configured character can not be any other languages except English. "
::= { hwBattStringConfigEntry 9 }
-- 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.100
hwBattStringConfigRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"RowStatus of battery string config table."
::= { hwBattStringConfigEntry 100 }Я пропустил несколько объектов таблицы, по сути все одно и тоже. На моем конкретном оборудовании snmpwalk -v 2c -c MySeCrEt 10.XX.XX.197 1.3.6.1.4.1.2011.6.164.1.4.4.1 возвращает:
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.1.5 = INTEGER: 5
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.1.6 = INTEGER: 6
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.2.5 = Gauge32: 3001
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.2.6 = Gauge32: 3002
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.3.5 = STRING: "Battery String1"
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.3.6 = STRING: "Battery String2"
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.4.5 = INTEGER: 50
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.4.6 = INTEGER: 50
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.5.5 = INTEGER: -10
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.5.6 = INTEGER: -10
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.8.5 = INTEGER: 190
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.8.6 = INTEGER: 190
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.100.5 = INTEGER: 1
SNMPv2-SMI::enterprises.2011.6.164.1.4.4.1.1.100.6 = INTEGER: 1
Вы же видите hwBattStringConfigIndex у меня принимает значения 5 и 6, установлены 2 батареи и все объекты(столбцы) представлены 2 раза для каждого INDEX’а (строки) отдельно
не всегда индекс нужного вам параметра будет последним числом в строке
озаботился созданием в Zabbx триггера состояния канала. Часто это не падение интерфейса, это может быть резервный канал, редко попадающий в таблицу маршрутизации, или стойка ВЧ связи, у которой с Ethernet портом все хорошо, а ВЧ тракт лёг. Самое простое это триггер на состояние Cisco IPSLA или Huawei NQA, но у Huawei, если настроен больше чем один NQA test, один от другого можно отделить с помощью '#SNMPINDEX', из строки:
'1.3.6.1.4.1.2011.5.25.111.4.1.1.3.{#SNMPINDEX}.{переменный_увеличивающийся на 1 индекс}'
и даже если настроить один запрос и не хранение последних значений, последняя часть превратится в {в длинный постоянный индекс}, все равно опрашивать надо:
"1.3.6.1.4.1.2011.5.25.111.4.1.1.3.11.80.105.110.103.79.118.101.114.82.82.76.7.80.105.110.103.78.69.83"
"1.3.6.1.4.1.2011.5.25.111.4.1.1.3.12.80.105.110.103.79.118.101.114.86.79.76.83.7.80.105.110.103.78.69.83"
где 11 и 12 как раз определяют номер NQA test
Вышеописанную таблицу проще понять если представить в виде ….. да, таблицы Excel:
hwBattStringConfigTable oid: 1.3.6.1.4.1.2011.6.164.1.4.4.1
hwBattStringConfigIndex | hwBattStringEquipId | hwBattStringEquipName | |
|---|---|---|---|
1.3.6.1.4.1.2011.6.164.1.4.4.1.1.1 | 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.2 | 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.3 | и так далее |
index: 5 oid:1.3.6.1.4.1.2011.6.164.1.4.4.1.1.1.5 | value: 3001 oid:1.3.6.1.4.1.2011.6.164.1.4.4.1.1.2.5 | value:"Battery String1" oid:1.3.6.1.4.1.2011.6.164.1.4.4.1.1.3.5 | и тому подобное |
index: 6 oid: 1.3.6.1.4.1.2011.6.164.1.4.4.1.1.1.6 | 3002 oid:1.3.6.1.4.1.2011.6.164.1.4.4.1.1.2.6 | "Battery String2" oid:1.3.6.1.4.1.2011.6.164.1.4.4.1.1.3.6 |
А каждая вместе взятая строка таблицы (не заголовки), это объект HwBattStringConfigEntry описатель структуры данных (строки)
Надеюсь этот небольшой опус кому-нибудь поможет прийти к пониманию SNMP и MIB файлов немного быстрее, чем я к этому шел :-)