Валидация конфигурации оборудования может оказаться крайне полезной. Помогает избежать опечаток, простых ошибок и сохранить единство принципов конфигураций на сети, в случае, если настройка производится разными людьми. Принципы работы следующие:
Теперь, после того как в НОКе обновится конфигурация оборудования, произойдёт автоматическая проверка правил и в случае срабатывания создастся Предупреждение.
Исходя из описания, для работы валидации необходимо:
Посмотреть собранные факты можно нажав на кнопку Facts на странице MO.
В открывшемся окне можно посмотреть собранные факты. Кнопка Revalidate позволяет запустить поцесс сбора фактов вручную.
Если окно facts пустое, это означает что парсер для данного профиля не написан. |
После того как мы просмотрели необходимые факты - приступаем к написанию проверок. Это делается из пункта меню "Configuration Management" -> "Setup" -> "Validation Rules".
В нём представлены написанные правила, цифра в кружочке означает количество совпадений. Добавить новое правило можно кнопкой "Add" в верхней строке.
Структура окна добавления/редактирования правила следующая:
Правило не начнёт работать, пока не будет добавлено в политику (Validation Policy), прикреплённую к конкретному устройству. |
Основной функционал правил реализуется в Handlers (обработчиках). Условно, их можно поделить на 2 вида:
Python-based находятся по пути "<noc_folder>/cm/validators": папки config, interface, object, service. Они представляют собой модули, написанные на Python'e которым передаются объекты, внутри себя они их проверяют и создают ошибку. Если позволяет знание Python'a можно реализовать свои модули-валидаторы.
CLIPS-based проверки основаны на специальном языке экспертной оценке CLIPS. Их можно реализовать как во внешних модулях (аналогично Python-based), так и вставкой прямо в правило (для этого есть специальные Handlers: "Object CLIPS Rules", "Interface CLIPS Rules").
Описание языка CLIPS можно посмотреть: Википедия |
С НОКом поставляется набор встроенных правил, которые можно использовать для стандартных задач. Если требуются специализированные проверки - то необходимо осваивать CLIPS. В папке "<noc_folder>/cm/validators" можно посмотреть код встроенных валидаторов.
Приведём пример валидатора, которые проверяет - назначен ли созданному подинтерфейсу VLAN. Для случая Cisco.IOS настройка выглядит так: interface FastEthernet0/1.200 encapsulation dot1q 200 В случае если в конфиге будет отсутствовать команда "encapsulation dot1q 200" должна выдаваться ошибка. Перефразируя вопрос - в фактах интерфейсов присутствует поля:
Необходимо написать правило, которое в случае отсутствия в случае пустого поля vlan_ids и наличия BRIDGED в afi выдавало ошибку. На левой картинке показаны факты с правильно настроенного интерфейса, а на правой - настроенного с ошибкой. Для данного случае стандартные правила нам не подходят. Напишем своё:
Данное правило написано на CLIPS и выполнит задачу. Сделаем некоторые пояснения.
|
При написании собственных правил возникает вопрос создания собственных типов ошибок. Как вариант, дополнения существующих новой информацией. Типы ошибок доступны в меню "Configuration Management"->Setup->"Error Types".
Для измения доступны поля "Subject Body" и "Body Template". Они применяются при создании аварии, в случае провала проверки.
Встроенные обработчики снабжены хорошими комментариями. Поэтому приведём примеры наиболее востребованных:
Имя | Описание | Опции | Пример |
---|---|---|---|
Config *MUST* match string | В конфигурации должна присутствовать строка. | строка, которую необходимо искать в конфигурации | |
Hostname *MUST* match regexp | Проверяет hostname на соответствие регулярному выражению | регулярное выражение в формате Python | |
Interface CLIPS Rules | Позволяет задавать свои CLIPS-based правила, применяются к блоку интерфейсов | правило в формате CLIPS | |
Object CLIPS Rules | Позволяет задавать свои CLIPS-based правила, прменяются ко всем блокам | правило в формате CLIPS |
После того как написаны правила - необходимо объединить их в политики и привязать к оборудованию (MO). Политики настраиваются в меню "Configuration Management" -> "Setup" -> "Validation Policy".
После нажатия кнопки Add, откроется окно добавления политики. В нём необходимо задать имя и список правил, по которым будет проходить проверка. Порядок правил не влияет.
После того как политика валидации (Validation Policy) создана, необходимо привязать её к устройству. Делается это через меню "Service Activation" -> "Management Object" -> Validation. В нём необходимо добавить настроенную политику. Для её применения необходимо или дождаться обновления конфига или воспользоваться кнопкой Revalidate на экране Facts.
.
Для немедленного применения политики необходимо воспользоваться кнопкой Revalidate на экране Facts |
Результаты применения политики отобразятся на том же экране Facts. Появится список ошибок. Также на экране правил (Rule) увеличится число в счётчике ошибок рядом с правилом и создастся Alarm.
После создания политики и её назначения на устройство НЕ происходит автоматической проверки конфигурации. Проверка пройдёт только после поступления в базу ИЗМЕНЕНИЙ в конфигурации (парсер фактов работает с базой конфигов НОКа).
Данное поведение связано с 2 моментами:
Если очень хочется:
./noc shell from noc.cm.engine import Engine from noc.sa.models.managedobject import ManagedObject for mo in ManagedObject.objects.filter(is_managed=True): e = Engine(mo) e.check() |