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

Введение

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

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

Устройства в базе данных NNM находятся либо в управляемом, либо в неуправляемом состоянии. Неуправляемые устройства не опрашиваются, так что NNM не вырабатывает относящихся к ним событий. Управляющие станции принимают во внимание это различие при импортировании устройств с накопительных станций.

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

Маршрутизаторы и другие сетевые устройства могут передавать консольные журнальные сообщения в службу системной журнализации ( syslog service ), которая работает в системе NNM. Такие журнальные файлы можно программным путем проверять на предмет наличия критических условий, которые невозможно выявить с помощью SNMP, и оповещать о них систему событий NNM.

В NNM предопределяется шесть категорий событий, и разрешается определять новые категории. Например, можно определить специальную категорию событий Router Alarms, чтобы получать перенаправляемые сообщения syslog.

Каждое событие, определенное в NNM, можно модифицировать, чтобы приспособить к местным условиям. Для конкретных событий можно также определить специально настроенные действия. Это могут быть различные действия: от выполнения скрипта восстановления до отсылки e-mail-сообщения.

Для управления историями событий используется база данных событий, которая может быть старомодным плоским файлом trapd.log (в NNM 5.x и более ранних версиях) или средством eventdb, введенным в NNM 6.0. Поскольку полезно иметь возможность просматривать старые события, размер базы данных можно увеличивать, насколько это требуется.

Даже большая, хорошо управляемая сеть заставит NNM генерировать равномерный поток событий, а иногда и шторм событий. Служба установления соотношения событий (ECS) призвана содействовать сокращению этого потока до ручейка качественных событий. ECS можно настроить с помощью параметров, конфигурируемых пользователями, и расширить путем добавления схем соответствия.

В качестве исторической справки заметим, что для NNM 5.x и более ранних версий в HP определялись категории событий (event category) и обеспечивался браузер событий (event browser). В NNM 6.0 для тех же сущностей используются термины "категория сигналов тревоги" (alarm category) и "браузер сигналов тревоги" (alarm brouser). Основанием является следующее:

Управляемые и неуправляемые устройства

NNM подвергает управляемый объект регулярному опросу на предмет его состояния и конфигурации, а демон snmpCollect собирает данные SNMP от управляемого устройства. Пиктограмма управляемого объекта отражает его состояние. Неуправляемое устройство не опрашивается, и для него не собираются данные SNMP. Его состояние неизвестно, поэтому пиктограмма не отражает состояние своего контейнера. Цвет пиктограммы неуправляемого объекта – пшеничный.

Менеджеры сети часто не управляют устройствами или интерфейсами по разным причинам:

В предшествующих рассуждениях термины "объект" и "устройство" умышленно использовались неточно. Это объясняется тем, что одни объекты представляют собой реальные устройства, другие представляют интерфейсы и соединения, и имеются также абстрактные контейнеры объектов, такие как подсети и сегменты. Поэтому, если менеджер сети выделяет пиктограмму маршрутизатора и выбирает из меню пункт Edit:Unmanage, маршрутизатор и все его интерфейсы становятся неуправляемыми. Маршрутизатор является реальным устройством, как и его интерфейсы. Отдельный интерфейс может стать неуправляемым, если открыть пиктограмму маршрутизатора, выделить интерфейс и выбрать пункт меню Edit:Unmanage. Но неуправляемой может стать и пиктограмма абстрактного контейнера, такого как сегмент; это означает, что все устройства внутри контейнера становятся неуправляемыми.

Если на схеме видно, что устройство является неуправляемым, то означает ли это, что оно действительно не управляется? В тех случаях, когда это устройство находится в нескольких схемах, оно по-настоящему не управляется, только если является неуправляемым в каждой схеме. Если хотя бы одна схема содержит управляемый вариант устройства, то netmon будет его опрашивать. Реальное состояние управляемости устройства определяется с помощью команды ovtopodump –L device_name.

Заметим, что если устройство является неуправляемым в домене управления накопительной станции, и если это устройство экспортируется на управляющую станцию, то экспортируется и состояние неуправляемости. Предположим, что две или более накопительные станции управляют или не управляют данным устройством. Ситуация, когда это устройство относится к нескольким накопительным станциям, причиняет беспокойство, поскольку одна из них назначается для него основной, но какая? Существует девять правил, которыми руководствуется управляющая станция при выборе основной накопительной станции для объекта. Ответ на наш вопрос дают правила 3, 5 и 9:

Правило 3: Если только одна из многих возможных накопительных станций сообщает, что объект управляется, и что его состояние не критическое, то эта станция обладает основным правом собственности на данный объект.

Правило 5: Если только у одной накопительной станции данный объект имеется в управляемом состоянии (либо по умолчанию, либо в результате выбора), то эта станция назначается основной для данного объекта.

Правило 9: Первая накопительная станция, которая сообщает об объекте, считается управляющей станцией основной. Владение объектом не ограничивается этой накопительной станцией на тот случай, если накопительная станция прекратит отслеживать объект.

Полное рассмотрение этих правил представлено в главе 5 учебника HP OpenView Advanced Network Node Manager.

Заметим, что неуправляемое устройство может, тем не менее, посылать SNMP-прерывания на накопительную станцию, если в таблице пересылки прерываний его SNMP-агента содержится система управления NNM. В большинстве случаев меню NNM будут оперировать неуправляемыми устройствами.

Прерывания от ожидаемых и неожиданных источников

SNMP-прерывания по умолчанию передаются на порт UDP 162. В число источников SNMP-прерываний входят NNM и сетевые устройства. NNM генерирует внутренние прерывания (часто свободно именуемые событиями), называемые прерываниями, специфичными для предприятия (enterprise-specific). NNM также может генерировать специальные SNMP-прерывания в ответ на действия, запрограммированные в ovevent.

У сетевых устройств могут иметься один или несколько сконфигурированных адресатов назначения прерывания. Пункты назначения прерываний обычно являются IP-адресами управляющих станций сети. Эти IP-адреса могут конфигурироваться вручную или автоматически путем использования программного обеспечения менеджера элементов устройства, работающего в системе NNM. Наличие нескольких пунктов назначения прерывания желательно, когда устройством управляют две или более накопительные станции, поскольку это повышает шансы реального получения прерывания одной из них. Поскольку прерывания SNMP передаются посредством пакетов UDP, они могут теряться. В отличие от TCP, в UDP не предусмотрено средство выявления или повторной передачи потерянных пакетов. Для SNMP-прерываний используется UDP, потому что этот протокол является облегченным, требующим небольшого числа ресурсов на стороне агента.

Заметим, что нераскрытое устройство может, тем не менее, конфигурироваться таким образом, чтобы посылать SNMP-прерывания в систему NNM. В случае приема такого прерывания было бы невозможно увидеть на схеме устройство, которое послало прерывание. Для должной расшифровки прерывания в системе NNM должна составляться MIB для этого устройства. К сожалению, иногда бывает трудно получить копию текущей MIB для устройства. Полезно знать, что MIB описывает SNMP-прерывания.

Чтобы получить самую последнюю версию файла MIB, можно попробовать поискать его на инсталляционном CD NNM, обратиться к компании-поставщику, в которой был произведен файл MIB, или поискать в web (). Следует убедиться, что определение MIB, загруженное в базу данных MIB системы NNM, соответствует версии MIB, которая используется на самом устройстве. Для удобства пользователей инсталляционный CD NNM содержит сотни определенных поставщиками MIB. Нужно просто загрузить те MIB, которые подходят для конкретной сетевой конфигурации.

Иногда события бывают настолько интересными, что администратор NNM будет конфигурировать автоматическую реакцию посредством GUI конфигурирования событий. Например, если бы вышел из строя критический интерфейс маршрутизатора, соответствующая автоматическая реакция могла бы заключаться в посылке короткого сообщения по e-mail на пейджер дежурного менеджера сети.

По причине важности SNMP-прерываний, в таблице 8.1 приводится короткая сводка их основных категорий. В промышленном стандарте SNMP прерывания общего характера нумеруются в диапазоне 0-6, а номера специальных прерываний связываются с общим прерыванием номер 6.

Потоки syslog от устройств и ovevent

Сетевое оборудование часто конфигурируется таким образом, чтобы консольные сообщения передавались по сети на некоторый узел и журнализировались с использованием его службы syslog. Во всех UNIX системах имеется демон с именем syslogd, который слушает UDP-порт 514 и журнализирует полученные сообщения в файле, имя которого указывается в файле /etc/syslog.conf. (см. пример на рис. 8.1).

Реальный текст, который журнализирует syslogd, является специфическим для устройства и может даже зависеть от редакции встроенной программы, типа модели и типа адаптера интерфейса. Степень серьезности сообщения определяется его текстом.

Как можно следить за этим файлом? Данные в файлах syslog не отслеживаются непосредственно NNM, и информация в нем может быть не видна, если смотреть "глазами" SNMP.

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

Альтернативное и, возможно, предпочтительное решение состоит в том, чтобы для отслеживания файла syslog маршрутизаторов запустить небольшой UNIX-скрипт в фоновом режиме. Скрипт может выполнять следующие шаги:

В среде UNIX демон syslogd журнализирует входящие UDP-сообщения в одном из перечисленных регистрационных файлов. Например, маршрутизаторы можно сконфигурировать для отсылки их консольных сообщений в систему NNM. Они будут журнализироваться в отдельном файле /var/log/routerlog.

Предопределенные и специальные категории сигналов

Имеются следующие предопределенные категории сигналов и связанные с ними числовые коды:

0 = Ignore;

1 = Log only;

2 = Error Alarms;

3 = Threshold Alarms;

4 = Status Alarms;

5 = Configuration Alarms;

6 = Application Alert Alarms.

Эти и специально определенные категории отображаются в GUI xnmevents, как показано на рис. 8.2.

Это небольшое окно всплывает по умолчанию при начале сессии ovw. Цвет каждой кнопки показывает наивысший уровень серьезности сигналов. Нажатие кнопки приводит к вызову браузера сигналов, который позволяет отобразить подробную информацию о сигналах данной категории. На этом снимке экрана показаны стандартные категории.

События, соответствующие консольным журнальным сообщениям маршрутизатора, как правило, посылаются в специальную категорию событий (не показанную выше). Эти события можно просматривать в браузере событий и оперировать ими как обычно.

Настройка действий в ответ на события

В каждой IT-организации устанавливаются свои стандарты серьезности событий и способов реагирования. Используя GUI, в NNM можно изменять категории событий, уровни их серьезности и запрограммированные действия. На рис. 8.3 изображен основной браузер конфигурирования событий. Представляет интерес корпоративная MIB OpenView, поскольку в ней перечисляются все собственные события NNM. Многие установленные по умолчанию коды серьезности и журнализации могут отличаться от локальных настроек.

Если дважды щелкнуть по событию, которое требуется настроить, то появится GUI (см. рис. 8.4), позволяющий изменять большинство параметров, включая:

Чтобы найти событие NNM, нужно прокрутить имена предприятий и выделить в списке OpenView. В нижней части прокручиваемой области отображаются все события NNM. Обратите внимание на показанные в среднем столбце номера прерываний, специфичных для предприятия. Чтобы вызвать GUI настройки, нужно дважды щелкнуть по имени события.

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

Возможные автоматические действия весьма разнообразны. Мощь, происходящая от гибкости, подпитывается изобретательностью администратора 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 позволяет сконфигурировать следующие критерии для ограничения числа отображаемых событий:

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