Jump to content
Калькуляторы

За что так вендоры не любят SNMP?

Крайняя прошивка на сиське из ветки 15.4(3)S6a

 

[root@net-mon-01 /usr/home/lion]# snmpbulkget -Cr100 10.0.6.24 .1.0.8802.1.1.2.1.3.7.1.2
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
и так далее по кругу...

 

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

Все вендоры, с которыми работал, имеют те или иные проблемы с SNMP.

 

Это не вопрос был, а пятиминутка ненависти.

Share this post


Link to post
Share on other sites

У Хуавея вообще нельзя использовать камьюнити public и private. Камьюнити обязательно должно быть буквенно-циферным.

Share this post


Link to post
Share on other sites

Добавил в своего опрашивателя проверку циклов.

Share this post


Link to post
Share on other sites

Присоединяюсь к пятиминутке. Сам SNMP архитектурно, конечно, редкостное убожество.

Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А уж подобие SQL было бы вообще манной небесной.

 

SELECT ig.interfaceName, ig.lineCardNumber, id.portNumber, ig.runningState, ic.trafficIn, ic.trafficOut FROM interfaces.general ig INNER JOIN interfaces.counters ic ON (ig.id = ic.id) WHERE (ig.type = 'physical') AND (ig.interfaceName LIKE 'Gigabit%') AND (ig.adminState <> 'shutdown')

 

SELECT ps.powerSupplyName, ps.slotNumber, ps.unitNumber, ps.currentPowerAmps, cp.maxPowerAmps FROM hardware.powerSupplies ps

 

Мечты, мечты...

 

И ведь железо по производительности такие финты давно позволяет делать. Даже эмбедовка. Ээээх. А пользоваться приходится древнющим тормозным монструозным ASN.1-based.

Share this post


Link to post
Share on other sites

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

bulkwalk юзайте или скармливайте набор параметров, которые хотите получить (второе правильнее).

 

Сам SNMP архитектурно, конечно, редкостное убожество.

архитектура вполне себе ок, для тех девайсов под которые он разрабатывался. в сотню байт RAM и пару килобайт кода без особого напряга влазит v1, и скорее всего даже v2.

 

то, что нормально много кто не осилил спеки почитать (+ сами спеки нормальные найти проблематично) - это да...

 

ну и отдельных лучей поноса заслуживает AFAIK безальтернативный net-snmp демон. разжирел до невозможности, и при >1k интерфейсов безбожно тупит.

Share this post


Link to post
Share on other sites

У Хуавея вообще нельзя использовать камьюнити public и private. Камьюнити обязательно должно быть буквенно-циферным.

undo snmp community complexity-check

Как-то так.

Share this post


Link to post
Share on other sites
Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А это и есть SNMP... Только текстовые поля заменены на индексы из словаря. И словарь этот находится на опрашивающей стороне. Называется MIB... Чем это принципиально лучше/хуже, чем текстовые key я не понимаю. Разве что маски и регэкспы нельзя использовать. Но, со времён v2 запросы кучей стали дёшевы и проще спросить больше, чем надо и выкинуть лишнее, чем реализовывать регэкспы на стороне железки.

 

А уж подобие SQL было бы вообще манной небесной.

 

SELECT ig.interfaceName, ig.lineCardNumber, id.portNumber, ig.runningState, ic.trafficIn, ic.trafficOut FROM interfaces.general ig INNER JOIN interfaces.counters ic ON (ig.id = ic.id) WHERE (ig.type = 'physical') AND (ig.interfaceName LIKE 'Gigabit%') AND (ig.adminState <> 'shutdown')

 

SELECT ps.powerSupplyName, ps.slotNumber, ps.unitNumber, ps.currentPowerAmps, cp.maxPowerAmps FROM hardware.powerSupplies ps

Те же йяйтса. Только вместо регэкспов арифметика больше/меньше стайл. И также решается избытком запросов (копеечных) и сортировкой на опрашивающей стороне.

 

Иначе, дело пахнет ксеонами в свичках.

Share this post


Link to post
Share on other sites

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

bulkwalk юзайте или скармливайте набор параметров, которые хотите получить (второе правильнее).

Что? Я пример в самом начале привел. Какой такой "набор параметров", когда я таблицу получаю?

Share this post


Link to post
Share on other sites

Бывают вендоры корявые. Нормальные вендоры SNMP поддерживают и при необходимости подправляют (D-Link и Eltex нормально принимают багрепорты и исправляют). https://habrahabr.ru/post/206612/

Share this post


Link to post
Share on other sites

Кстати более глючного снмп чем на гепоне элтекса не видел. Вот там ад и израиль, тормоза, неустановка значений после сета...

Share this post


Link to post
Share on other sites

Ну не глючность скорее, а странность.

ЗТЕ шасси с220\с300\с320, вот где АДъ и израиль.

Если просто надо достать данные, то всё довольно просто. А вот сет пипец какой неоднозначный. Что б сменить влан нужно сеты отправлять строгой очередности. И при том одним пакетом по несколько штук оидов за раз.

Share this post


Link to post
Share on other sites
Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А это и есть SNMP... Только текстовые поля заменены на индексы из словаря. И словарь этот находится на опрашивающей стороне. Называется MIB... Чем это принципиально лучше/хуже, чем текстовые key я не понимаю. Разве что маски и регэкспы нельзя использовать. Но, со времён v2 запросы кучей стали дёшевы и проще спросить больше, чем надо и выкинуть лишнее, чем реализовывать регэкспы на стороне железки.

 

Иначе, дело пахнет ксеонами в свичках.

Неа. SNMP это /path/*, а не /path/*/path например. Ну и какие ксеоны если копеечный pi1 допустим вполне тянет полноценный mysql. А тут вообще речь об упрощенном диалекте и инмемори. Но что имеем то имеем, жрем кактус. Про балк отдельная тема, там тоже не все гладко - многие агенты (вся циска например) оптимизировать их внутри в балк не умеют, и все равно выгребают по 1 итему за заход. Т.е. нагрузка на цпу железки единофигственна и тормоза те же, только запрос-ответ типа оптом.

 

Вообще я под ущербностью архитектуры имел в виду вот именно эту идею с выгребанием каунтера за заход. Там особо не соптимизируешь. Ну и убожество индексации ещё. Даже лдап был бы лучше.

Share this post


Link to post
Share on other sites

ну и отдельных лучей поноса заслуживает AFAIK безальтернативный net-snmp демон. разжирел до невозможности, и при >1k интерфейсов безбожно тупит.

Потому что идеология - 1 итем за заход. А чтобы было шустрее - надо кешировать, а кеша нету да и лейтенси. Я для нетснмп делал прослойку в мемкачед из за этого.

Share this post


Link to post
Share on other sites

Я пример в самом начале привел

вы юзали bulkget. а не bulkwalk.

 

Какой такой "набор параметров", когда я таблицу получаю?

набор OID'ов которые надо получить. списком. а не "получить все".

 

Потому что идеология - 1 итем за заход. А чтобы было шустрее - надо кешировать, а кеша нету да и лейтенси.

там вроде не только в этом дело. 10-40% процессорного времени постоянно отожрано при 1к интерфейсов (причем - system) - как по мне бред. ушел на заббикс агент, все стало ок.

Share this post


Link to post
Share on other sites

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

 

На одном, всем известном оборудовании, можно получать любые параметры простыми удобными текстовыми запросами.

Share this post


Link to post
Share on other sites

Я пример в самом начале привел

вы юзали bulkget. а не bulkwalk.

 

snmpbulkwalk это такая команда из известного набора утилит. В протоколе метод GetBulkRequest, которые использут как snmpbulkwalk, так и моя, написаная на С утилита.

 

Какой такой "набор параметров", когда я таблицу получаю?

набор OID'ов которые надо получить. списком. а не "получить все".

В курсе, что в дереве MIB бывают таблицы? Таблица интерфейсов например?

Что далеко не всегда можно заранее знать количество и ifIndex всех имеющихся интерфейсов?

Также надеюсь очевидно, что агент не должен выдавать на getBulkRequest повторяющиеся циклично OIDы?

 

SNMP устаревшая технология

...

Share this post


Link to post
Share on other sites

На одном, всем известном оборудовании, можно получать любые параметры простыми удобными текстовыми запросами.

Можете привести пример?

Share this post


Link to post
Share on other sites

Блин, у истории продолжение - агент зацикливается на встроенных шести интерфейсах и дополнительные просто не отдает.

Share this post


Link to post
Share on other sites

Иначе, дело пахнет ксеонами в свичках.

Так уже давно ксеоны и прочие коры с гигабайтами ram, SSD и линуксом :)

Share this post


Link to post
Share on other sites

В курсе, что в дереве MIB бывают таблицы? Таблица интерфейсов например?

и чо?

 

Что далеко не всегда можно заранее знать количество и ifIndex всех имеющихся интерфейсов?

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

Share this post


Link to post
Share on other sites
практически всегда. ну как минимум

Ну как минимум сопоставить индекс интерфейса с dot3 индексом - та ещё благодать. Join'ов в SNMP не придумано, выборок по одному из полей таблицы - тоже.

При этом в пределах одного вендора разные железки могут не поддерживать половину вроде бы очевидных и необходимых счётчиков, или расположить их в совершенно другом дереве.

Вот в точно том же формате, но в другом дереве - особенно D-Link этим болеет. А выборок вида .1.2.3.4.5.<any>.1.2.3.1.1 - нет.

Если проще - древнющее гуано мамонта, которым, увы, приходится пользоваться. Никто ж тогда ещё не думал, что в него сотни взаимосвязанных параметров запихиваться будут. Не говоря уже о тысячах.

MIB'ы тоже... имеют читабельность, сходную с читабельностью наскальных иероглифических рисунков эпохи тех самых мамонтов.

Share this post


Link to post
Share on other sites

Ну так расположение одних и тех-же параметров в разных ветвях дерева не есть проблема протокола. Это проблема альтернативно одарённого вендора, а не SNMP.

 

А MIBы, их вообще "читать" не надо. Есть MIB браузер, им и смотрте.

Share this post


Link to post
Share on other sites

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

 

На одном, всем известном оборудовании, можно получать любые параметры простыми удобными текстовыми запросами.

 

Пробовал использовать API. Неудачно, документации почти нет, стандарт свой, библиотек нет. То что есть не работает с ходу. Спасибо, не надо.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this