Требования
Валидация конфигурации оборудования может оказаться крайне полезной. Помогает избежать опечаток, простых ошибок и сохранить единство принципов конфигураций на сети, в случае, если настройка производится разными людьми. Принципы работы следующие:
- Нок получает конфигурацию с оборудования.
- Специально написанный парсер проходит по конфигурации (это происходит по последней актуальной конфигации из базы НОКа).
- Результатом работы парсера становится набор фактов вида: версия ssh 2, на интерфейсу присвоен такой-то адрес и т.д.
- Далее мы добавляем правила, которым должен соответствовать факт или набор фактов.
- Объединяем правила в политику.
- Привязываем политику к оборудованию.
Теперь, после того как в НОКе обновится конфигурация оборудования, произойдёт автоматическая проверка правил и в случае срабатывания создастся Предупреждение.
Исходя из описания, для работы валидации необходимо:
- Написанный парсер, превращающий конфигурацию оборудования в набор фактов.
- Правила, на основе фактов, контролирующие правильность конфигурации.
- Политики привязки правил к оборудованию.
Смотрим факты
Посмотреть собранные факты можно нажав на кнопку Facts на странице MO.
В открывшемся окне можно посмотреть собранные факты. Кнопка Revalidate позволяет запустить поцесс сбора фактов вручную.
Если окно facts пустое, это означает что парсер для данного профиля не написан.
Пишем правила
После того как мы просмотрели необходимые факты - приступаем к написанию проверок. Это делается из пункта меню "Configuration Management" -> "Setup" -> "Validation Rules".
В нём представлены написанные правила, цифра в кружочке означает количество совпадений. Добавить новое правило можно кнопкой "Add" в верхней строке.
Структура окна добавления/редактирования правила следующая:
- Поле Name (Имя) - имя, просто имя.
- Выпадающий список Handlers (обработчик) - отвечает за проверку, которую будет производить правило
- Списки Selectors и Objects служат для фильтрации устройств (MO) на которые подействует правило. Доступны 3 действия:
- Ignore - игнорировать значение в данной строчке (т.е. не проводить проверку на влючение/исключение)
- Include - при совпадении включить в список на применение правила
- Exclude - при совпадении исключить из списка на применение правила
Правило не начнёт работать, пока не будет добавлено в политику (Validation Policy), прикреплённую к конкретному устройству.
Проверки (Handlers)
Основной функционал правил реализуется в Handlers (обработчиках). Условно, их можно поделить на 2 вида:
- Python-based
- CLIPS-based
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" можно посмотреть код встроенных валидаторов.
Ошибки.
При написании собственных правил возникает вопрос создания собственных типов ошибок. Как вариант, дополнения существующих новой информацией. Типы ошибок доступны в меню "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 моментами:
- Действует принцип "Закон обратной силы не имеет". Т.е. считается, что, изначально, все конфиги соответствуют политике.
- Мало приятного получить 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()
Возможные проблемы
- Окошко Facts пустое
- Для данного профиля не написан парсер. Проверить можно посмотрев содержимое папки "cm/parsers/".
- Парсер написан, но не работает. Ошибки необходимо искать в логах web.
- Правило написано, но не обнаруживает ошибку
- Необходимо проверить что правило включено в политику, а политика привязана к устройству.
- Необходимо нажать кнопку Revalidate в окошке Facts.
- Проверить логи web на наличие ошибок (в нём отображается какие правила были применены и результат)
1 Comment
Unknown User (e_zombie)
ага, парсер надо в __init__.py профиля указать
default_parser = "noc.cm.parsers.Cisco.IOS.base.BaseIOSParser"
./noc discovery --debug run --check=config box МО