Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 675 / 67 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 8:

Управление событиями с использованием NNM

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >

Управление историями событий и trapd.log

Поведение версий, предшествующих NNM 6.0, предусматривает журнализацию всех событий в файле $OV_LOG/trapd.log и сброс этого файла в $OV_LOG/trapd.log.old при достижении заданного размера. Этот предельный размер устанавливается в $OV_LRF/pmd.lrf в виде параметра —$OV_EVENT;t;lsize, где l – это буква L в строчном регистре, а size – предельное значение размера файла в мегабайтах. Когда начинает выполняться xnmevents, он сканирует оба файла. Эта команда также сохраняет отдельный журнал событий для каждого пользователя в файле с именем xnmevents.username. Так поддерживается уведомление о приеме событий индивидуальных пользователей.

Поведение NNM 6.0 в высшей степени отличается от поведения его предшественников. По умолчанию события не сохраняются в trapd.log, а вместо этого фиксируются в базе данных событий. К счастью, можно обеспечить и журнализацию в trapd.log, если это критично для функционирования. Для этого требуется внести опцию –SOV_EVENT;t в файл pmd.lrf, зарегистрировать файл с помощью команды $OV_BIN/obaddobj $OV_LF/pmd.lrf и остановить и запустить pmd. Если решено в основном пользоваться новой базой данных событий, но время от времени полагаться на trapd.log, то можно применить команду ovdumpevents, чтобы создать файл, содержащий необходимые данные.

В NNM 6.0 и более поздних версиях используется средство eventdb, а прерывания и события сохраняются в базе данных в каталоге $OV_DB/eventdb/. По умолчанию размер базы данных составляет 16 мегабайт. Для изменения этого параметра следует использовать опцию OV_EVENT;bsize в pmd.lrf ( b – это буква b, а size – размер базы данных в мегабайтах). Браузер событий взаимодействует с этой базой данных, а ov_event помещает в нее журнальные записи.

Укрощение шторма событий с помощью ECS

В NNM 6.0 внедрены службы установления соотношения событий (ECS) для обеспечения средств разумной интерпретаций потока событий, ограничения его объема и повышения качества. Это решает проблему обслуживания событий в большой сети, где они могут исчисляться сотнями в минуту. Одиночная аварийная ситуация может породить тысячи событий. Поскольку невозможно реагировать на все эти события, менеджеры сети могли бы прибегнуть к какому-либо варианту из следующего списка:

Потоки событий в NNM

Рис. 8.5. Потоки событий в NNM

Эта схема очень высокого уровня показывает потоки данных между базами данных и демонами в NNM.

  • игнорировать все сообщения, кроме того случая, когда критическое устройство выходит из строя;
  • переконфигурировать большинство сообщений в режим только регистрации;
  • управлять только критическими сигналами;
  • использовать фильтр браузера событий NNM для ограничения числа событий;
  • приобрести инструментальное средство для фильтрации событий у независимого поставщика.

Фильтр браузера событий NNM позволяет сконфигурировать следующие критерии для ограничения числа отображаемых событий:

  • уровень серьезности;
  • исходные IP-адреса;
  • метасимвол для указания диапазона IP-адресов или имен узлов;
  • подтвержденные или неподтвержденные сигналы;
  • временной промежуток сигнала;
  • поиск слова в строке сообщения;
  • тип события.
Таблица 8.2. Правила установления соотношения событий в редакции, связанной с NNM
Наименование правила Описание
Connector Down Разрыв соединения Для привязки исходной причины каскада отказов устройств к конкретному соединительному звену используется топология сети. Это позволяет избежать наличия вала событий, и в браузере событий журнализируется одно событие. Устройство, послужившее причиной, показывается в виде красной пиктограммы, а пиктограммы затронутых им устройств окрашены в синий цвет (состояние неизвестно)
Scheduled Maintanance Плановое обслуживание При выключении устройств, запланированных для обслуживания, NNM обычно генерирует сигналы. Это правило определяет, какие устройства или какой диапазон IP-адресов следует игнорировать, начиная с указанного времени в течение заданного интервала
Repeated Event Повторное событие Предусмотрено для подавления связанных событий, относящихся к конкретному устройству. Например, без этого правила при изменении MAC-адрес устройства проверка системой NNM ARP-кэшей соседних устройств заставит NNM сообщать о несоответствии каждого из них
Pair Wise Парные события Устанавливается соответствие нескольких прерываний в некоторый промежуток времени, идентифицируется исходное прерывание, и об этом извещается браузер сигналов
MgXServer Down Выход из строя сервера ManageX Появившаяся впервые в NNM 6.1, эта схема позволяет устанавливать соответствие событий между системами HP OpenView Network Node Manager и HP OpenView ManageX

Простая фильтрация событий является очень грубым методом ограничения потока событий до тоненького ручейка. Имеются крупицы ценной информации, скрытые в потоке событий, и правильный способ их обнаружения состоит в использовании ECS. Желательно идентифицировать причину проблемы, а не наблюдать все результирующие симптоматические события. На рис. 8.5 представлен общий вид потока событий в рамках NNM. Заметим, что ECS активизируется по умолчанию. Обеспечивается несколько связанных с NNM правил установления соотношения событий, как это описано в таблице 8.2. Точный набор поставляемых правил изменяется с каждой версией NNM. Дополнительные правила можно получить от сторонних поставщиков, от консультантов HP, или написав собственные правила на основе использования средства ECS Designer для продуктов NNM.

< Лекция 7 || Лекция 8: 1234 || Лекция 9 >