forum.opennet.ru - "SNMP принцип работы MIB файлов/баз данных" (8)

форумы

помощь

поиск

регистрация

вход/выход

слежка

"SNMP принцип работы MIB файлов/баз данных"

Форум Открытые системы на сервере (Мониторинг, логи / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"SNMP принцип работы MIB файлов/баз данных"	+/–
Сообщение от CROSP (ok) on 06-Ноя-16, 09:42
Здравствуйте, пытаюсь разобраться со возможными средствами мониторинга сети. Сейчас пытаюсь настроить простой мониторинг с помощью SNMP протокола с использованием таких утилит как Cactie, MRTG ... (не столь важно). Сам протокол предельно понятен и прост в понимании. Вот возникли проблемы с пониманием MIB баз данных (или файл, далее буду использовать взаимозаменяемо) и всего что связано с ними. Сама структура этой базы понятно, что древовидная на подобии DNS. При запросе посылается идентификатор определенного объекта в этом дереве, он в свою очередь может быть скаляром или же таблицей. Вопросы и проблемы с пониманием возникли больше по организационной части. 1. Насколько я понял существует глобальный файл/база данных MIB идентификаторов, и для того чтобы попасть в этот список надо подать заявку, обычно это надо производителей сетевого железа. Верно ? 2. Все таки это один файл или же несколько ? 3. При настройке в новых версиях по умолчанию этих файлов MIB файлов нету в системе. Поэтому предлагают выполнить команды sudo apt-get install snmp-mibs-downloader sudo download-mibs Вопрос зачем это делать ? Насколько я понимаю подгружается весь файл/файлы из иерархии. Допустим у меня есть маленький роутер, с каким-то openwrt на борту я хочу мониторить его состояние. Зачем мне качать все эти файлы, если роутер будет хранить информацию про самые базовые показатели (пакеты, аптайм, память ...). Зачем качать все файлы/один большой для всех вендоров, если нужно работать только с несколькими нодам в этом дереве ? 4. Каким образом происходит работа с этой самой MIB базой/файлом на агенте (устройство для мониторинга). А именно как записываются данные в эту базу ? В первом случае предположим что хотим записать информацию в какую-то ноду в дереве. Система например хочет записать информацию о количестве принятых пакетов. Кто за это ответственный и как это происходит. Демон считывает сам определенную информацию ? Это происходит по тому же протоколу SNMP только с локального хоста ? Запускаются какие-то скрипты которые берут информацию о системе и отдают демону или же сами записывают в MIB файл. 5. Что нужно делать если хочу добавить свой кастомный идентификатор(ноду) в базу данных. По идее можно просто не устанавливать все файлы, а сделать кастомный и подсунуть его демону ? Например я хочу считать информацию о датчиках температуры проца через псевдо файловую систему /proc. Каким образом это все связать со всей этой системой. Буду благодарен за пояснения или хороший материал для прочтения. Уже много искал на эту тему, но толкового ничего не нашел, поэтому обратился на форум. Спасибо.
Ответить \| Правка \| Cообщить модератору

Оглавление

SNMP принцип работы MIB файлов/баз данных, PavelR, 11:59 , 06-Ноя-16, (1)
SNMP принцип работы MIB файлов/баз данных, PavelR, 12:39 , 06-Ноя-16, (2)

SNMP принцип работы MIB файлов/баз данных, CROSP, 16:22 , 06-Ноя-16, (3)

SNMP принцип работы MIB файлов/баз данных, PavelR, 21:44 , 06-Ноя-16, (4)

SNMP принцип работы MIB файлов/баз данных, CROSP, 13:06 , 07-Ноя-16, (5)

SNMP принцип работы MIB файлов/баз данных, PavelR, 15:42 , 07-Ноя-16, (6)

SNMP принцип работы MIB файлов/баз данных, CROSP, 18:50 , 07-Ноя-16, (7)

SNMP принцип работы MIB файлов/баз данных, PavelR, 23:09 , 07-Ноя-16, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от PavelR (??) on 06-Ноя-16, 11:59

> Здравствуйте, пытаюсь разобраться со возможными средствами мониторинга сети.
> Сейчас пытаюсь настроить простой мониторинг с помощью SNMP протокола с использованием таких
> утилит как Cactie, MRTG ... (не столь важно).
> Сам протокол предельно понятен и прост в понимании.
http://www.k-max.name/linux/snmp-protocol/
> Вопрос зачем это делать ? Насколько я понимаю подгружается весь файл/файлы из
> иерархии. Допустим у меня есть маленький роутер, с каким-то openwrt на
> борту я хочу мониторить его состояние. Зачем мне качать все эти
> файлы, если роутер будет хранить информацию про самые базовые показатели (пакеты,
> аптайм, память ...). Зачем качать все файлы/один большой для всех вендоров,
> если нужно работать только с несколькими нодам в этом дереве ?
Да вроде не надо качать, если стандартные показатели смотреть.

> 4. Каким образом происходит работа с этой самой MIB базой/файлом на агенте
> (устройство для мониторинга). А именно как записываются данные в эту базу
> ?
MIB база это база описаний, что по каким адресам находится. Это не база значений.
>В первом случае предположим что хотим записать информацию в какую-то
> ноду в дереве. Система например хочет записать информацию о количестве принятых
> пакетов. Кто за это ответственный и как это происходит. Демон считывает
> сам определенную информацию ?
Демон считывает информацию каким-либо образом, например если мы говорим про количество пакетов, то он это делает вычитывая файл "/proc/net/snmp". "snmp" в названии файла вполне могло бы быть заменено например на более общее "statistics"
>Это происходит по тому же протоколу SNMP только с локального хоста?
нет
> Запускаются какие-то скрипты которые берут информацию
> о системе и отдают демону или же сами записывают в MIB
> файл.
Это делает snmp-daemon при поступлении к нему запроса. Демон же и отвечает на запрос, файл на запрос ответить не может.
Повторю еще раз: в MIB-файл ничего не пишется.
Любая программа может реализовать SNMP протокол и к ней можно будет обратиться за её внутренней статистикой. Примеры: squid, amavisd-new.
> 5. Что нужно делать если хочу добавить свой кастомный идентификатор(ноду) в базу
> данных. По идее можно просто не устанавливать все файлы, а сделать
> кастомный и подсунуть его демону ? Например я хочу считать информацию
> о датчиках температуры проца через псевдо файловую систему /proc. Каким образом
> это все связать со всей этой системой.
В snmpd есть возможность запускать скрипты и возвращать значения на основе их вывода.
Также в snmpd есть такая функция как "агенты".

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от PavelR (??) on 06-Ноя-16, 12:39

Без БД:
# snmpwalk -v 2c  localhost -u xxxx -c xxxx .1.3.6.1.4.1.795
iso.3.6.1.4.1.795.14.1.100.1.0 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.100.2.0 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.100.3.0 = INTEGER: 419
iso.3.6.1.4.1.795.14.1.100.4.0 = STRING: "Copyright (c) 2009 Adaptec Inc"
iso.3.6.1.4.1.795.14.1.100.5.0 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.201.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.201.1.1.2.1 = STRING: "None"
iso.3.6.1.4.1.795.14.1.201.1.1.3.1 = STRING: "Adaptec"
iso.3.6.1.4.1.795.14.1.201.1.1.4.1 = STRING: "Adaptec 5405"
iso.3.6.1.4.1.795.14.1.201.1.1.5.1 = STRING: "5.2-0"
iso.3.6.1.4.1.795.14.1.201.1.1.6.1 = STRING: "xxxx"
iso.3.6.1.4.1.795.14.1.201.1.1.7.1 = STRING: "Adaptec 5405"
iso.3.6.1.4.1.795.14.1.201.1.1.8.1 = INTEGER: 8
iso.3.6.1.4.1.795.14.1.201.1.1.9.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.201.1.1.10.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.201.1.1.11.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.201.1.1.12.1 = INTEGER: 256
iso.3.6.1.4.1.795.14.1.201.1.1.13.1 = INTEGER: 6
iso.3.6.1.4.1.795.14.1.201.1.1.14.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.201.1.1.15.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.201.1.1.16.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.201.1.1.17.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.201.1.1.18.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.201.1.1.19.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.201.1.1.20.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.211.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.211.1.1.2.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.211.1.1.3.1 = INTEGER: 18
iso.3.6.1.4.1.795.14.1.211.1.1.4.1 = STRING: "5.2-0"
iso.3.6.1.4.1.795.14.1.211.1.1.5.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.300.1.1.1.3 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.300.1.1.1.4 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.300.1.1.2.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.2.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.2.3 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.2.4 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.3.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.3.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.3.3 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.3.4 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.4.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.300.1.1.4.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.4.3 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.300.1.1.4.4 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.300.1.1.5.1 = INTEGER: 7
iso.3.6.1.4.1.795.14.1.300.1.1.5.2 = INTEGER: 7
iso.3.6.1.4.1.795.14.1.300.1.1.5.3 = INTEGER: 7
iso.3.6.1.4.1.795.14.1.300.1.1.5.4 = INTEGER: 7
iso.3.6.1.4.1.795.14.1.300.1.1.6.1 = STRING: "SAS 300"
iso.3.6.1.4.1.795.14.1.300.1.1.6.2 = STRING: "SAS 300"
iso.3.6.1.4.1.795.14.1.300.1.1.6.3 = STRING: "SAS 300"
iso.3.6.1.4.1.795.14.1.300.1.1.6.4 = STRING: "SAS 300"
iso.3.6.1.4.1.795.14.1.300.1.1.7.1 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.7.2 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.7.3 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.7.4 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.8.1 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.8.2 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.8.3 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.8.4 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.300.1.1.9.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.9.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.9.3 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.9.4 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.300.1.1.10.1 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.300.1.1.10.2 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.300.1.1.10.3 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.300.1.1.10.4 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.300.1.1.11.1 = INTEGER: 8
iso.3.6.1.4.1.795.14.1.300.1.1.11.2 = INTEGER: 8
iso.3.6.1.4.1.795.14.1.300.1.1.11.3 = INTEGER: 8
iso.3.6.1.4.1.795.14.1.300.1.1.11.4 = INTEGER: 8
iso.3.6.1.4.1.795.14.1.300.1.1.12.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.300.1.1.12.2 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.300.1.1.12.3 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.300.1.1.12.4 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.400.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.400.1.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.400.1.1.2.1 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.400.1.1.2.2 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.400.1.1.3.1 = STRING: "1"
iso.3.6.1.4.1.795.14.1.400.1.1.3.2 = STRING: "1"
iso.3.6.1.4.1.795.14.1.400.1.1.4.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.400.1.1.4.2 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.400.1.1.5.1 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.400.1.1.5.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.400.1.1.6.1 = STRING: "WDC"
iso.3.6.1.4.1.795.14.1.400.1.1.6.2 = STRING: "WDC"
iso.3.6.1.4.1.795.14.1.400.1.1.7.1 = STRING: "WD3000HLFS-0"
iso.3.6.1.4.1.795.14.1.400.1.1.7.2 = STRING: "WD3000HLFS-0"
iso.3.6.1.4.1.795.14.1.400.1.1.8.1 = STRING: "04.04V06"
iso.3.6.1.4.1.795.14.1.400.1.1.8.2 = STRING: "04.04V06"
iso.3.6.1.4.1.795.14.1.400.1.1.9.1 = STRING: "WD-WX11DBxxx"
iso.3.6.1.4.1.795.14.1.400.1.1.9.2 = STRING: "WD-WX11DBxxx"
iso.3.6.1.4.1.795.14.1.400.1.1.10.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.400.1.1.10.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.400.1.1.11.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.400.1.1.11.2 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.400.1.1.12.1 = STRING: "controller 1, connector 0, device 0, S/N WD-WX11DBxxx"
iso.3.6.1.4.1.795.14.1.400.1.1.12.2 = STRING: "controller 1, connector 0, device 1, S/N WD-WX11DBxxx"
iso.3.6.1.4.1.795.14.1.400.1.1.13.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.400.1.1.13.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.400.1.1.14.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.400.1.1.14.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.400.1.1.15.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.400.1.1.15.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.401.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.401.1.1.2.1 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.401.1.1.2.2 = STRING: "Unknown"
iso.3.6.1.4.1.795.14.1.401.1.1.3.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.3.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.401.1.1.4.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.401.1.1.4.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.401.1.1.5.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.5.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.6.1 = STRING: "0"
iso.3.6.1.4.1.795.14.1.401.1.1.6.2 = STRING: "1"
iso.3.6.1.4.1.795.14.1.401.1.1.7.1 = STRING: "0"
iso.3.6.1.4.1.795.14.1.401.1.1.7.2 = STRING: "0"
iso.3.6.1.4.1.795.14.1.401.1.1.8.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.8.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.401.1.1.9.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.401.1.1.9.2 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.401.1.1.10.1 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.401.1.1.10.2 = INTEGER: 300
iso.3.6.1.4.1.795.14.1.401.1.1.11.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.401.1.1.11.2 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.410.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.410.1.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.410.1.1.2.1 = STRING: "WDC  WD3000HLFS-0"
iso.3.6.1.4.1.795.14.1.410.1.1.2.2 = STRING: "WDC  WD3000HLFS-0"
iso.3.6.1.4.1.795.14.1.410.1.1.3.1 = INTEGER: 286168
iso.3.6.1.4.1.795.14.1.410.1.1.3.2 = INTEGER: 286168
iso.3.6.1.4.1.795.14.1.410.1.1.4.1 = INTEGER: 512
iso.3.6.1.4.1.795.14.1.410.1.1.4.2 = INTEGER: 512
iso.3.6.1.4.1.795.14.1.410.1.1.5.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.410.1.1.5.2 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.410.1.1.6.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.410.1.1.6.2 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.410.1.1.7.1 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.410.1.1.7.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.410.1.1.8.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.410.1.1.8.2 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.410.1.1.9.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.410.1.1.9.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.1000.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1000.1.1.2.1 = ""
iso.3.6.1.4.1.795.14.1.1000.1.1.3.1 = INTEGER: 285686
iso.3.6.1.4.1.795.14.1.1000.1.1.4.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.1000.1.1.5.1 = INTEGER: -1
iso.3.6.1.4.1.795.14.1.1000.1.1.6.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.1000.1.1.7.1 = INTEGER: 100
iso.3.6.1.4.1.795.14.1.1000.1.1.8.1 = INTEGER: 6
iso.3.6.1.4.1.795.14.1.1000.1.1.9.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1000.1.1.10.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1000.1.1.11.1 = INTEGER: 3
iso.3.6.1.4.1.795.14.1.1000.1.1.12.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.1000.1.1.13.1 = INTEGER: 4
iso.3.6.1.4.1.795.14.1.1000.1.1.14.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.15.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.16.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.17.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.18.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.19.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1000.1.1.20.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1000.1.1.21.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1001.1.1.1.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1001.1.1.1.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.1001.1.1.2.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1001.1.1.2.2 = INTEGER: 2
iso.3.6.1.4.1.795.14.1.1001.1.1.3.1 = INTEGER: 585105408
iso.3.6.1.4.1.795.14.1.1001.1.1.3.2 = INTEGER: 585105408
iso.3.6.1.4.1.795.14.1.1001.1.1.4.1 = INTEGER: 128
iso.3.6.1.4.1.795.14.1.1001.1.1.4.2 = INTEGER: 128
iso.3.6.1.4.1.795.14.1.1001.1.1.5.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1001.1.1.5.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1001.1.1.6.1 = INTEGER: 585105280
iso.3.6.1.4.1.795.14.1.1001.1.1.6.2 = INTEGER: 585105280
iso.3.6.1.4.1.795.14.1.1001.1.1.7.1 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1001.1.1.7.2 = INTEGER: 0
iso.3.6.1.4.1.795.14.1.1001.1.1.8.1 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.1001.1.1.8.2 = INTEGER: 1
iso.3.6.1.4.1.795.14.1.2000.1.0 = INTEGER: 0
С использованием БД
# snmpwalk -OT -v 2c  -mADAPTEC-UNIVERSAL-STORAGE-MIB  localhost -u xxx -c xxx .1.3.6.1.4.1.795
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausMibStatusRevMajor.0 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausMibStatusRevMinor.0 = INTEGER: 4
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausMibStatusSecondsSinceInitiation.0 = INTEGER: 1130
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausMibStatusCopyright.0 = STRING: "Copyright (c) 2009 Adaptec Inc"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausMibStatusOverall.0 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerUniqueId.1 = STRING: "None"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerVendor.1 = STRING: "Adaptec"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerModel.1 = STRING: "Adaptec 5405"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerRevision.1 = STRING: "5.2-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerSerialNumber.1 = STRING: "xxx"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerDescription.1 = STRING: "Adaptec 5405"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerHostBusType.1 = INTEGER: pcie(8)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerHostBusMaximumTransferRate.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerNumberOfChannels.1 = INTEGER: 4
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerHighestChannelWithDevices.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerInstalledMemory.1 = INTEGER: 256
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerAudibleAlarmStatus.1 = INTEGER: installedAndActive(6)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerBatteryStatus.1 = INTEGER: notInstalled(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerOverallStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerPerformanceMode.1 = INTEGER: dynamic(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerMaxIQAssignedDrives.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerMaximumAllowedMaxIQDrives.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausControllerNCQStatus.1 = INTEGER: Disabled(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausCCodeControllerIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausCCodeControllerPCIBusId.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausCCodeControllerPCISlotNumber.1 = INTEGER: 18
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausCCodeControllerBiosVersion.1 = STRING: "5.2-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausCCodeControllerMainIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelIndex.3 = INTEGER: 3
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelIndex.4 = INTEGER: 4
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelLocation.1 = INTEGER: hostAttached(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelLocation.2 = INTEGER: hostAttached(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelLocation.3 = INTEGER: hostAttached(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelLocation.4 = INTEGER: hostAttached(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerIndex.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerIndex.3 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerIndex.4 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerChannelNumber.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerChannelNumber.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerChannelNumber.3 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelAusControllerChannelNumber.4 = INTEGER: 3
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelType.1 = INTEGER: sas(7)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelType.2 = INTEGER: sas(7)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelType.3 = INTEGER: sas(7)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelType.4 = INTEGER: sas(7)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelTypeDescription.1 = STRING: "SAS 300"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelTypeDescription.2 = STRING: "SAS 300"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelTypeDescription.3 = STRING: "SAS 300"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelTypeDescription.4 = STRING: "SAS 300"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerId.1 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerId.2 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerId.3 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerId.4 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerSubId.1 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerSubId.2 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerSubId.3 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelControllerSubId.4 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelWidth.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelWidth.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelWidth.3 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelWidth.4 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumTransferRate.1 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumTransferRate.2 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumTransferRate.3 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumTransferRate.4 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumAttachments.1 = INTEGER: 8
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumAttachments.2 = INTEGER: 8
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumAttachments.3 = INTEGER: 8
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelMaximumAttachments.4 = INTEGER: 8
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelOverallStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelOverallStatus.2 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelOverallStatus.3 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausChannelOverallStatus.4 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceUniqueId.1 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceUniqueId.2 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceAusChannelIndices.1 = STRING: "1"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceAusChannelIndices.2 = STRING: "1"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceType.1 = INTEGER: directAccess(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceType.2 = INTEGER: directAccess(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceTypeGroup.1 = INTEGER: storageDevice(2)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceTypeGroup.2 = INTEGER: storageDevice(2)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceVendor.1 = STRING: "WDC"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceVendor.2 = STRING: "WDC"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceModel.1 = STRING: "WD3000HLFS-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceModel.2 = STRING: "WD3000HLFS-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceRevision.1 = STRING: "04.04V06"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceRevision.2 = STRING: "04.04V06"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceSerialNumber.1 = STRING: "WD-WX11DBxxx"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceSerialNumber.2 = STRING: "WD-WX11DBxxx"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceNumberOfPorts.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceNumberOfPorts.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceStatus.2 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceLocation.1 = STRING: "controller 1, connector 0, device 0, S/N WD-WX11DBxxx"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceLocation.2 = STRING: "controller 1, connector 0, device 1, S/N WD-WX11DBxxx"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceMaxIQCacheCapable.1 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceMaxIQCacheCapable.2 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceMaxIQCacheAssigned.1 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceMaxIQCacheAssigned.2 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceSataNCQEnabled.1 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDeviceSataNCQEnabled.2 = INTEGER: False(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortUniqueId.1 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortUniqueId.2 = STRING: "Unknown"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusDeviceIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusDeviceIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusDevicePortNumber.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusDevicePortNumber.2 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusChannelIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortAusChannelIndex.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortId.1 = STRING: "0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortId.2 = STRING: "1"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortSubId.1 = STRING: "0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortSubId.2 = STRING: "0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortWidth.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortWidth.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortMaximumTransferRate.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortMaximumTransferRate.2 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortNegotiatedTransferRate.1 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortNegotiatedTransferRate.2 = INTEGER: 300
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausDevicePortStatus.2 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceDescription.1 = STRING: "WDC  WD3000HLFS-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceDescription.2 = STRING: "WDC  WD3000HLFS-0"
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceFormattedCapacity.1 = INTEGER: 286168
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceFormattedCapacity.2 = INTEGER: 286168
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceBlockSize.1 = INTEGER: 512
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceBlockSize.2 = INTEGER: 512
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceNumberOfBlocksLow.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceNumberOfBlocksLow.2 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceNumberOfBlocksHigh.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceNumberOfBlocksHigh.2 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceRemovableMedia.1 = INTEGER: notSupported(2)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceRemovableMedia.2 = INTEGER: notSupported(2)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceSmartStatus.1 = INTEGER: okay(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceSmartStatus.2 = INTEGER: okay(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceMainIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStorageDeviceMainIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayName.1 = ""
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayCapacity.1 = INTEGER: 285686
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayType.1 = INTEGER: raid1(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayStripeSize.1 = INTEGER: -1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayTaskStatus.1 = INTEGER: noTaskActive(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayTaskCompletion.1 = INTEGER: 100
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayTaskPriority.1 = INTEGER: low(6)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayHostingControllerType.1 = INTEGER: physicalController(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayHostingControllerIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayStatus.1 = INTEGER: okay(3)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayState.1 = INTEGER: quickInited(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayCacheStatus.1 = INTEGER: writeBack(4)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayMembership.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayID.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayPMStatus.1 = INTEGER: Disabled(0)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausStandByTimer.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausPowerOffTimer.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausVerifyTimer.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayMaxIQPreferredCacheSetting.1 = INTEGER: disabled(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausArrayMaxIQCacheSetting.1 = INTEGER: Disabled(1)
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentAusDeviceIndex.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentAusDeviceIndex.2 = INTEGER: 2
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentSize.1 = INTEGER: 585105408
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentSize.2 = INTEGER: 585105408
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentStartingLBALow.1 = INTEGER: 128
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentStartingLBALow.2 = INTEGER: 128
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentStartingLBAHigh.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentStartingLBAHigh.2 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentNumberOfBlocksLow.1 = INTEGER: 585105280
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentNumberOfBlocksLow.2 = INTEGER: 585105280
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentNumberOfBlocksHigh.1 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentNumberOfBlocksHigh.2 = INTEGER: 0
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentArrayMembership.1 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausExtentArrayMembership.2 = INTEGER: 1
ADAPTEC-UNIVERSAL-STORAGE-MIB::ausEventLogNumEntries.0 = INTEGER: 0

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от CROSP (ok) on 06-Ноя-16, 16:22

> Без БД:
> # snmpwalk -v 2c  localhost -u xxxx -c xxxx .1.3.6.1.4.1.795
> iso.3.6.1.4.1.795.14.1.100.1.0 = INTEGER: 1
> iso.3.6.1.4.1.795.14.1.100.2.0 = INTEGER: 4
Спасибо большое Вам за ответ. То есть насколько я понял MIB нужен только для того,
чтобы использовать имя вместо идентификатора ?
За статью отдельное спасибо, часто черпал полезную инфу с этого ресурса.
Еще пару вопросов возникло, если не сложно, ответьте пожалуйста.
1. Каким образом при посылке какого-то OID snmpd знает куда смотреть, что запускать и так далее ?
2. Каким образом составлено это дерево ? То есть каждый раз когда кого-то вносять в официальную спецификацию нужно обновлять демон и другие утилиты которые используют это дерево ?
3. Выходит что демон отдает данные которые где-то хранятся текущее только или читает от какого-то скрипта.
4. Вы сказали что в MIB ничего не записывается. Вот просто из статьи той что Вы скинули.
>Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB.
Спасибо еще раз.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от PavelR (??) on 06-Ноя-16, 21:44

>> Без БД:
>> # snmpwalk -v 2c  localhost -u xxxx -c xxxx .1.3.6.1.4.1.795
>> iso.3.6.1.4.1.795.14.1.100.1.0 = INTEGER: 1
>> iso.3.6.1.4.1.795.14.1.100.2.0 = INTEGER: 4
> Спасибо большое Вам за ответ. То есть насколько я понял MIB нужен
> только для того, чтобы использовать имя вместо идентификатора ?
Да. Непосредственно в протоколе бегают именно идентификаторы.
> 1. Каким образом при посылке какого-то OID snmpd знает куда смотреть, что
> запускать и так далее ?
Это его внутренняя реализация, а также его конфигурация, если мы говорим про то,
что определенную ветку он должен отправить на какого-то агента / скрипт и т д.
> 2. Каким образом составлено это дерево? То есть каждый раз когда
> кого-то вносять в официальную спецификацию нужно обновлять демон и другие утилиты
> которые используют это дерево ?
Что значит - используют?
Я показал в примере, что _отображать_ информацию можно вообще без MIB.
А чтобы _формировать_ значения для _новых_ данных, естественно надо что-то обновлять на стороне, которую опрашиваем - демон/конфигурацию/агента.
> 3. Выходит что демон отдает данные которые где-то хранятся текущее только или
> читает от какого-то скрипта.
А как иначе?
> 4. Вы сказали что в MIB ничего не записывается. Вот просто из
> статьи той что Вы скинули.
>>Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB.
Ну на заборе....
Вы сами файлы MIB видели? Вот в них 146% ничего не записывается.
> Спасибо еще раз.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от CROSP (ok) on 07-Ноя-16, 13:06

>> 4. Вы сказали что в MIB ничего не записывается. Вот просто из
>> статьи той что Вы скинули.
>>>Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB.
> Ну на заборе....
> Вы сами файлы MIB видели? Вот в них 146% ничего не записывается.
Спасибо еще раз за ответ. Я решил не гадать и искать где все будет разложено по полочкам. А открыл сорцы snmp_agent и также с ним вместе идут некоторые mib файлы.
Почитав на офф сайте информацию по MIB
http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a...
http://net-snmp.sourceforge.net/wiki/index.php/Agent_Archite...
Вот тут есть фраза
>>>MIB modules, which are responsible for implementing portions of the MIB tree, have the opportunity to register callbacks for any portion of the MIB tree when they are initialized. Registrations can functionally come from any of the following sources:
>>>MIB Modules register themselves by defining two things
a netsnmp_handler_registration structure containing "where" in the OID tree to register the MIB
a netsnmp_mib_handler structure indicating "what" code is registering to handle the requests
>>>The name "handler" is exactly what it sounds like: it is a mechanism that "handles a request". The term is used frequently throughout the API.
То есть насколько я понимаю MIB файлы или же модули это просто код который обрабатывает запросы по определенному OID. При запуске демона все подключенные и скомпилированные модули подгружаются и регистрируют сами себя на определенный OID в дереве.
Скачав сорцы перешел в директорию net-snmp-5.7.3\net-snmp-5.7.3\agent\mibgroup\udp-mib\data_access
И как я и предполагал тут много файлов для разных систем. (Linux, Solaris, BSD ...)
Открыв файл udp_endpoint_linux.c
static int
_load4(netsnmp_container *container, u_int load_flags)
{
    netsnmp_file              *fp;
    netsnmp_line_process_info  lpi;
    if (NULL == container)
        return -1;
    /*
     * allocate file resources
     */
    fp = netsnmp_file_fill(NULL, "/proc/net/udp" , O_RDONLY, 0, 0);
    if (NULL == fp) /** msg already logged */
        return -2;

    memset(&lpi, 0x0, sizeof(lpi));
    lpi.mem_size = sizeof(netsnmp_udp_endpoint_entry);
    lpi.process = _process_line_udp_ep;
    lpi.user_context = (void*)0;
    container = netsnmp_file_text_parse(fp, container, PM_USER_FUNCTION,
                                        0, &lpi);
    netsnmp_file_release(fp);
    return (NULL == container);
}

То есть все данные берутся из псевдо файловой системы /proc/ модулем MIB (в данном случае UDP).
Соответственно MIB нужны для того чтобы отвечать на определенный запрос в дереве по OID, также обрабатывать запись. Поэтому для каждой ветки в дереве должне быть свой хендлер и по умолчанию имеется определенный набор файлов MIB который скомпилированы под определенную систему.
Верно я понимаю ? Или опять что-то навыдумывал ?
Спасибо

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от PavelR (??) on 07-Ноя-16, 15:42

> Спасибо еще раз за ответ. Я решил не гадать и искать где
> все будет разложено по полочкам. А открыл сорцы snmp_agent и также
> с ним вместе идут некоторые mib файлы.
> Почитав на офф сайте информацию по MIB
> http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a...
> http://net-snmp.sourceforge.net/wiki/index.php/Agent_Archite...
> Вот тут есть фраза
>>>>MIB modules, which are responsible for implementing portions of the MIB tree, have the opportunity to register callbacks for any portion of the MIB tree when they are initialized. Registrations can functionally come from any of the following sources:
>>>>MIB Modules register themselves by defining two things
Естественно, что даймон, которого мы можем опрашивать по SNMP, знает, какие счетчики он знает.
Естественно, что у него внутри есть какие-то куски кода, которые знают, какие значения выдать в ответ на запрос определенного OID.
Называть ли это MIB или нет?
В одном из пониманий - нет, не называть. Посмотрите на .mib - файлы, которые вы скачали.
Даймон может ответить на запросы к нему и без этих файлов.
Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть нечто, что можно попробовать назвать MIB, но я не считаю это правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB написано определение:
>"MIB is short for Management Information Base. MIBs are written in the SMI language"
> a netsnmp_handler_registration structure containing "where" in the OID tree to register
> the MIB
> a netsnmp_mib_handler structure indicating "what" code is registering to handle the requests
>>>>The name "handler" is exactly what it sounds like: it is a mechanism that "handles a request". The term is used frequently throughout the API.
> То есть насколько я понимаю MIB файлы или же модули это просто
> код который обрабатывает запросы по определенному OID.
Я предлагаю разделить отдельно "MIB файлы" описания и модули, которые обрабатывают запросы по определенным OID.
>При запуске демона все подключенные и скомпилированные модули подгружаются и
> регистрируют сами себя на определенный OID в дереве.
Что-то вроде того.

> Скачав сорцы перешел в директорию net-snmp-5.7.3\net-snmp-5.7.3\agent\mibgroup\udp-mib\data_access
...
> То есть все данные берутся из псевдо файловой системы /proc/ модулем MIB
> (в данном случае UDP).
Здесь - берутся из proc, где-то берутся еще как-то.
> Соответственно MIB нужны для того чтобы отвечать на определенный запрос в дереве
> по OID, также обрабатывать запись.
В моем понимании чтобы отвечать на определенный запрос должен быть соответствующий модуль.
MIB - это база описаний. Загляните в каталог mibs/ архива.
> Поэтому для каждой ветки в дереве
> должне быть свой хендлер и по умолчанию имеется определенный набор файлов
> MIB который скомпилированы под определенную систему.
MIB - это база описаний. Загляните в каталог mibs/ архива.
> Верно я понимаю ? Или опять что-то навыдумывал ?
Надо определиться и согласовать терминологию.
> Спасибо

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от CROSP (ok) on 07-Ноя-16, 18:50

>[оверквотинг удален]
> Естественно, что у него внутри есть какие-то куски кода, которые знают, какие
> значения выдать в ответ на запрос определенного OID.
> Называть ли это MIB или нет?
> В одном из пониманий - нет, не называть. Посмотрите на .mib -
> файлы, которые вы скачали.
> Даймон может ответить на запросы к нему и без этих файлов.
> Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть
> нечто, что можно попробовать назвать MIB, но я не считаю это
> правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB
> написано определение:
Спасибо.
Если сейчас правильно понял, то ситуация такова.
Существуют MIB файлы (базы данных) в них описывается символические имена узлов в общем дереве и ставится соответствие для определенного OID.
На счет последнего возник вопрос, где все таки прописывается соответствие идентификатору, вот взял пример.
ifType OBJECT-TYPE
    SYNTAX      IANAifType
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The type of interface.  Additional values for ifType are
            assigned by the Internet Assigned Numbers Authority (IANA),
            through updating the syntax of the IANAifType textual
            convention."
    ::= { ifEntry 3 }

То есть MIB файл нужен для установки соответствия идентификатора к имени (как ДНС), а также несет информацию о данном узле, типе переменной, режиме записи....
Опять же чтобы не запоминать эти ужасные айдишники используются символические имена.
Также есть понятие MIB модуля. Это модуль для демона, который реализует определенные функции заданные спецификацией и колбеки. Которые затем будет вызваны при необходимости демоном при приходе OID. То есть определенный модуль реализует работу для определенного узла с OID.
MIB Module <-> OID
Соответственно запрос к агенту посылается запрос с определенным OID. Демон смотрит по OID есть ли зарегистрированные модули для обработки такого OID. Если да до передает управление модулю, получает результат и отправляет назад.
Верно ?
P.S. Возникла проблема при настройке мониторинга (MRTG || Observium)для SNMPv3 нужен какой-то ContextEngineId. Вообще не могу найти что это такое, с рандомным вроде работает (MRTG), но хотелось бы узнать что это такое все таки.
Спасибо

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "SNMP принцип работы MIB файлов/баз данных" +/–

Сообщение от PavelR (??) on 07-Ноя-16, 23:09

>[оверквотинг удален]
>> Даймон может ответить на запросы к нему и без этих файлов.
>> Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть
>> нечто, что можно попробовать назвать MIB, но я не считаю это
>> правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB
>> написано определение:
> Спасибо.
> Если сейчас правильно понял, то ситуация такова.
> То есть MIB файл нужен для установки соответствия идентификатора к имени (как
> ДНС), а также несет информацию о данном узле, типе переменной, режиме
> записи....
Это справочник. Реализация может отличаться от справочника. Пофиг что в справочнике написано RO, даймон может реализовать RW и сделать по нему запись чего-то вообще левого (ну бэкдор например).
> Соответственно запрос к агенту посылается запрос с определенным OID. Демон смотрит по
> OID есть ли зарегистрированные модули для обработки такого OID. Если да
> до передает управление модулю, получает результат и отправляет назад.
> Верно ?
Ну примерно так, но всегда есть вариации.
> P.S. Возникла проблема при настройке мониторинга (MRTG || Observium)для SNMPv3
> нужен какой-то ContextEngineId. Вообще не могу найти что это такое, с
> рандомным вроде работает (MRTG), но хотелось бы узнать что это такое
> все таки.
https://tools.ietf.org/html/rfc5343

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "SNMP принцип работы MIB файлов/баз данных"	+/–
Сообщение от PavelR (??) on 06-Ноя-16, 11:59
> Здравствуйте, пытаюсь разобраться со возможными средствами мониторинга сети. > Сейчас пытаюсь настроить простой мониторинг с помощью SNMP протокола с использованием таких > утилит как Cactie, MRTG ... (не столь важно). > Сам протокол предельно понятен и прост в понимании. http://www.k-max.name/linux/snmp-protocol/ > Вопрос зачем это делать ? Насколько я понимаю подгружается весь файл/файлы из > иерархии. Допустим у меня есть маленький роутер, с каким-то openwrt на > борту я хочу мониторить его состояние. Зачем мне качать все эти > файлы, если роутер будет хранить информацию про самые базовые показатели (пакеты, > аптайм, память ...). Зачем качать все файлы/один большой для всех вендоров, > если нужно работать только с несколькими нодам в этом дереве ? Да вроде не надо качать, если стандартные показатели смотреть. > 4. Каким образом происходит работа с этой самой MIB базой/файлом на агенте > (устройство для мониторинга). А именно как записываются данные в эту базу > ? MIB база это база описаний, что по каким адресам находится. Это не база значений. >В первом случае предположим что хотим записать информацию в какую-то > ноду в дереве. Система например хочет записать информацию о количестве принятых > пакетов. Кто за это ответственный и как это происходит. Демон считывает > сам определенную информацию ? Демон считывает информацию каким-либо образом, например если мы говорим про количество пакетов, то он это делает вычитывая файл "/proc/net/snmp". "snmp" в названии файла вполне могло бы быть заменено например на более общее "statistics" >Это происходит по тому же протоколу SNMP только с локального хоста? нет > Запускаются какие-то скрипты которые берут информацию > о системе и отдают демону или же сами записывают в MIB > файл. Это делает snmp-daemon при поступлении к нему запроса. Демон же и отвечает на запрос, файл на запрос ответить не может. Повторю еще раз: в MIB-файл ничего не пишется. Любая программа может реализовать SNMP протокол и к ней можно будет обратиться за её внутренней статистикой. Примеры: squid, amavisd-new. > 5. Что нужно делать если хочу добавить свой кастомный идентификатор(ноду) в базу > данных. По идее можно просто не устанавливать все файлы, а сделать > кастомный и подсунуть его демону ? Например я хочу считать информацию > о датчиках температуры проца через псевдо файловую систему /proc. Каким образом > это все связать со всей этой системой. В snmpd есть возможность запускать скрипты и возвращать значения на основе их вывода. Также в snmpd есть такая функция как "агенты".
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от CROSP (ok) on 06-Ноя-16, 16:22
	> Без БД: > # snmpwalk -v 2c localhost -u xxxx -c xxxx .1.3.6.1.4.1.795 > iso.3.6.1.4.1.795.14.1.100.1.0 = INTEGER: 1 > iso.3.6.1.4.1.795.14.1.100.2.0 = INTEGER: 4 Спасибо большое Вам за ответ. То есть насколько я понял MIB нужен только для того, чтобы использовать имя вместо идентификатора ? За статью отдельное спасибо, часто черпал полезную инфу с этого ресурса. Еще пару вопросов возникло, если не сложно, ответьте пожалуйста. 1. Каким образом при посылке какого-то OID snmpd знает куда смотреть, что запускать и так далее ? 2. Каким образом составлено это дерево ? То есть каждый раз когда кого-то вносять в официальную спецификацию нужно обновлять демон и другие утилиты которые используют это дерево ? 3. Выходит что демон отдает данные которые где-то хранятся текущее только или читает от какого-то скрипта. 4. Вы сказали что в MIB ничего не записывается. Вот просто из статьи той что Вы скинули. >Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Спасибо еще раз.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от PavelR (??) on 06-Ноя-16, 21:44
	>> Без БД: >> # snmpwalk -v 2c localhost -u xxxx -c xxxx .1.3.6.1.4.1.795 >> iso.3.6.1.4.1.795.14.1.100.1.0 = INTEGER: 1 >> iso.3.6.1.4.1.795.14.1.100.2.0 = INTEGER: 4 > Спасибо большое Вам за ответ. То есть насколько я понял MIB нужен > только для того, чтобы использовать имя вместо идентификатора ? Да. Непосредственно в протоколе бегают именно идентификаторы. > 1. Каким образом при посылке какого-то OID snmpd знает куда смотреть, что > запускать и так далее ? Это его внутренняя реализация, а также его конфигурация, если мы говорим про то, что определенную ветку он должен отправить на какого-то агента / скрипт и т д. > 2. Каким образом составлено это дерево? То есть каждый раз когда > кого-то вносять в официальную спецификацию нужно обновлять демон и другие утилиты > которые используют это дерево ? Что значит - используют? Я показал в примере, что _отображать_ информацию можно вообще без MIB. А чтобы _формировать_ значения для _новых_ данных, естественно надо что-то обновлять на стороне, которую опрашиваем - демон/конфигурацию/агента. > 3. Выходит что демон отдает данные которые где-то хранятся текущее только или > читает от какого-то скрипта. А как иначе? > 4. Вы сказали что в MIB ничего не записывается. Вот просто из > статьи той что Вы скинули. >>Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. Ну на заборе.... Вы сами файлы MIB видели? Вот в них 146% ничего не записывается. > Спасибо еще раз.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от CROSP (ok) on 07-Ноя-16, 13:06
	>> 4. Вы сказали что в MIB ничего не записывается. Вот просто из >> статьи той что Вы скинули. >>>Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу данных MIB. > Ну на заборе.... > Вы сами файлы MIB видели? Вот в них 146% ничего не записывается. Спасибо еще раз за ответ. Я решил не гадать и искать где все будет разложено по полочкам. А открыл сорцы snmp_agent и также с ним вместе идут некоторые mib файлы. Почитав на офф сайте информацию по MIB http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a... http://net-snmp.sourceforge.net/wiki/index.php/Agent_Archite... Вот тут есть фраза >>>MIB modules, which are responsible for implementing portions of the MIB tree, have the opportunity to register callbacks for any portion of the MIB tree when they are initialized. Registrations can functionally come from any of the following sources: >>>MIB Modules register themselves by defining two things a netsnmp_handler_registration structure containing "where" in the OID tree to register the MIB a netsnmp_mib_handler structure indicating "what" code is registering to handle the requests >>>The name "handler" is exactly what it sounds like: it is a mechanism that "handles a request". The term is used frequently throughout the API. То есть насколько я понимаю MIB файлы или же модули это просто код который обрабатывает запросы по определенному OID. При запуске демона все подключенные и скомпилированные модули подгружаются и регистрируют сами себя на определенный OID в дереве. Скачав сорцы перешел в директорию net-snmp-5.7.3\net-snmp-5.7.3\agent\mibgroup\udp-mib\data_access И как я и предполагал тут много файлов для разных систем. (Linux, Solaris, BSD ...) Открыв файл udp_endpoint_linux.c static int _load4(netsnmp_container container, u_int load_flags) { netsnmp_file fp; netsnmp_line_process_info lpi; if (NULL == container) return -1; /* * allocate file resources / fp = netsnmp_file_fill(NULL, "/proc/net/udp" , O_RDONLY, 0, 0); if (NULL == fp) /* msg already logged / return -2; memset(&lpi, 0x0, sizeof(lpi)); lpi.mem_size = sizeof(netsnmp_udp_endpoint_entry); lpi.process = _process_line_udp_ep; lpi.user_context = (void)0; container = netsnmp_file_text_parse(fp, container, PM_USER_FUNCTION, 0, &lpi); netsnmp_file_release(fp); return (NULL == container); } То есть все данные берутся из псевдо файловой системы /proc/ модулем MIB (в данном случае UDP). Соответственно MIB нужны для того чтобы отвечать на определенный запрос в дереве по OID, также обрабатывать запись. Поэтому для каждой ветки в дереве должне быть свой хендлер и по умолчанию имеется определенный набор файлов MIB который скомпилированы под определенную систему. Верно я понимаю ? Или опять что-то навыдумывал ? Спасибо
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от PavelR (??) on 07-Ноя-16, 15:42
	> Спасибо еще раз за ответ. Я решил не гадать и искать где > все будет разложено по полочкам. А открыл сорцы snmp_agent и также > с ним вместе идут некоторые mib файлы. > Почитав на офф сайте информацию по MIB > http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a... > http://net-snmp.sourceforge.net/wiki/index.php/Agent_Archite... > Вот тут есть фраза >>>>MIB modules, which are responsible for implementing portions of the MIB tree, have the opportunity to register callbacks for any portion of the MIB tree when they are initialized. Registrations can functionally come from any of the following sources: >>>>MIB Modules register themselves by defining two things Естественно, что даймон, которого мы можем опрашивать по SNMP, знает, какие счетчики он знает. Естественно, что у него внутри есть какие-то куски кода, которые знают, какие значения выдать в ответ на запрос определенного OID. Называть ли это MIB или нет? В одном из пониманий - нет, не называть. Посмотрите на .mib - файлы, которые вы скачали. Даймон может ответить на запросы к нему и без этих файлов. Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть нечто, что можно попробовать назвать MIB, но я не считаю это правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB написано определение: >"MIB is short for Management Information Base. MIBs are written in the SMI language" > a netsnmp_handler_registration structure containing "where" in the OID tree to register > the MIB > a netsnmp_mib_handler structure indicating "what" code is registering to handle the requests >>>>The name "handler" is exactly what it sounds like: it is a mechanism that "handles a request". The term is used frequently throughout the API. > То есть насколько я понимаю MIB файлы или же модули это просто > код который обрабатывает запросы по определенному OID. Я предлагаю разделить отдельно "MIB файлы" описания и модули, которые обрабатывают запросы по определенным OID. >При запуске демона все подключенные и скомпилированные модули подгружаются и > регистрируют сами себя на определенный OID в дереве. Что-то вроде того. > Скачав сорцы перешел в директорию net-snmp-5.7.3\net-snmp-5.7.3\agent\mibgroup\udp-mib\data_access ... > То есть все данные берутся из псевдо файловой системы /proc/ модулем MIB > (в данном случае UDP). Здесь - берутся из proc, где-то берутся еще как-то. > Соответственно MIB нужны для того чтобы отвечать на определенный запрос в дереве > по OID, также обрабатывать запись. В моем понимании чтобы отвечать на определенный запрос должен быть соответствующий модуль. MIB - это база описаний. Загляните в каталог mibs/ архива. > Поэтому для каждой ветки в дереве > должне быть свой хендлер и по умолчанию имеется определенный набор файлов > MIB который скомпилированы под определенную систему. MIB - это база описаний. Загляните в каталог mibs/ архива. > Верно я понимаю ? Или опять что-то навыдумывал ? Надо определиться и согласовать терминологию. > Спасибо
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от CROSP (ok) on 07-Ноя-16, 18:50
	>[оверквотинг удален] > Естественно, что у него внутри есть какие-то куски кода, которые знают, какие > значения выдать в ответ на запрос определенного OID. > Называть ли это MIB или нет? > В одном из пониманий - нет, не называть. Посмотрите на .mib - > файлы, которые вы скачали. > Даймон может ответить на запросы к нему и без этих файлов. > Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть > нечто, что можно попробовать назвать MIB, но я не считаю это > правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB > написано определение: Спасибо. Если сейчас правильно понял, то ситуация такова. Существуют MIB файлы (базы данных) в них описывается символические имена узлов в общем дереве и ставится соответствие для определенного OID. На счет последнего возник вопрос, где все таки прописывается соответствие идентификатору, вот взял пример. ifType OBJECT-TYPE SYNTAX IANAifType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of interface. Additional values for ifType are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the IANAifType textual convention." ::= { ifEntry 3 } То есть MIB файл нужен для установки соответствия идентификатора к имени (как ДНС), а также несет информацию о данном узле, типе переменной, режиме записи.... Опять же чтобы не запоминать эти ужасные айдишники используются символические имена. Также есть понятие MIB модуля. Это модуль для демона, который реализует определенные функции заданные спецификацией и колбеки. Которые затем будет вызваны при необходимости демоном при приходе OID. То есть определенный модуль реализует работу для определенного узла с OID. MIB Module <-> OID Соответственно запрос к агенту посылается запрос с определенным OID. Демон смотрит по OID есть ли зарегистрированные модули для обработки такого OID. Если да до передает управление модулю, получает результат и отправляет назад. Верно ? P.S. Возникла проблема при настройке мониторинга (MRTG \|\| Observium)для SNMPv3 нужен какой-то ContextEngineId. Вообще не могу найти что это такое, с рандомным вроде работает (MRTG), но хотелось бы узнать что это такое все таки. Спасибо
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "SNMP принцип работы MIB файлов/баз данных"	+/–
	Сообщение от PavelR (??) on 07-Ноя-16, 23:09
	>[оверквотинг удален] >> Даймон может ответить на запросы к нему и без этих файлов. >> Если называть MIB структуру внутри памяти процесса, то да, внутри процесса есть >> нечто, что можно попробовать назвать MIB, но я не считаю это >> правильным, т.к. это не полноценная MIB, про которую тут http://net-snmp.sourceforge.net/wiki/index.php/MIB >> написано определение: > Спасибо. > Если сейчас правильно понял, то ситуация такова. > То есть MIB файл нужен для установки соответствия идентификатора к имени (как > ДНС), а также несет информацию о данном узле, типе переменной, режиме > записи.... Это справочник. Реализация может отличаться от справочника. Пофиг что в справочнике написано RO, даймон может реализовать RW и сделать по нему запись чего-то вообще левого (ну бэкдор например). > Соответственно запрос к агенту посылается запрос с определенным OID. Демон смотрит по > OID есть ли зарегистрированные модули для обработки такого OID. Если да > до передает управление модулю, получает результат и отправляет назад. > Верно ? Ну примерно так, но всегда есть вариации. > P.S. Возникла проблема при настройке мониторинга (MRTG \|\| Observium)для SNMPv3 > нужен какой-то ContextEngineId. Вообще не могу найти что это такое, с > рандомным вроде работает (MRTG), но хотелось бы узнать что это такое > все таки. https://tools.ietf.org/html/rfc5343
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору