Child pages
  • Fault Managment - система управления событиями и ошибками в NOC (Microservices).
Skip to end of metadata
Go to start of metadata


1. Введение.

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

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

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


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

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

Необходимые системные требования для установки NOC. Перед установкой крайне рекомендуется ознакомится со следующими материалами:

Обзор Tower,

Установка NOC на любой *nix дистрибутивDebian 8.5, FreeBSD 11 или миграция с предыдущей ветки (default/develop).

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


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

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


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


 

(На момент написания статьи аварий на сети не было, пришлось отправить в перезагрузку CPE устройство за облаком провайдера. В данный момент такие линки привязать через UI нет возможности).

Кроме просмотра структурной схемы сети, объекты также можно привязать к геоинформационной системе и отображать на разных картах: OpenstreetMap, Google Maps, … При этом учитывать уровни детализации карты, например:
глобальный - отображает сеть на уровне городов
агрегированный - отображает объекты на уровне районов города
уровень доступа - отображает объекты по зданиям
в здании - объекты размещаются в комнатах, офисах, подъездах в зависимости от их назначения
в помещениях уже находятся стойки, коммуникационные ящики
и на конец в стойках находятся сами объекты ИТ инфраструктуры
Объекты можно выбирать по их географическому расположению открыв Inventory →Inventory:


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


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


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

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

Name:

Имя объекта в NOC.

SA Profile:

Внутренний профиль объекта в NOC. Если подходящего нет, выбираем Generic.Host.

Scheme:

Тип управления устройством. Может быть telnet, ssh, HTTP.

Address:

IP адрес объекта.

Port:

Порт, на котором слушает управляющий сервис.

User:

Имя пользователя.

Password:

Его пароль.

Trap Source IP:

IP адрес объекта, с которого будут приходить SNMP сообщения.

Trap Community:

Пароль для SNMP сообщений.

RO Community:

Пароль для SNMP подключения.


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


 

Более подробное описание добавления нового объекта в NOC.

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


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

5.1 Пример с SNMP Trap.


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

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

Теперь нажимаем Create Rule и получим форму для создания правила:

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

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

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

Для сохранения правила необходимо нажать кнопку 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. Выполнение определённых действий при наступлении некого события.

6.1 Старый механизм pyrule.

Не будем здесь его описывать просто приведём ссылки:

Pyrule для FM который пригодится каждому.

Alarm Trigers HowTo

Pyrule для Inventory, который пригодится для FM каждого

Некоторые алгоритмы для поиска причины аварии.

 

6.2 Новый механизм handlers.

В описании класса события Event Classes (noc / fm / collections / eventclasses /), например, noc / fm / collections / eventclasses / Network / Link / Link_Down.json есть ключ handlers:

Link_Down.json ключ handlers
"handlers": [
        "noc.fm.handlers.event.link.oper_down"
    ],

он указывает на скрипт который выполнится при приёме сообщения этого класса.

Сами скрипты расположены в noc / fm / handlers / event /, например, noc / fm / handlers / event / link.py  функция oper_down:

link.py функция oper_down
def oper_down(event):
    """
    Set oper status to down
    """
    i_name = event.vars["interface"]
    InterfaceStatus.set_status(
        event.managed_object, i_name, oper_status=False)

7. Интеграция NOC с другими системами с помощью интерфейса REST.

В этом разделе рассмотрим пример как интегрировать NOC Fault Managment в другие, например биллинговые системы или системы helpdesk. При приёме звонка от клиента, оператору желательно видеть в карточке клиента, список ошибок конкретно на порту клиента и общие касающиеся оборудования клиента.

Сначала необходимо добавить в NOC пользователя 'noc_user' с паролем 'noc_password' и наделить его необходимыми и достаточными правами. Эти учётные данные, а также IP сервера необходимо прописать в скрипте ниже. В виду хранящихся в скрипте учётных данных необходимо запретить доступ к этому скрипту всем кроме исполняющего его пользователя.

Приведём пример скрипта использующего внешний интерфейс NOC REST для получения ошибок на порту объекта:

helpdesk_mo_port_alarms.py
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
##----------------------------------------------------------------------
## Copyright (C) 2007-2014 The NOC Project
## See LICENSE for details
##----------------------------------------------------------------------

# Пример запуска:
# python billing_ip_port_alarm.py IP port

# Python modules
import sys
# Additional Python modules
import requests

### Учётные данные для входа в NOC:
NOC_IP='192.168.17.1'
noc_user='noc_user'
noc_password='noc_pasword'

def proc_rest(obj_alarms,port):
    """
    Proc data from REST
    :Resive: List of alarms
    :returns: connection and cursor
    :rtype: List

    Пример события с REST:
    {
        'status': 'A',
        'severity__label': 'WARNING',
        'severity': 2000,
        'timestamp': '2014-03-30T20:22:32+06:00',
        'managed_object': 6,
        'events': 1,
        'row_class': 'noc-color-2',
        'fav_status': False,
        'managed_object__label': 'sw-17-17.12.example.com',
        'alarm_class': '53318cfd06e3d36fea523aaa',
        'duration': 57455,
        'alarm_class__label': 'Network | Storm Control | Broadcast Storm Detected',
        'id': '533828a906e3d37b8783401f',
        'subject': 'Broadcast Storm detected on port 2'
        'vars' : {
            'interface' : '2',
            'ip' : '192.168.17.17'
            }
    }
    """

    result = []
    for alarm in obj_alarms:
        event = alarm["alarm_class__label"]
        try:
            if alarm["vars"]["interface"]==port:
                t = 0
                for e in events:
                    if e in event:
                        result.append(events[e])
                        t = 1
                if t == 0:
                    result.append(event)
        except:
            t = 0
            for e in events:
                if e in event:
                    result.append(events[e])
                    t = 1
            if t == 0:
                result.append(event)
    return (result)

### Перевод ошибок к понимаемому техническим персоналом виду:
events = {
    "NOC | Managed Object | Ping Failed": 'Абоненский коммутатор не доступен.',
    "Network | STP | BPDU Guard Violation": 'Отключить STP на клиентском устройстве.',
    "Network | DHCP | Untrusted Server": 'Выключить DHCP сервер на клиентском устройстве.',
    "Network | LBD | Loop Detected": 'Абоненский порт отключён по причине кольцевой топологии сети. Или сгорел абоненский порт.',
    "Network | Storm Control | Storm Detected": 'Абоненский порт отключён по причине шторма.',
    "Network | Storm Control | Multicast Storm Detected": 'Абоненский порт отключён по причине Multicast шторма.',
    "Network | Storm Control | Unicast Storm Detected": 'Абоненский порт отключён по причине Unicast (DLF) шторма.',
    "Network | Storm Control | Broadcast Storm Detected": 'Абоненский порт отключён по причине широковещательного шторма.',
    }

### IP получить как параметр , вместе с портом!
IP = sys.argv[1]
port = sys.argv[2]

### Получение id объекта по IP
url='https://' + NOC_IP + '/sa/managedobject/?address=' + IP + '&__only=id'
urlopen = requests.get(url, auth=(noc_user, noc_password), verify=False)
obj = urlopen.json()
#obj_id = obj["id"]
obj_id = obj[0]["id"]

### Получение списка ошибок.
#url='https://' + NOC_IP + '/fm/alarm/?managed_object=' + str(obj_id) + '&status=A'
url='https://' + NOC_IP + '/fm/alarm/?managed_object=' + str(obj_id)
urlopen = requests.get(url, auth=(noc_user, noc_password), verify=False)
obj_alarms = urlopen.json()
result = proc_rest(obj_alarms,port)

### Вывод результатов.
for i in result:
    print (i)

quit()

Выполнив выше приведённый скрипт с параметрами IP адреса клиентского оборудования и порта клиента получим текущий список ошибок на клиентском порту и общий касающийся его оборудования в удобной для понимания техническим персоналом форме.

8. Итоги.

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

  • будет создаваться или закрываться соответствующее уведомление об ошибке в Fault Managment → Alarms;

  • будут выполнятся соответствующие действия при наличии триггера, например выполнение скриптов;

  • будет отсылаться уведомление при настройке системы уведомлений, почта, SMS;

  • на карте объект с ошибками будет изменять цвет Inventory → Network Map;

  • весь перечень ошибок по конкретному объекту можно просмотреть в свойствах объекта Service Activation → Managed Objects нажав кнопку Alarms.

  • возможна простая интеграция NOC с другими системами посредством интерфейса REST.

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


9. Смотрите также:

Видео по созданию правил класификации Creating FM Rules. 

Модуль управления инцидентами и авариями.

Fault Managment и поддержка GNU/Linux.