Использование устройств NetPing с системой мониторинга NOC

1. Введение

Сегодня провайдеры, датацентры и компании со средней и крупной ИТ-инфраструктурой остро нуждаются в программном обеспечении для мониторинга, управления, инвентаризации их ИТ-объектов. Центр Управления Сетью (NOC) успешно справляется со всеми этими задачами.

Также необходимо отслеживать физические параметры среды, контролировать физический доступ и проблемы с питанием в местах работы ИТ-объектов. В этом может помочь серия оборудования для мониторинга ООО «Алентис Электроникс».

Пример совместной работы: мониторинг датчиков с помощью устройств NetPing, *UniPing* и обработка, вывод структурированных результатов в унифицированном web-интерфейсе программы NOC рассмотрим в следующем разделе.

2. Краткий обзор системы мониторинга и управления ошибками NOC

 Просмотреть структурированный список всех ошибок в сети можно в Fault Managment → Alarms, отсортировав вывод по Severity:

Возможности фильтрации ошибок: по объектам, классам, временным интервалам.

Схему сети со связями между объектами получим, перейдя в Inventory → Network Maps. В случае недоступности объекта значок объекта изменит цвет на красный: 

Кроме просмотра структурной схемы сети, объекты также можно привязать к геоинформационной системе и отображать на разных картах: OpenstreetMap, Google Maps, … При этом возможно учитывать уровни

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

Объекты можно выбирать по их географическому расположению, открыв Inventory → Inventory:

Изображение стойки получим, выделив её название «Rack 1». В стойках уже видно расположение самих объектов:

Если два раза кликнуть на объекте в стойке, перейти на вкладку Managed Objects и нажать кнопку Alarms, то появится список ошибок по конкретному объекту:

3. Необходимые требования

Если вы заинтересовались данной связкой программы NOC и оборудованием NetPing, рассмотрим минимальные требования:

Необходимые системные требования для установки NOC. Установка NOC на Debian 7.0, Ubuntu 12.04 LTS, FreeBSD 9.2, установка на любой *NIX, VirtualBOX, Gentoo [оверлей | https://bugs.gentoo.org/show_bug.cgi?id=366051]. NOC есть свободным программным обеспечением и распространяется под BSD [лицензией | http://kb.nocproject.org/display/DOC/License].

Если вы планируете писать свои правила, о чём речь пойдёт дальше, вам также необходимы некоторые минимальные знания:

• понимание структуры типа словарь (json);

• умение писать регулярные выражения [ на языке Python | https://docs.python.org/2/library/re.html].

4. Регистрация объекта в системе NOC

Сначала надо завести сам объект в базу NOC. Для этого заходим в Service Activation → Managed Objects и нажимаем кнопку +Add.

В открывшееся окно (рис.ниже) необходимо прописать:

 После ввода всех учётных данных объекта нажимаем кнопку Save.

5. Система управления ошибками (NOC FM)

Система управления ошибками (Fault Management FM) в NOC может сохранять все сетевые события, классифицировать их, выводить приоритезированные сообщения об ошибках и выполнять определённые действия при каком-либо событии. Настройка [ | http://kb.nocproject.org/display/SITE/FM+quick+setup] NOC для работы [ FM | http://kb.nocproject.org/display/SITE/FM+quick+setup].

Мы затронем только часть FM — как создать новое правило классификатора для распознания SNMP или SYSLOG сообщения от сетевого устройства. Чтобы просматривать сетевые события в NOC, откроем вкладку Fault Managment → Events, изображённую на рисунке ниже.

5.1 Пример с SNMP Trap

 Видим неклассифицированное событие, в поле «Class» которого стоит «Unknown | SNMP Trap». Войдем в него двойным кликом. Получим картинку изображённую на рисунке ниже:

Теперь перейдем на вкладку Data, показанную на следующем рисунке.

Обращаем внимание: передаваемые в SNMP Trap переменные можно извлечь из сообщения и использовать для его классификации. Они находятся в разделах Resolved Variables и Raw Variables. Теперь нажимаем Create Rule и получим форму для создания правила:

Сначала надо выбрать класс события NOC. Список всех классов также можно просмотреть в /opt/noc/fm/collections/eventclasses/.

Нас интересует влажность, она находится в каталоге Environment:

Теперь приступим к написанию регулярных выражений для классификации события.

Обязательная переменная  name: Humidity указывает на название сенсора. Мы её не извлекаем, а добавляем внизу. Остальные переменные measure, min, max извлекаем из данных SNMP Trap. Не забываем при этом заменить переменные цифровые значения на \d+

Список переменных для события можно найти в файле: /opt/noc/fm/collections/eventclasses/Environment/Humidity_Returned_to_Normal_Range.json

После написание правила нажимаем кнопку Test и переходим к окну:

В его поле ввода надо ввести идентификационный номер события. Он находится в первой колонке вкладки Fault Managment → Events и выделен в следующем примере:

При нажатии кнопки Test появится результат. Успешный результат теста приведён ниже.

Нажимаем кнопку Close и возвращаемся к нашему правилу.  Для сохранения правила необходимо нажать кнопку Save.

Открылась вкладка Fault Managment → Clasification Rules: здесь есть список всех правил класификации для всех устройств. Для фильтрации списка набираем производителя Alentis и видим наше правило. На нём не стоит метка Build in.

Двойным кликом открываем правило для редактирования. В открывшемся окне нажимаем кнопку JSON.

Копируем содержимое окна в файл Humidity_Returned_to_Normal_Range_1_SNMP_.json

Этот файл можно отослать на http://bt.nocproject.org/secure/Dashboard.jspa — таким образом база NOC будет поддерживать больше оборудования разных производителей.
Для подгрузки нового правила необходимо перезапустить NOC сервис. После перезагрузки входим в наше правило двойным кликом. И нажимаем кнопку Reclasify.

Возвращаемся назад, нажав кнопку Close. Видим, что наше сообщение теперь распозналось.

5.2 Пример с сообщением Syslog

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

Итак, открываем такое же правило Sysylog, сообщение о нормализации влажности. Выбираем класс события Environment | Humidity Returned to Normal Range.

Меняем имя так, чтобы оно было уникально, добавив номер.

Смотрим, какие переменные надо извлечь в файле: /opt/noc/fm/collections/eventclasses/Environment/Humidity_Returned_to_Normal_Range.json

Нажимаем кнопку +Add, добавляем имя name и его значение Humidity:

Теперь создаём само регулярное выражение, по которому будет классифицироваться событие. Особое внимание необходимо обратить на экранирование спец символов «(», «)» и «.» с помощью «\». Также мы в этом случае оставим пробелы, которые обычно стоит заменять на «\s+» или «\s*». Дело в том, что конкретно в этом случае сообщения о выходе влажности за пределы нормы и возвращение влажности в пределы нормы различаются всего одним пробелом!

Нажимаем кнопку Test для проверки нашего регулярного выражения:

Копируем уникальный идентификационный номер нашего сообщения, как в примере с SNMP. Нажимаем кнопку Test для вывода результата проверки: Пример успешного тестирования:

Для закрытия нажимаем Close. Чтобы сохранить наше новое правило, нажимаем Save.

Открылась вкладка Fault Managment → Clasification Rules: здесь есть список всех правил классификации для всех устройств. Вводим производителя Alentis для фильтрации списка и видим наше правило. На нём не стоит метка Build in.

Двойным кликом открываем правило для редактирования.  В открывшемся окне нажимаем кнопку JSON.

Копируем содержимое окна в файл Humidity_Returned_to_Normal_Range_1_SYSLOG_.json Потом закрываем, нажав Close.

Подробное описание переменных и дополнительных функций для правил класификации событий. Этот файл желательно отослать на http://bt.nocproject.org/secure/Dashboard.jspa, так база NOC будет обогащаться поддержкой оборудования разных производителей. Для вступления правила в силу необходимо перезапустить NOC. 

6. Итоги

 Результат правильной классификации события:

• будет создаваться или закрываться соответствующее уведомление об ошибке в Fault Managment → Alarms;
• будут выполнятся соответствующие действия при наличии триггера, например, выполнение скриптов;
• будет отсылаться уведомление при настройке системы уведомлений с помощью почты или SMS;
• на карте объект с ошибками будет изменять цвет на красный Inventory → Network Map;
• весь перечень ошибок по конкретному объекту можно просмотреть в свойствах объекта Service Activation → Managed Objects, нажав кнопку Alarms.

В данной статье не рассмотрен случай, когда нужного Event Class не нашлось (в /opt/noc/fm/collections/eventclasses/ он пока ещё не создан). Возможно для нового Event Class понадобится также создавать новый Alarm Class (в /opt/noc/fm/collections/alarmclasses/). Это можно сделать в Fault Managment → Event Classes и Fault Managment → Alarm Classes соответственно.

• Все устройства