IBM Tivoli Netcool/OMNIbus, Версия 8.1

Импорт данных MIB

Как импортировать данные SNMP MIB в MIB Manager.

Прежде чем начать

В окне Предпочтения укажите положения MIB, которые регулярно используются для MIB поставщиков. Убедитесь, что ваши MIB расположены в заданных для поставщиков каталогах, а все номера связанного оборудования содержатся в подкаталогах. Убедитесь также, что в этих каталогах нет других, отличных от MIB, текстовых файлов. Большинство MIB устанавливаются в каталог ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/mibs/base, а все RFC MIB - в каталог ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/mibs/rfc.

Импортированные вами MIB могут зависеть от других MIB. Чтобы обеспечить для MIB Manager возможность искать зависимые MIB при выполнении импорта, задайте путь поиска к положениям зависимых файлов MIB.

Процедура

Чтобы импортировать данные MIB:

  1. Щелкните по значку Значок Импорт MIB Импорт или в меню выберите пункт Файл > Импорт.
  2. В поле Каталог укажите положение модулей MIB, которые вы хотите импортировать.
  3. Чтобы MIB Manager мог произвести синтаксический анализ всех MIB, обнаруженных в доступных подкаталогах, включите переключатель Просмотреть подкаталоги.
  4. Нажмите кнопку Импорт.

    Во время синтаксического анализа модулей MIB выводится окно Состояние импорта. В левой части этого окна выводится число различных типов объектов MIB, увеличивающееся по мере обнаружения каждого из них во время синтаксического анализа импортированных файлов MIB.

    Когда синтаксический анализ MIB завершен, MIB Manager проверяет каждый модуль MIB и анализирует все расположенные в нем объекты MIB. После завершения синтаксического анализа всех объектов MIB Manager проверяет каждый MIB и обрабатывает операторы импорта, чтобы обнаружить все модули MIB, на которые существуют ссылки. Если в ранее импортированных модулях MIB не удается найти все модули MIB, на которые существуют ссылки, MIB Manager проводит поиск в подкаталогах, заданных в пути поиска. В правой части окна Состояние импорта представлены значки, показывающие состояния всех операторов импорта, обнаруженных в импортированных MIB, как это перечислено в следующей таблице:
    Значок Описание
    Вопросительный знак Означает, что оператор импорта не был разрешен.
    Галочка Означает, что оператор импорта был разрешен.
    Крест Означает, что модуль MIB, на который есть ссылка в операторе импорта, не разрешен.

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

    Заголовок Импорт завершен выводится в верхней части фрейма состояний, когда обработаны все импортированные файлы MIB. Можно просмотреть все сообщения о состоянии, сгенерированные во время импорта, щелкнув по Просмотреть хронологию состояний и используя выпадающий список Представление для выбора опций фильтра.

  5. Щелкните по Отклонить, чтобы закрыть окно Состояние импорта.

Результаты

Представление Модули MIB автоматически обновляется, чтобы показать имена новых импортированных модулей MIB. Представление Дерево OID автоматически обновляется, чтобы показать все импортированный объекты MIB. Для перепостроения дерева MIB Manager рекурсивно ищет родительские узлы дерева (iso, ccitt и joint-iso-ccitt) для дочерних узлов, пока не будет найден дочерний узел, у которого нет связанных дочерних элементов. Если не обнаруживаются ошибки, целиком заполненное дерево MIB выводится в представлении Дерево OID , содержащем проанализированные объекты.

Если щелкнуть по объекту в представлении Дерево OID, объект будет автоматически показан в представлении Модули MIB. В представлении Подробности выводится подробная информация о выбранном объекте.

Импортированные модули MIB хранятся в файле XML, представляющем структуру данного модуля MIB. Эти файлы XML расположены в каталоге ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/data.

Если обнаруживаются неразрешенные операторы импорта, обратитесь к поставщику, ответственному за отсутствующие MIB, добавьте отсутствующий файл или файлы в путь поиска и повторите операцию импорта.

Прим.:

Иногда поставщики указывают дублированные имена объектов или имя объекта, совпадающее с именем объекта, заданным в RFC.

Например, объект с именем system может быть определен в модуле SNMPv2-MI' с OID 1.3.6.1.2.1.1, а другой объект с именем system - в модуле WINDOWS-NT-PERFORMANCE с OID 1.3.6.1.4.1.311.1.1.3.1.1.23. Также объект с именем sysDescr может быть определен как system.1 в модуле SNMPv2-MIB, а другой объект с именем sysFileReadOperationsPerSec - как system.1 в модуле WINDOWS-NT-PERFORMANCE. В этом случае неясно, с каким родительским объектом связаны дочерние объекты.

Когда обнаружен объект с дублированным родительским именем, MIB Manager пытается найти родительский объект, определенный в том же модуле MIB. В предыдущем примере это модуль WINDOWS-NT-PERFORMANCE. Если в том же модуле MIB не определен ни один из родительских объектов, MIB Manager ищет, не определен ли родительский объект в другом модуле MIB, от которого этот объект зависим. MIB Manager определяет также другие модули MIB, которые ссылаются на родительский объект, и выбирает родительское имя, на которое существует более всего ссылок. Однако этот способ выбора может привести к неправильному заполнению дерева MIB и к неправильному вычислению OID. Поэтому каждый раз, когда MIB Manager находит дублированное имя объекта, этот компонент производит запись в журнал отладки предупреждения, а также действий, предпринятых для исправления дублирования.


Библиотека | Поддержка |