Opened 9 years ago
Closed 7 years ago
#93 closed улучшение (fixed)
Конфигурировать корневую ноду SNMP OID'ов
| Reported by: | alx | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: |
Description (last modified by )
Сейчас MIB блока 3U всегда находится в ветке { adc 9999 }. В случае когда требуется мониторить
несколько разных блоков с разной набивкой и, следовательно, разными MIB, возникает проблема подключения этих MIB к SNMP менеджеру.
Предлагается сделать конфигурационный параметр, который можно настраивать на вкладке SNMP, и который будет задавать корневую ноду для каждого борка.
Там же можно поместить ссылку на генерацию MIB.
Change History (11)
follow-up: 2 comment:1 by , 7 years ago
| Description: | modified (diff) |
|---|
follow-up: 3 comment:2 by , 7 years ago
Replying to san:
У меня было немного другое предложение, для решения проблемы пересечении мибов:
- Существующую структуру дерева
adc.m3U160.slots.<№ слота>.<переменная платы>изменить наadc.m3U16.slots.<№ слота>.<тип платы>.<переменная платы>, т.е в каждом слоте будут отдельные ветки для разных типов плат которые могут быть установлены в слот.
Это решение мне не нравится по нескольким причинам. Или, можно назвать их проблемами.
Первая проблема: MIB присутствующей платы мы получаем чтением из нее переменной .4.0. А как получить MIB платы, которой нет? :) :) :)
Вторая проблема: это нарушит совместимость с ранее выпущенными платами, так как в OID добавляется новый элемент.
Третья проблема: допустим, мы каким-то телепатическим чудом (см. первую проблему) получили MIB отсутствующей платы. А что должен возвращать агент в ответ на запрос чтения OID отсутствующей платы?
В моём представлении у этого варианта есть преимущество в том, что будет возможно сделать универсальный миб(очень большой конечно) описывающий все варианты набивки блоков.
Расскажи, пожалуйста, каким образом такое, по-твоему, возможно. Я такой возможности не вижу. Так как MIB каждой платы хранится в ней самой, мне представляется принципиально невозможным сформировать MIB блока до того как платы будут в него вставлены и опрошены...
follow-up: 4 comment:3 by , 7 years ago
Первая проблема: MIB присутствующей платы мы получаем чтением из нее переменной .4.0. А как получить MIB платы, которой нет? :) :) :)
Так как MIB каждой платы хранится в ней самой, мне представляется принципиально невозможным сформировать MIB блока до того как платы будут в него вставлены и опрошены...
Я подразумевал создание универсального миба не блоком, а нами и выкладывание его на сайт, например.
Вторая проблема: это нарушит совместимость с ранее выпущенными платами, так как в OID добавляется новый элемент.
платами - всмысле sw? Да, нарушит.
Третья проблема: допустим, мы каким-то телепатическим чудом (см. первую проблему) получили MIB отсутствующей платы. А что должен возвращать агент в ответ на запрос чтения OID отсутствующей платы?
Интересный вопрос :) Получится дерево с немногими "живыми" ветками и остальными в непонятном виде. Да, совсем плохо выглядит. Соглашусь, что мой вариант нежизнеспособен.
Зато теперь я понял и могу сформулировать основное что мне не нравится в твоём варианте, и почему я пытался предложить какие-то альтернативы.
Сейчас в любом блоке можно опросить общие аварии плат по одним и тем-же oid. Т.е. можно настроить общее правило для всех блоков и при аварии менеджер будет знать какая плата виновата. И такая возможность позволяет быстро включить блоки в мониторинг, а потом уже неспешно разбирать мибы.
В случае если у блоков будут разные "корни", то "по быстрому" уже не получится и для каждого блока придётся создавать отдельные правила в менеджере.
Не знаю насколько это важно, возможно я преувеличиваю )
А в общем, судя по всему, твой вариант - единственно возможный способ решить нашу проблему с мибами.
comment:4 by , 7 years ago
Replying to san:
Так как MIB каждой платы хранится в ней самой, мне представляется принципиально невозможным сформировать MIB блока до того как платы будут в него вставлены и опрошены...
Я подразумевал создание универсального миба не блоком, а нами и выкладывание его на сайт, например.
Да какая разница, нами или не нами? :) Не зная заранее, какие MIB'ы будут в установленных платах (а этого никто кроме, может быть, гадалок с хрустальными шарами не знает), сформировать MIB блока невозможно. Независимо от того, кто будет пытаться его сформировать, и куда он его потом выложит. :)
В случае если у блоков будут разные "корни", то "по быстрому" уже не получится и для каждого блока придётся создавать отдельные правила в менеджере.
Но по умолчанию-то значение корня по-прежнему будет одним и тем же - как и раньше, 9999! То есть, получив с завода новую плату/новый блок, его можно сразу ("по-быстрому", как ты пишешь) начинать опрашивать из корня 9999. И, как и было до сегодняшнего дня, подавляющее большинство пользователей это устроит. А вот когда и если у кого-то возникнет желание играться с MIB'ами - то он, если надо, корень поменяет. И проблемы у него не будет, ведь изменение корня - не самоцель, а средство получить MIB-файл, не конфликтующий с другими существующими. Следовательно, сразу после изменения корневого OID'а будет сгенерирован MIB и скормлен менеджеру. И менеджер начнет опрос... Я не вижу здесь проблемы...
follow-up: 6 comment:5 by , 7 years ago
Не зная заранее, какие MIB'ы
Мы ведь знаем мибы плат которые производим, и при появлении новой платы можем обновлять миб, но это уже не важно.
Я не вижу здесь проблемы...
Согласен
comment:6 by , 7 years ago
Replying to san:
Не зная заранее, какие MIB'ы
Мы ведь знаем мибы плат которые производим, и при появлении новой платы можем обновлять миб, но это уже не важно.
Встречный вопрос: а зачем вообще тогда придумана стандартная переменная .4.0, с помощью которой мы запрашивает у платы ее MIB? Исходя из логики, что мы и так всегда знаем мибы плат, которые производим, зачем все эти сложности с запросами MIB'ов каждой платы и составлением динамической базы? Насколько было бы проще всего этого не делать! :)
Мы ведь для того все это и придумали, чтобы swd мог работать с платами, прошивки которых новее его самого, и содержат нечто, о чем он знать не мог на момент своего выхода... Кроме того, обратная ситуация (когда плата в блоке старее чем последний MIB) не намного лучше (если не хуже): в MIB'е переменная прописана, но при попытке обращения к ней плата возвращает ошибку...
comment:7 by , 7 years ago
Просто пояснил что я имел ввиду в первом комменте, с твоими аргументами согласен.
comment:8 by , 7 years ago
| Milestone: | 2 очередь → 1 очередь |
|---|
Переставлю в первую очередь в связи с появившейся заинтересованностью пользователей.
comment:9 by , 7 years ago
Там же можно поместить ссылку на генерацию MIB.
Ещё туда бы поместить корневой миб аппаратуры АДС, или ссылку на него (выложить mib на наш сайт)
comment:10 by , 7 years ago
| Summary: | Конфигурировать корневую ноду SNMP IOD'jd → Конфигурировать корневую ноду SNMP OID'ов |
|---|
У меня было немного другое предложение, для решения проблемы пересечении мибов:
adc.m3U160.slots.<№ слота>.<переменная платы>изменить наadc.m3U16.slots.<№ слота>.<тип платы>.<переменная платы>, т.е в каждом слоте будут отдельные ветки для разных типов плат которые могут быть установлены в слот.adc.m3U160.slots.<№ слота>.0.[1..4]значения "стандартных" переменных установленной платы (для упрощенного опроса общих аварий плат и возможного автоматического определения менеджером нужных переменных в зависимости от типа платы)В моём представлении у этого варианта есть преимущество в том, что будет возможно сделать универсальный миб(очень большой конечно) описывающий все варианты набивки блоков.