Управление событиями с использованием NNM
Управление историями событий и 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.
- игнорировать все сообщения, кроме того случая, когда критическое устройство выходит из строя;
- переконфигурировать большинство сообщений в режим только регистрации;
- управлять только критическими сигналами;
- использовать фильтр браузера событий NNM для ограничения числа событий;
- приобрести инструментальное средство для фильтрации событий у независимого поставщика.
Фильтр браузера событий NNM позволяет сконфигурировать следующие критерии для ограничения числа отображаемых событий:
- уровень серьезности;
- исходные IP-адреса;
- метасимвол для указания диапазона IP-адресов или имен узлов;
- подтвержденные или неподтвержденные сигналы;
- временной промежуток сигнала;
- поиск слова в строке сообщения;
- тип события.
Простая фильтрация событий является очень грубым методом ограничения потока событий до тоненького ручейка. Имеются крупицы ценной информации, скрытые в потоке событий, и правильный способ их обнаружения состоит в использовании ECS. Желательно идентифицировать причину проблемы, а не наблюдать все результирующие симптоматические события. На рис. 8.5 представлен общий вид потока событий в рамках NNM. Заметим, что ECS активизируется по умолчанию. Обеспечивается несколько связанных с NNM правил установления соотношения событий, как это описано в таблице 8.2. Точный набор поставляемых правил изменяется с каждой версией NNM. Дополнительные правила можно получить от сторонних поставщиков, от консультантов HP, или написав собственные правила на основе использования средства ECS Designer для продуктов NNM.