NOC Project настройка

NOC Project настройка - вторая часть материала по NOC Project, здесь будут рассмотрены основные моменты связанные
с настройкой.

Возможны повторения и перехлёсты с 1 частью - это нормально. Готовые тестовые VMs башни и ноды под Hyper-V Windows 10 можно забрать здесь

Собственно уже не в теме, так как с середины декабря 17 NOC'ом в продакшене не занимаюсь. Чтобы быть в теме нужно постоянно тратить значительное количество сил и времени, долго так продолжаться не может. Тем не менее остался некоторый материал и наработки, нужно выложить.

Отслеживание изменений

Чтобы оперативно получать информацию об изменениях, нужно подписаться на Telegram-канал NOC Project News https://t.me/nocproject_news

Начальная настройка

Установка NOC выполнена, но что же со всем этим делать? На первый взгляд абсолютно непонятно, ok — начинаем разбираться.

Минимальное описание есть на странице проекта и хотя с последней версией есть отличия, но ознакомиться полезно.

Вводим в браузере адрес ноды, важно обратить внимание, что в отличие от башни адрес ноды - это HTTPS.

Вводим логин admin, пароль admin и открывается вот такая страничка:

NOC Project настройка

  1. Материалы по NOC Project, с которыми необходимо ознакомиться;
  2. Посмотреть версию системы, настроить свой профиль (язык и e-mail), поменять пароль, выйти из системы;
  3. Основное меню системы, здесь будут интересовать пункты Main, Inventory, Service Activation (далее - SA).

NOC Project настройка

В последних версиях NOC также появилось подсказки при наведении на поле для заполнения. Не везде, но там где они есть — полезно читать.

Браузер

Поскольку большая часть работы ведется через веб ноды, то при различных проблемах отображения и странном поведении веба - в первую очередь обновлять страницу, во вторую чистить кеш браузера.

Users

Пользователи добавляются в Main - Setup - Users.

По умолчанию есть 1 пользователь — admin, как видно на рисунке у него есть статус Superuser:

NOC Project настройка

Можно добавить ещё пользователей со статусом Superuser, но admin - самый "прямой" суперюзер, так, например, Data Sources для Grafana можно добавить/поменять только из под админа. Конечно можно настроить права в Grafana, но изначально это может сделать только admin.

Чтобы пользователь мог работать ему обязателен статус Superuser, иначе при входе в систему — пустое меню. Чтобы этого не происходило нужно создавать и настраивать группы Main - Setup - Groups. Тут много минусов:

  • Для групп нет готовых пресетов на права, то есть права для каждой группы надо прощёлкивать руками, а разделов и чекбоксов в каждом разделе там ой как много;
  • Что-то интуитивно понятно, что-то вызывает вопросы - а какие чекбоксы нужно отмечать в данном разделе? И нужно ли это делать для этого раздела вообще. Определяется методом проб;
  • Чтобы права подтянулись к пользователю иногда нужны сильные танцы с браузером - чистить кеш, обновлять страницу раз по 10 и так далее. Хотя при написании статьи ещё раз пробовал - права для тестового юзера появились сразу.

Есть нюансы:

  • Чтобы для пользователя стали видны сами устройства, нужно добавить запись в SA - Setup - User Access.

NOC Project настройка

  • Таже есть групповой доступ  SA -Setup - Group Access сразу для группы. Работает аналогично.

Логика следующая:

  • Cначала заводится группа, название группа не очень правильное, поскольку это набор прав;
  • Потом эта группа присваивается внутри записи для пользователя;
  • Затем в SA -Setup - Group Acces группа связывается с Административными доменами (о доменах чуть дальше): 1 запись, 1 домен. Права пользователя определяются набором таких записей;
  • Если какой-то из пользователей группы прямее, чем остальные, то ему заводятся дополнительные записи для доступа к другим домена в SA - Setup - User Access.

По крайней мере, понял логику работы прав именно так. Пользователи/группы - пока субъективно слабое место системы.

Telegram

В связи с блокировками не знаю насколько сейчас этот абзац актуален, но оставляю на всякий пожарный.

На мой взгляд сообщения из NOC удобнее всего получать в Telegram-канал, специально созданый для этой цели. Мобильник всегда под рукой — удобно. Порядок настройки следующий:

  • Необходимо создать публичный канал Telegram;
  • Добавить себе бота @BotFather;
  • Ввести ему команду /newbot – создание нового бота. BotFather попросит придумать новое уникальное имя (MY_NOCbot) для этого бота. Оно обязательно должно заканчиваться на bot;
Done! Congratulations on your new bot. You will find it at t.me/MY_NOCbot.
  • Затем BotFather присылает уникальный токен API, который нужно сохранить (ID бота - это цифровая часть его API);
Use this token to access the HTTP API:
386356356:AAECpgGGG-NNNNNNW1VR-R
  • В сервисах башни добавляем сервис tgsender для Telegram в количестве 1 и записываем в его настройках в поле Token API бота;
  • Выполняем деплой чтобы сервис заработал на ноде;
  • В наш канал добавляем администратором нашего бота через по поиск по имени бота @MY_NOCbot;
  • Получение ID канала — пишем тестовое сообщение нашему боту в адресной строке браузера, в открывшейся странице находим chat id - это идентификатор канала:

https://api.telegram.org/bot<API бота>/sendMessage?chat_id=@<имя канала>&text=Hello!
(подставить свои значения и вставить в браузер)

https://api.telegram.org/bot386356356:AAECpgGGG-NNNNNNW1VR-R/sendMessage?chat_id=@MYChannel_NOC&text=Hello!

{"ok":true,"result":{"message_id":5,"chat":{"id":-10010666633333,"title":"MYChannel_NOC","username":"MYChannel_NOC","type":"channel"},"date":1506504800,"text":"Hello!"}}

Вот эта часть строки "id":-10010666633333 и нужна.

  • Переводим наш канал в приватный;
  • Приглашаем туда нужных сотрудников, выдаём им права;

И ещё 3 настройки на ноде:

  • Main - Setup - Notification Groups - создаём группу оповещения.  В Other добавляем новую строку с Method - Telegram и Params - ID канала (вводится как есть, то есть с минусом);
  • Заходим SA - Setup - Managed Object Selector - создаём селектор: для какого оборудования отправлять сообщения. Тут очень много фильтров и оборудование можно отобрать очень точно. Понадобится несколько фильтров для отбора нескольких групп оборудования;
  • Потом SA - Setup - Object Notification - создаём новую нотификацию: что именно отправлять для данного оборудования, какие события. Так, допустим, для ключевого оборудования важно видеть возникновение алармов и их закрытие, но получение алармов для всего оборудования или большой группы - перегрузит канал. Для одного оборудования важно оперативно видеть изменения в конфиге, для другого - изменение интерфейса и так далее.
Сегментация

Можно и нужно сразу создать административные домены и сегменты сети:

  • SA - Setup - Administative Domains - "сеть такая-то";
  • Inventory - Setup - Network Segments - "LAN99".

Как уже говорил, если нужно предоставить пользователю NOC доступ к группе устройств, то такой группой как раз является Административный домен. Лучше заранее подумать как разбить сеть на домены, чтобы потом не переделывать.

Карты сети в Inventory - Network Map выводятся отдельно для каждого сегмента. Что будет крупнее сегменты или домены определяется спецификой администрирования в каждом конкретном случае.

Кроме того данные логические разбиения нужны для удобства при выводе и сортировке сетевых устройств (например, в SA - Managed Objects - далее MO).

Есть ещё автосегментация - настраивается SA - Setup -  Managed Object Profiles в свойствах конкретного профиля на закладке Autosegmentation (действие по умолчанию - не применять автосегментацию):

NOC Project настройка

Не использую и всегда выставляю сегмент руками при создании записи оборудования.


Service activation

Это основной раздел NOC, здесь:

  1. Централизовано можно просмотреть конфиги устройств в Get Now;
  2. Непосредственно заводятся и просматриваются записи для сетевых устройств в MO;
  3. Запускается групповое выполнение команд на группе однотипных устройств в Run Commands;
  4. Полезные отчеты в Reports;
  5. Много важных настроек в Setup.
SA - Get Now

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

NOC Project настройка

Можно запустить конфиг на сбор - Get config Now:

NOC Project настройка

Когда собрано несколько конфигов для устройства, то можно их сравнить (выбрать первый конфиг в окошке Version, а второй в окошке Compare): строки добавленные в конфиг будут отображаться с +, убранные с -, одинаковое при сравнении не выводится, за исключением части конфига, где найдено изменение:

NOC Project настройка

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

Полезно дублировать конфиги устройств из среды NOC в отдельную папку на ноде для быстрого к ним доступа. Каждый конфиг будет хранится в отдельном файле — это удобно. Тут нужно отметить, что в папке будет только последняя версия конфига для каждого устройства. Для этого нужно:

  • Создать папку /var/lib/noc/config_mirror на ноде;
  • Назначить владельцем папке пользователя noc;
  • Создать файл на ноде /opt/noc/etc/settings.yml со следующим содержанием:
path:
  config_mirror_path: /var/lib/noc/config_mirror
  • Перезапустить сервис нока: service noc restart;
  • Выгрузить конфиг нока на ноде:
cd /opt/noc/
./noc config dump > dump
vi dump - проверить значение переменной config_mirror_path
  • Если всё правильно, то создать в crone задачу по синхронизации через rsync с внешним источником.

Можно забирать непосредственно с ноды через WinSCP.

SA - MO

Основной раздел для создания, удаления и просмотра записей устройств. Со временем записей для устройств появится много и тут можно удобно сортировать эти записи различными фильтрами:

NOC Project настройка

Прежде чем создавать запись для устройства нужно понять несколько моментов. Можно для наглядности открыть единственную в новой инсталляции запись в MO - SAE:

NOC Project настройка

Структура профиля устройства

Важный момент: для устройства всегда есть 2 независимых типа профилей, то есть должен быть задан и первый тип, и второй - работу NOC с устройством определяет их совокупность:

  • SA profile — Определяет набор унифицированных скриптов (в каждом SA профиле скрипт, выполняющий некоторые функции - имеет одинаковое название и структуру), созданных заранее разработчиками NOC. Скрипты SA профиля доступны для модификации, но по природе своей - это изначально заданный функционал. Каждый SA профиль создан под конкретную операционную систему устройства. Например, SA profile CISCO IOS - 100% подходит для всех железок CISCO с IOS, но также может подойти для устройств, для которых нет своего SA профиля (при условии, что часть команд идентичны командам в IOS). Пример - коммутаторы Arlan, маршрутизаторы Dionis NX и так далее. Очевидно заработают не все скрипты чужого профиля, малая часть. Что делать в этом случае и как создать свой SA профиль - расскажу далее. Количество скриптов в профиле может различаться и чем их больше, тем больше доступный функционал в NOC для устройств с данным профилем. Физически лежат SA profiles внутри ноды по пути: /opt/noc/sa/profiles

NOC Project настройка

  • Object profile — Определяет какие скрипты из доступных в SA profile будут задействованы и параметры работы с устройством (временные/многие другие). Создаётся пользователем NOC на этапе конфигурирования и заведения устройств SA - Setup - Managed Objects Profile. Единственный заранее существующий Object profile - это профиль по умолчанию default, трогать его не нужно, он создан для устройства SAE (также как и пул P0001 - служебный пул, устройства на нём не опрашиваются, использовать его не надо, так как он только для SAE). Профиль создаётся для группы устройств с одинаковыми параметрами, например CISCO Switch L3. Если много разных устройств, то и профилей Object profile должно получиться много.
Скрипты

Работа со скриптами происходит в автоматическом режиме с настройками из Object Profile — в определённый момент запускается нужный скрипт, затем по его завершении результаты обрабатываются, сохраняются и их можно просматривать предлагаемыми средствами - в записи устройства, в Get Now, в Grafana, на карте сегмента и так далее. Опрос происходит с помощью сервисов activator (тех что много — по 2 на ядро ноды).

Сервисов activator может не хватать, такое можно увидеть в логе, если запустить Box или Periodic вручную — нет свободных активаторов, они все заняты. Тогда работа больших скриптов, которые при своей работе запускают много других скриптов (например, get_interfaces или же расчёт STP на карте), будет оканчиваться крахом. Причём один раз скрипт будет отрабатывать нормально, другой раз — ошибка. Причины :

  • Слишком много устройств и активаторов банально не хватает;
  • Если база устройств "не отбита", то есть присутствуют подвисания и задержки при опросе устройств из-за неверных логинов/паролей и строк сообществ SNMP;
  • При плохих скриптах, скрипт не работает, ждёт таймаута, активатор ждёт скрипт. Такое также может наблюдаться, когда в Object Profile в Box и Periodic заданы нерабочие скрипты для этого SA Profile;
  • При неверном количестве активаторов на ядро. Не вдавался в многопоточность работы NOC, но думаю есть разница, чем является ядро — физическим ядром без HT,  физическим ядром с HT, ядром виртуальной машины, то есть потоком физического процессора. В последнем варианте можно поставить хоть 10 активаторов на ядро — одновременно они работать не смогут (моё субъективное мнение).

В обратном случае — при хорошей базе, чёткой работе устройств, большом количестве ядер и малом числе устройств можно выставить и по 1 сервису activator на ядро. Подбирается это всё индивидуально, в общем случае когда нет проблем — стандартно 2 сервиса на ядро.

Нода в 500 устройств при опросе Box 5 часов, Periodic 30 минут и 8 ядрах — 16 активаторов не хватает, установка 3 активаторов на ядро ничего даёт. На 20 ядрах и 40 активаторах работает очень хорошо.

Вручную поработать со скриптами можно из записи для устройства в закладке Scripts, результат выводится здесь же в предопределённом виде - для некоторых скриптов немного неудобно, так как читаемость такого вывода слабая, но разобраться можно. Тут перечислены все доступные на момент скрипты для данного профиля SA. Часть скриптов работает через SNMP, часть через CLI, часть и так, и так, порядок задаётся в Object Profile на закладке Acces - порядок по умолчанию CLI, SNMP.

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

Часть стандартных скриптов, которые видны в вебе, но отсутствуют в папке профиля для устройства в /opt/noc/sa/profiles, лежат там же в папке профиля Generic. Если в папке профиля присутствует скрипт заменяющий стандартный (с таким же именем), то отрабатывать будет именно он.

Для каких-то профилей SA скриптов много и все они работоспособны (CISCO IOS, Qtech QSW2800) - работать с такими устройствами в NOC одно удовольствие, для каких-то профилей SA может быть лишь часть нужных скриптов. Так же скрипты могут присутствовать, но выдавать ошибку при запуске, это нормально - скрипты находятся в постоянной доработке как разработчиками, так и сообществом NOC. Некоторые нерабочие скрипты при желании возможно допилить самому - опять же будет рассказано далее.

Создание Object profile

На закладке Common:

  • Style — цвет строки записи для устройства с этим профилем в MO. Новые стили заводятся в Main - Setup - Styles, можно красивишные всякие стили поналепить. С этим стилем строка устройства будет выводиться в MO - очень удобно для быстрого поиска, советую раскрасить все Object профиля в свои цвета;

NOC Project настройка

  • Выбрать Shape для устройств — картинка на схеме топологии в Inventory - Network map. Лучше выбрать здесь, чтобы не выбирать каждый раз в записи нового устройства при его заведении. Shape в записи имеет приоритет над Shape в профиле.

Закладка IPAM — добавлять или нет устройство с этим профилем в IP Address Manager - менеджер для учёта использования адресного пространством, нужен смотреть в какой подсети сколько IP адресов занято, сколько свободно и прочее. Находится IPAM - Assigned Addresses. Отметить чекбокс.

Закладка Ping Check - определяет доступность устройства и его цвет на карте сегмента в Inventory - Network map:

  • Зеленый — устройство доступно;
  • Красный — недоступно;
  • Серый — состояние не определено;
  • Желтый — аларм, один из скриптов отработал с ошибкой.

Поэтому выключать Pink Check не надо, иначе все устройства на мапе будут серые, но лучше увеличить время по умолчанию (у меня 300) и можно снять 2 нижних чекбокса - один выводит картинку с пингами в Grafana, второй увеличивает информацию по пингам.

Помимо работоспособности скриптов они ещё должны быть включены, как уже говорилось, в Objects Profile. Включение производится на закладках Box discovery и Periodic discovery, каждый чекбокс - это скрипт. Отмечать все чекбоксы не нужно, только требуемые и работоспособные скрипты (само-собой разумеется, что отмечаемые скрипты должны присутствовать в наборе скриптов SA profile) — чем больше чекбоксов отмечено, тем сильнее нагрузка как на железки, так и на ноду. Если отмечены неработоспособные или отсутствующие скрипты — это ошибки в отчётах и алармы в статусах устройств, если не отмечены нужные чекбоксы — пропадёт требуемый функционал.

Пример. Для Object профиля устройств CISCO (CISCO Switch L3) в Box discovery - Box: отмечаю все скрипты, кроме Profile, в Box discovery - Topology: CDP, STP, LACP (LLDP мои железки в тестовой среде не умеют).

Если на железке работает SNMP и отмечен чекбокс Box discovery - Box - Profile, то по идее NOC сам должен распознать оборудование и самостоятельно подставить требуемый SA профиль в запись оборудования. Как это правильно настроить не разобрался, если выставляю чексбокс Profile, устройство валится в аларм. Во всех профилях Object Profile отключил данный скрипт.

Еще нужно сказать о временных задержках Box discovery и Periodic discovery: чем чаще опрос, тем выше нагрузка, чем реже опрос, тем медленнее актуализируется информация.

Нагрузку на ноду можно снизить уменьшив частоту опроса Консула, поправив в конфиге:

...
consul:
   check_interval: 10
   connect_timeout: 150
...

Следует сказать, что нагрузку на устройства NOC даёт довольно-таки большую, так по SNMP запросов NOC в разы больше, чем у того же Zabbix. Это нужно учитывать.

На закладке Periodic discovery — отметить все чекбоксы, кроме MAC и Metrics.

MAC и Metrics собираются одинаково и в Box, и в Periodic — можно видеть по логу, если запускать вручную в записи для железки через Discovery, поэтому включил только в Box.

Выбор метрик происходит на соседней закладке Metrics: нужно добавить метрики из выпадающего списка и отметить напротив каждой чекбокс включения метрики. После этого в записи для устройства с этим профилем при нажатии на закладку Dashboard будет открываться Grafana с отображением графиков выбранных метрик. В основном использую метрики для просмотра загрузки CPU и памяти.

На вкладке MAC отметить чекбокс Collect All, для сбора mac-адресов в базу Inventory - Mac DB (для дальнейшего поиска устройства по маку подключённого оборудования - удобно). После того как будут настроены профили интерфейсов тут нужно будет поменять на Collect if permitted by interface profile.

Также на мой взгляд сбор MAC адресов нужен только для устройств уровня доступа. Сбор с устройств других уровней, а также сбор с транков сильно захламляет вывод поиска MAC DB. Если у профиля SA нет скрипта определяющего интерфейсы или есть, но нерабочий (AT8000S), то сбора в MAC DB для устройства с таким SA профилем не будет. В этом случае можно искать MAC через скрипт get_mac_address_table внутри записи для устройства.

Если при сохранении профиля всплывёт ошибка, то посмотреть на что ругается и исправить. Вот так кратенько.

Автоматизация добавления новых устройств - не разбирался и не пробовал.

Создание записи устройства

Краткий пример заведения устройства рассказан на странице проекта. В последних версиях NOC внешний вид записи MO изменён, но принцип тот же самый - все обязательные поля выделены цветом.

Обычно записи добавляются сразу для группы устройств (для сегмента сети), поэтому порядок такой - первая запись забивается руками и сохраняется, последующие с помощью кнопки Clone внутри записи: нажать Clone, отредактировать имя и IP адрес, сохранить - значительно ускоряет заведение устройств.

Итак, Name — понятное имя на латинице.

Раздел Role:

  • Object Profile — свежесозданный профиль.

Раздел Platform:

  • SA Profile — CISCO.IOS.

Раздел Access:

  • Scheme — SSH/Telnet;
  • Address — IP адрес устройства;
  • User — имя пользователя;
  • Password — пароль;
  • Super Password — второй пароль (обычно в случае Telnet);
  • RO/RW Community — строки сообщества SNMP;
  • Time Pattern — Any.

Раздел Location:

  • Administrative domain — созданый административный домен;
  • Segment — созданый сегмент;
  • Pool — default.

Раздел Ivent Sources:

  • Trap Source — Management Address;
  • Syslog Source — Management Address;
  • Trap Community — строка сообщества для трапов.

Указывает откуда NOC должен ожидать приход сообщений Syslog и SNMP для данного устройства (Management Address - с адреса, который был указан в разделе Access).

Важно: если реальный адрес, с которого приходят сообщения, отличается от указанного, то сообщения будут отброшены. В этом случае IP адрес нужно выставлять руками - тут надо понять работу прокси и с какого адреса приходит сообщение. Для трабл-шутинга прихода сообщений полезно использовать trapcollector-default.log на ноде.

После заведения записи переходим на вкладку Scripts и запускаем скрипт login — должен отработать со значением true.

Также можно запустить скрипт login через CLI:

cd /opt/noc
./noc login MONAME
Основные скрипты

Скрипты в примерном порядке их важности:

  • login;
  • get_config;
  • get_interfaces - зависим от других скриптов, например, get_portchannel, get_switchport, get_lacp_neighbors.

Скрипт login проверяет возможность подключения к устройству, get_config забирает с устройства конфиг, get_interfaces — если этот скрипт работоспособен, то для устройства будут определены интерфейсы и на схеме топологии можно будет связать его с другими устройствами линками вручную, нет — устройство будет одиноко висеть на схеме сегмента.

Скрипт login является стандартным (/opt/noc/sa/profiles/Generic/login.py), но для его правильной работы должен быть правильно заполнен скрипт с шаблонами __init__.py.

Кстати, с этим скриптом есть полезный "lifehack": никто не мешает при заходе им на железку проверять что-нибудь, например вбитые настройки и прочее и отдавать "False" если что-то не понравилось. В этом случае, пока, всё не будет приведено в норму - НОК будет всё время подбирать логин/пароль к железке и не будет её опрашивать (при выставленном профиле Аутентификации с подбором логина/пароля). К сожалению, это будет влиять на профиль целиком. 
Но, никто не мешает клонировать существующий профиль и добавить туда такой "специальный" скрипт.

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

  • get_discovery_id — по этому скрипту NOC определяет внутреннее имя железки, которое отличает его от других железок;
  • get_cdp_neighbors, get_lldp_neighbors, get_lldp_neighbors.

В NOC присутствует несколько параллельных механизмов связывания линков и разрабатываются новые (в частности, проскакивала информация о планах сделать альтернативную линковку на основе MAC-адресов интерфейсов).

После назначения профиля SA устройству и сохранения записи, нужно зайти на закладку Scrips и проверить работоспособность основных скриптов.

Удаление записи устройства

Иногда при удалении записи для устройства происходит сбой, запись не удаляется целиком из базы, тогда в MO записи уже нет, но если открыть карту сегмента, то там будет устройство и вместо имени wiping-"цифровое значение". Удалять нужно через CLI:

cd /opt/noc
./noc wipe managed_object 2

Где 2 — как раз то самое цифровое значение.

NOC Project настройка

Таким образом можно удалять объект МО либо пользователя. Один раз получилось так, что сам объект удалился, а связанные с ним данные из базы datastream/ping нет. В результате сервисы пинга вываливались с трейсом, где присутствовал недоудалённый объект wiping. Может кому пригодится:

для wiping-722

Посмотреть:

# ./noc datastream get --datastream=cfgping 722
...
{
"status":null,
"count":15,
"name":"wiping-722",
"change_id":"5b72daef9e40bfa668231f56",
"interval":600,
"time_expr":"True",
"report_attempts":false,
"timeout":1000,
"report_rtt":true,
"policy":"f",
"bi_id":5901858178645758968,
"id":"722",
"pool":"default",
"size":64
}

Убить:

# mongo --username noc -p --authenticationDatabase noc noc
Enter password: noc
noc:PRIMARY> db.ds_cfgping.find({"_id" : 722})
noc:PRIMARY> db.ds_cfgping.findOneAndDelete({"_id" : 722})
Auth Profile

При добавлении записи устройства в MO реквизиты доступа логин и пароль - вбивались руками. Это неудобно, во-первых, это занимает время при заведении, во-вторых, если пароль (логин) будет поменян, то придется обойти все записи и руками перебить пароль - треш. Поэтому есть удобный инструмент - профиль авторизации SA - Setup - Auth Profiles. Использую профили авторизации 2 типов (поле Type) - остальные не знаю:

  1. Local Group — тут вбиваются логин, пароль, комьюнити, затем профиль сохраняется и используется уже в записях устройств;
  2. Suggest — вбиваются различные пары логин/пароль (Suggest CLI), а при применении этого профиля в записи устройства подбирается рабочая пара для входа на устройство и она подставляется уже в поля User/Password записи устройства.

Тип Suggest — удобная штука, если связка логин/пароль не меняется, если же происходит изменение, то вход на устройство будет неудачным, так как после того как удачная пара подобрана, она жёстко вписывается в запись для устройство и больше подбор не применяется.

Работа с записью устройства

После того как запись для устройства заведена, через время указанное в Box и в Periodic отработают скрипты, будет собрана информация об устройстве и заполнены различные разделы в записи устройства.

В частности в главном окне записи заполнится раздел Platform:

NOC Project настройка

Далее кратко по пунктам меню записи:

  • Card — сводная карточка оборудования;
  • Dashbord — вывод через Grafana включенных метрик;

NOC Project настройка

Вот так это выглядит, у меня NOC тестовый, железки ничего не делают, пилообразная загрузка CPU - это как раз опрос NOC'а.

С вводом новой башни правильный Data Source для Grafana прописывается автоматом. А до этого нужно было делать так — зайти под учёткой admin, открыть Grafana для любой записи, выбрать пункт Data Source, настроить как на картинке (пароль для readonly задается в сервисах в башне и по умолчанию noc). Иначе графики для выбранных метрик выводились рандомно:

  • Show Map — вывод карты сегмента (аналогично Inventory - Network Map);
  • _Console — консоль устройства, работает, все манипуляции нужно осуществлять из строки ввода, которую не так-то просто заметить;

NOC Project настройка

  • Scripts — вывод всех доступных скриптов с возможностью их запуска;
  • Config — просмотр конфига (аналогично Get Now);
  • Inventory - будут выедены компоненты устройства, такие как, например, SFP модули (если они были распознаны NOC);
  • Interfaces — важный раздел, выводит информацию об интерфейсах с возможностью конфигурирования связей между устройствами и настройкой профиля интерфейса;
  • Links - просмотр найденых связей между устройствами и метода, которым эта связь найдена;
  • Discovery — важный раздел, просмотр состояния опроса устройства и лога работы Box, Periodic и Ping;
  • Alarm — просмотр открытых алармов для устройства с возможностью их ручного закрытия;
  • Capabilities — поддерживаемые устройством возможности с точки зрения NOC;
  • Facts — различная информация об устройстве в виде раскрывающегося списка (дополняет Card).

Остальные пункты не знаю/не использую.

Важно: как уже было сказано скрипты запускаются автоматически через Box и Periodic с указанными интервалами, но можно запустить опрос вручную на закладке Discovery. Например, когда запись для устройства только что заведена в NOC и нет времени ждать, когда скрипты отработают по таймеру.

SA - Run Commands

Очень полезный инструмент, когда нужно выполнить одинаковые команды на группе однотипных устройств, чем больше группа, тем больше экономия времени. Несколько раз приходилось выполнять набор команд на более чем 100 устройствах Qtech.

Порядок выполнения:

  • Отметить чекбоксы нужных устройств;
  • Нажать Do Checked;
  • В окошке Commands ввести команды так, как бы они вводились из привилегированного режима;
  • Нажать Run;
  • Дождаться выполнения: строка устройства выделена зелёным цветом — команды выполнены успешно, красным - неуспешно либо нет подключения к устройству.

Следует обратить внимание, успешное выполнение команд не означает автоматического получения нужного результата - а только лишь то, что команды отработали без ошибок. Поэтому после выполнения нужно нажать на строку устройства, тогда в окошке отобразится лог работы, посмотреть лог и убедиться в достижении нужного результата. Достаточно проверить на 1 устройстве — на остальных результат аналогичен.

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

SA - Reports

Самый важный отчёт это Discovery Problem — помогает разобраться на каких устройствах какие скрипты отрабатывают криво, а дальше уже разбираться с настройкой устройств/скриптов.


Inventory

Второй после SA важный раздел NOC. Опять же, пользуюсь тут не всем и расскажу только то, что знаю. Здесь:

  1. Можно просматривать карты сегментов;
  2. Искать интерфейс/устройство по MAC-адресу через MacDB;
  3. Также разные нужные настройки в Setup.
Network map

Очень полезная штука чтобы сразу визуально оценить состояние подсети сегмента - видно какие устройства недоступны, где есть открытые алармы. Кроме этого наглядно видны проблемы с линками и STP.

Для начала нужно ознакомиться с обозначениями:

NOC Project настройка

и ещё:

NOC Project настройка

  1. Отображение устройств по имени/по IP;
  2. Отображение загрузки линков;
  3. Расчёт STP.

Чтобы всей этой лепотой пользоваться нужно:

  • В Object profile включить Ping Check - будет правильно отображаться статус устройства;
  • Создать профиль интерфейса и повесить его на все аплинки — будет правильно отображаться пропускная способность интерфейса, его загрузка.
Создание профиля интерфейса

Классификация интерфейсов.

Идём Inventory - Setup - Interface Profiles и видим там единственный профиль по умолчанию, который и присвоен всем интерфейсам. Заходим в него и меняем MAC Discovery Policy на Enable, чтобы с интерфейсов собирались маки в MacDB, сохраняем.

Затем клонируем профиль и называем новый профиль uplink, MAC Discovery Policy выключаем и ставим галку Status Discovery. Потом руками меняем профиль для слинкованых интерфейсах на uplink. Сделать это можно либо записи устройства в MO, в пункте меню Interfaces, либо в Inventory - Interfaces, выбрав устройство:

NOC Project настройка

Когда интерфейсы будут опрошены, для них будет определена пропускная способность - она выведется в пункте Interfaces и на карте сегмента - вместо пунктирной линии появится линия определённой толщины. Удобно, можно сразу определить где интерфейсы работают неправильно - допустим 100Mbit вместо 1Gbit. Статус интерфейса собирается естественно по SNMP - SNMP должен быть настроен на устройстве и комьюнити прописано в записи устройства.

Также к профилю интерфейса можно прикрутить метрики, что очень удобно.

Следует помнить, что сбор статусов интерфейсов и метрик расходует ресурсы, поэтому не надо собирать статусы со всех интерфейсов, дабы не перегружать железки/ноду.

По поводу ручной линковки: у меня частенько интерфейсы слинкованные вручную теряли, поэтому создал отдельный профиль с Discovery Policy выставленной в Ignore.

Профилей можно создать много разных под свои задачи, так у меня: аплинк со сбором метрик для уровня Distribution, без метрик и без статуса аплинк для уровня Access, аплинк для ручной линковки и так далее.

Ещё 1 момент: понятно что управляемые коммутаторы не надо соединять между собой через неуправляемый - это в теории, но на практике случается и решить такую проблему, тем более удалённо, тем более когда сотрудник 1 линии избегает этим заниматься - решить тяжело. Когда такое происходит, то скрипты get_cdp_neighbors и get_lldp_neighbors начинают сходить с ума - на 1 интерфейсе сразу несколько соседей разных коммутаторов и линк прыгает между устройствами. На данный момент реализован мультилинк в ручном режиме через ./noc shell.

Пример. Как создать мультилинк:

NOC Project настройка

cd /opt/noc
./noc shell

from noc.sa.models.managedobject import ManagedObject
from noc.inv.models.interface import Interface
from noc.inv.models.link import Link
mo0 = ManagedObject.objects.get(name="3550-1")
mo1 = ManagedObject.objects.get(name="2950-1")
mo2 = ManagedObject.objects.get(name="2950-2")
iface0 = mo0.get_interface("fa0/4")
iface1 = mo1.get_interface("fa0/4")
iface2 = mo2.get_interface("fa0/4")
Link(interfaces=[iface0,iface1,iface2], discovery_method="manual").save()

NOC Project настройка

Особенности такой линковки:

  • Таким образом можно связать 2, 3 или больше интерфейсов;
  • Мультилинк создастся даже если у интерфейсов уже есть линки. В обычной ситуации через Веб так сделать нельзя и можно повесить только 1 линк на интерфейс;
  • Мультилинк создаётся даже если уже есть мультилинки с этими интерфейсами;
  • Удалить так созданный мультилинк обычными средствами через Веб нельзя;
  • Удалить мультилинк можно также как и создать: через Shell командой Link.delete().

Разработчики подсказали метод удаления:

cd /opt/noc 
./noc shell 

from noc.sa.models.managedobject import ManagedObject from noc.inv.models.interface import Interface 
from noc.inv.models.link import Link

mo0 = ManagedObject.objects.get(name="0")
iface0 = mo0.get_interface("f0/1")
link = Link.objects.filter(interfaces=iface0.id).first()
link.delete()

Особенности: если было заведено N мультилинков на интерфейсе, удалять придётся N раз.

Также хотелось бы видеть возможность вводить описание для сегмента карты — туда было бы очень удобно заносить текущие задачи и вопросы по этому сегменту.

Кроме этого, когда между устройствами несколько линков, то на карте их не видно, они накладываются один поверх другого.

Создание профиля сегмента

Inventory-Setup-Network Segment Profile: создаём, меняем параметры, задаём цветовую схему, присваиваем сегментам. Главное чем тут пользуюсь — методы автолинковки, если в профиле сегмента метод не добавлен, то он будет пропускаться при отработке Box, даже когда соответствующий чекбокс отмечен в Object profile.

STP

Тоже крайне полезная вещь, после расчёта будет выведен корневой свич/свичи, какие линки задействованы, какие отключены и можно сразу понять правильно ли настроен STP, в соответствии с разработанной стратегией или нет. Так в нескольких сегментах сети, сразу после их заведения в NOC и при отображении этого расчёта были выявлены ошибки: где-то на некоторых коммутаторах STP вообще не был включен, где-то использовались несовместимые протоколы STP - и этот непорядок сразу бросался в глаза на карте сегмента.

Выводы

Моё мнение субъективно, ни на какую вселенскую истину в 1 инстанции не претендую 🙂 но мой вывод такой  Qtech мегареспектовые железки, сегменты по 15-20 коммутаторов через полчаса после заведения уже были полностью автослинкованы, после выставления аплинков ещё через короткий промежуток интерфейсы уже со статусом и всё работает, всё отображается. Плюс полная калька с CISCO, а значит знакомые команды, плюс отечественный производитель, рекомендованный к импортозамещению, плюс не заоблачная цена.

Mac DB

Полезная штука в 1 очередь для 1 линии хелп-деска: отвалился пользовательский компьютер/принтер/сервер и нужно быстро узнать на каком коммутаторе, на каком порту это дело висит.

MAC-адрес 48 битовый, выводится обычно как 6 октетов, каждый октет отображается с помощью 2 цифр 16-разрядной системы счисления (каждая цифра 4 бита). Соответственно для поиска по MacDB нужно скопировать в поле поиска 2 последних октета с двоеточиями.

Пример. MAC 84-16-F9-05-8D-7C, в поле поиска нужно поместить

  • Начальную часть 84:16: (для поиска группы устройств);
  • Хвостовую часть :8D:7C (удобный поиск 1 устройства);
  • Или адрес целиком 84:16:F9:05:8D:7C

Посмотреть собирается ли вообще что-то в Mac DB:

clickhouse-client clickhouse-client --host 127.0.0.1

select * from noc.mac limit 10 - выведет собранное

exit

Fault Management

Не очень мне нравится этот раздел, как он устроен. Не могу понять чего, но чего-то не хватает. Алармы открываются автоматически при возникновении проблемы и автоматически закрываются при исчезновении проблемы, но иногда автозакрытия не происходит. Тогда нужно зайти в запись устройства MO, в пункт меню Alarm и закрыть руками.

Самая важный в FM это FM - Alarms, чтобы что-то вывелось нужно выбрать Show recently closed и какой-то, к примеру, селектор. Селектор можно создать SA - Setup - Managed Odject Selector, к примеру, для всего оборудования:

Соответственно в FM будет так:

Можно нажать на значок глобуса в записи аларма, тогда откроется карта сегмента или на значок глаза, тогда откроется запись объекта MO.

Есть ещё FM - FM Monitor, тут сводная информация по количеству алармов/эвентов.

Чистка эвентов: делать нужно очень аккуратно, если очистить эвент по которому поднят аларм, то можно нарушить работу NOC и потом посыпать голову пеплом:

cd /opt/noc 
./noc shell

from noc.fm.models.activeevent import ActiveEvent

event_filter = ["595a2e02de7e511563c4d6d3", "595a2e03de7e511563c4d781", "595a2e01de7e511563c4d686", "595a2e01de7e511563c4d690"]

events = ActiveEvent.objects.filter(event_class_in=event_filter)

for event in events:
 print(event.subject)
 event.delete()

Сейчас к сожалению перестало работать, но для того, кто хочет разобраться — последовательность действий такая же.


Работа с ошибками

Удаление записей

Некоторые записи в разных разделах NOC ссылаются на другие записи в других разделах. Чтобы удалить запись, нужно удалить все ссылающиеся на неё записи. Может быть вложенность.

Пример. Чтобы удалить запись вендора Inventory - Setup - Vendors, нужно удалить записи Inventory - Setup - Firmware и Inventory - Setup - Platforms, отфильтровав предварительно по данному вендору. А чтобы удалить эти записи, нужно убрать все упоминания о них во всех записях устройств MO.

Обычно всплывающая ошибка на красном поле снизу окна Веба при удалении устройства подсказывает в каком направлении рыть. Но иногда-таки сложно сразу разобраться где и что искать.

Поиск и исправление ошибок

Поскольку среда NOC активно разрабатывается и дорабатывается, то всяких багов выше крыши - это нормально. Такой мощнейший продукт предлагается абсолютно бесплатно, да ещё и пожелания по включению нового функционала учитываются - это покрывает все недостатки, ну а кого не устраивает, можете заплатить хорошие бабки и пользоваться альтернативными платными продуктами.

Что делать если найдена ошибка? Как уже говорилось в 1 части:

  • Поискать ошибку на канале Telegram, возможно она уже обсуждалась;
  • Поискать на баг-трекере: https://code.getnoc.com/noc/noc/issues/
  • Ничего не найдено — выложить на баг-трекер и задать вопрос на канале Telegram со ссылкой.

Самостоятельно проанализировать ошибки на своей ноде и посмотреть что происходит:

cd /opt/noc

./noc crashinfo list
./noc crashinfo view UID - подробно посмотреть конкретное событие по UID из crashinfo list

Для работы есть команда ./noc fix:

[root@node1 noc]# ./noc fix list
compact_schedules
convert_conduits_links
convert_pop_links
fix_bi_id
fix_broken_outages
fix_discoveryid_macs
fix_etl_order
fix_firmware_full_name
fix_geocodercache_query
fix_inv_root
fix_link_objects
fix_object_coordinates
fix_object_paths
fix_object_uplinks
fix_ordermap
fix_phone_parents
fix_platform_full_name
fix_platform_sysobjectid
fix_pop_links
fix_segment_access
fix_segment_redundancy
fix_segment_summary
fix_selector_cache
fix_tags
set_snmp_v2c
[root@node1 noc]#

Также полезно использовать команду ./noc с опциями дебаг и чек:

usage: discovery.py run [-h] [-c CHECK] [--trace] {box,periodic} ...

./noc discovery --debug run --check=config box MONAME 
./noc discovery --debug run box MONAME --check=interfacestatus 
./noc discovery --debug run --check=lldp box MONAME 
./noc discovery --debug run periodic MONAME
./noc discovery run --check=metric periodic MONAME

usage: login.py [-h]
[--loglevel {critical,error,warning,info,debug,none} | --quiet | --debug | --enable-profiling | --show-metrics]
[--backend BACKEND] [--user USER] [--password PASSWORD]

./noc login --debug --backend=ldap --user=User
./noc login --debug --user=User

Для юзера сейчас вываливается в трейс, скорее позже починят.

Consul

Совсем недавно узнал, что работоспособность ноды также можно отслеживать в Consul по урлу http://IP_ноды:8500

NOC Project настройка

Чтобы удалить отсюда несуществующий/нерабочий Telegraf, для которого будет отображаться ошибка, нужно почистить папку /etc/consul.d


Доработка скриптов

Очень интересная и большая тема. Если для конкретной железки есть свой профиль SA — это хорошо, значит хоть какой-то функционал мы для неё уже получили. Если нет, то можно взять наиболее подходящий чужой профиль SA. В каком случае это вообще нужно делать? Считаю, что устройство есть смысл добавлять в MO, когда у него по крайней мере рабочий скрипт get_config.

А что делать когда нет подходящего профиля SA, а устройство нужное и важное? Конечно же разработать отдельный профиль для этой железки и наполнить его рабочими скриптами.

Как создать собственный профиль SA

Если есть устройство для которого нет профиля SA, а профили устройств других производителей для него подходят лишь частично, то:

  • Попробовать для него разные профили SA, чем больше, тем лучше — проверять запуск скриптов из соответствующего пункта меню внутри записи MO для устройства;
  • Подобрать наиболее близкие профили с наибольшим количеством рабочих скриптов;
  • Подключиться к ноде через WinSCP, папка /opt/noc/sa/profiles;
  • Создать там новую папку с названием производителя, внутри папку с названием модели оборудования;
  • Создать новый профиль Service Activation - Setup - Profiles (название профиля должно точно соответствовать названию папок чрез точку);
  • Скопировать внутрь этой папки файлы рабочих скриптов из папок других профилей SA;
  • Поменять в файлах *.py пути на верные, файлы *.pyc это откомпилированные под Python файлы *.py - их удалить, пересоздаются автоматически после запуска соответствующего скрипта *.py через CLI;
  • Редактировать далее скрипты, добиваясь их работоспособности;
  • Как минимум — опять же уже говорил должен заработать get_config.

Интересная вещь: конфиг можно получить по SNMP. Подробно для CISCO описано здесь: //www.ciscozine.com/how-to-save-configurations-using-snmp/ Проверял, работает и такой метод используется для нескольких профилей SA, главное чтобы сообщество SNMP было на запись (RW).

Важно: названия скриптов должны быть в точности сохранены, иначе возможны неприятности. Так у меня из-за неправильного названия скрипта при открытии в Вебе вкладки Scripts для любого объекта MO c данным профилем SA возникала ошибка и скрипты не отображались.

Как работает скрипт

Прежде чем редактировать существующие и клепать свои собственные скрипты, полезно будет понять основные моменты в работе скрипта:

  • Скрипт состоит из 2 взаимозаменяемых частей - CLI части и SNMP части;
  • Порядок работы частей задаётся в Object profile;
  • Если 1 часть отработала неуспешно, только тогда запускается 2 часть;
  • SNMP часть забирает параметры непосредственно по своему протоколу;
  • CLI часть сначала осуществляет вход на устройство (должен быть рабочим скрипт login), затем на устройство отсылается команда, обычно это команда show... Затем вывод этой команды считывается и присваивается строковой переменной.

После того как необходимые строковые переменные заполнены, начинается их дальнейшая обработка в скрипте для получения необходимого вывода.

Какой здесь главный момент — если нужно редактировать/дорабатывать/создавать скрипты, то необходимо:

  1. Научится работать со строковыми переменными в Python — форматировать их к определённому виду, проверять их на присутствие заданных символов и слов, выбирать из них заданные символы и слова, заменять одни символы в строке на другие;
  2. Уметь работать с регулярными выражениями.

Самые частые приёмы работы со строками, которые встречались мне:

len(a) - длина строки
a = a.strip() - удалить из сроки начальные и конечные пробелы, можно передавать и другие символы для вырезания: a.strip("sl ")
a = a[0:-1] - удалить из строки последний символ
a = a.split('символ') - разделить сроку на части между вхождениями символа символ, чаще всего этим символом является пробел, то то есть бьём строку на слова, а затем ищем/выбираем нужное
a = a[1] - в прошлом примере побили строку на части и теперь выбрали 2 часть: 0 - 1 часть, 1 - 2, ..., -1 - последняя
a = a + b - сложение строк a и b
a = a.replace(' ','*') - заменили в строке a все пробелы на звездочки

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

Редактирование скриптов

Первое, что тут нужно сказать — отступы, они должны быть строго фиксированы для каждой строки, а не как попало, иначе скрипт с неверными отступами для строк будет отрабатывать с ошибкой:

IndentationError: unexpected indent

Скрипты можно редактировать прямо через WinSCP, но удобнее копировать их на компьютер и дальше править в Notepad++. Работа в Notepad++ помогает контролировать правильность отступов.

Второе — для профилей SA в папке вендора, внутри папки с моделью устройства есть скрипт __init__.py, в нём задаются шаблоны для работы других скриптов (пустой __init__.py внутри папки вендора должен присутствовать).

Пример.

vi /opt/noc/sa/profiles/DCN/DCWL/__init__.py

class Profile(BaseProfile):
        name = "DCN.DCWL"
        pattern_prompt = r"^(?P<hostname>\S+)\s*#"
        command_more = "\n"
        command_submit = "\n"
        command_exit = "exit"
  • pattern_prompt — шаблон обработки вывода строки приглашения в CLI, допустим для CISCO это будет приглашение вида Switch#, а для другого производителя уже по-другому;
  • command_more — разделитель между страницами при выводе конфига в CLI, допустим для CISCO IOS таким разделителем будет --More-- и нужно нажать пробел для вывода следующей страницы, для другого производителя опять же по-другому.

Соответственно файл __init__.py должен быть правильно заполнен. Вот тут и пригодятся регулярные выражения. Подгонять регулярку к требуемому виду удобно здесь.

Третье — после того как скрипт отредактирован с ним можно уже сразу работать через CLI: подключаемся к ноде по SHH, идём в директорию /opt/noc и в ней запускаем наш скрипт:

./noc script название_скрипта MONAME

root@NODE1:/opt/noc# ./noc script get_version "2950-1"

./noc script
usage: script.py [-h]
[--loglevel {critical,error,warning,info,debug,none} | --quiet | --debug | --enable-profiling | --show-metrics]
[--pretty | --yaml] [--without-snmp]
[--access-preference ACCESS_PREFERENCE]
[--update-spec UPDATE_SPEC]
script object_name ...

Чтобы изменения стали доступны и в вебе - сервис noc нужно перезапустить:

service noc restart

Если скрипт отредактирован с ошибками, а именно содержит неверные конструкции языка Python, то скрипт исчезнет из веба. Скрипт может быть нерабочим, но синтаксически он должен быть составлен правильно.

Отладка скриптов

Первым делом нерабочий скрипт нужно запустить в вебе ноды — либо будет красное вплывающее сообщение, что запуск скрипта провалился (скорее всего работа скрипта завершена по тайм-ауту), либо же будет вывод с информацией об ошибке — иногда это очень ценная информация. Например, вот такое сообщение:

NOC Project настройка

Скрипт может быть рабочим, но он не получил данных. Допустим, на устройстве не поддерживается LLDP, а был запущен скрипт get_lldp_neighbors, скрипт не получит начальных данных и отработает вот с такой ошибкой.

Далее дебаг, подключаемся к ноде через SHH, идём в директорию /opt/noc и в ней запускаем дебаг нашего скрипта, всё как в прошлый раз только добавляется параметр --debug :

./noc script --debug название_скрипта MONAME

root@NODE1:/opt/noc# ./noc script --debug get_version "2950-1"

После изучаем вывод дебага. Иногда вывод очень большой, а хочется посмотреть его весь, тогда лучше направить вывод в файл, а потом этот файл через WinSCP забрать, лежать он будет естественно в /opt/noc:

root@NODE1:/opt/noc# ./noc script --debug get_version "2950-1" > 2950report

Открыть 2950report в Notepad++ и просмотреть.

Пример. Выражения могут быть и более сложные:

./noc script --debug --pretty get_lldp_neighbors MONAME
./noc script --debug get_metrics MONAME metrics:='{"CPU | Usage": {"scope": "o"}}'

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

print(имя_переменной)

Иногда таки сильно помогает разобраться.

Вообще редактирование и отладка скриптов NOC — задача нетривиальная и требующая усидчивости, внимательности, а также большого количества времени на изучение нерабочих скриптов, рабочих скриптов из других профилей и на разбор конструкций языка, особенно если ты не программист Python. Тем не менее мне вместе с моими коллегами удалось создать профиль для устройств Dionis NX с рабочими скриптами get_version, get_config и get_interfaces, а также доработать некоторые скрипты для профиля HP 1910, для профиля Brocade CER, для профиля Qtech QSW2800. Так что при наличии желания разбираться — разобраться можно.

Если удалось хорошо допилить, то желательно поделиться с сообществом.

Локальные правки

Если какие-то скрипты были изменены или добавлены новые, то при деплое NOC выдаст ошибку, что присутствуют локальные правки. Как это обойти рассказано в статье NOC Project установка, в разделе На что обратить внимание при деплое. Также была упомянута папка noc_custom, куда должны быть снесены все локальные правки, но разобраться до конца с работой этой папки не смог, всегда пользовался git stash/git stash pop - возможно получится у вас. А при создании папки  noc_custom со всей иерархией вложенности как для оригинальной папки noc и со скриптами __init__.py, приводило к тому, что нода начинала работать нестабильно.


Полезное

Просмотр MO без Веб-интерфейса с помощью браузера: https://IP_ноды/sa/managedobject/

Сlickhouse
# clickhouse-client --host=127.0.0.1
ClickHouse client version 18.10.3.
Connecting to 127.0.0.1:9000 as user default.
Connected to ClickHouse server version 18.10.3 revision 54405.
clickhouse2 ) select * from noc.ping where date='2018-10-15'
MongoDB
  • Очистка кеша монги:
mongo --username noc -p --authenticationDatabase noc noc

ввести пароль (по умолчанию noc)

db.noc.caches.mongo.remove({})
  • Обновление MongoDB c выгрузкой базы (тут конкретно с 3.2 на 3.4, для других версий по аналогии) - вообще в случае с монгой, 3.4 нормально подтягивается при деплое, в отличие от апгрейда постгре, где делать надо обязательно руками:
mongodump -u noc -p noc --db noc --out /opt/noc/mongodump/
service mongod stop
yum remove mongodb-org

Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
 Erasing : mongodb-org-3.2.16-1.el7.x86_64 1/1
 Verifying : mongodb-org-3.2.16-1.el7.x86_64 1/1

Removed:
 mongodb-org.x86_64 0:3.2.16-1.el7

Complete!

vi /etc/yum.repos.d/mongodb-org-3.4.repo
 
[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc

sudo yum install -y mongodb-org

service mongod start

mongorestore --verbose --db noc -u noc -p noc /opt/noc/mongodump/noc

Ссылка по установке 3.4, ссылка по восстановлению.

  • Обновление монги с 3.4 до 3.6 рассказано в 1 части, тут уже дублировать не буду.
PostgreSQL

Обновление до 9.6, все действия от root, кроме пары моментов, где пользователь должен быть postgres:

yum install https://yum.postgresql.org/9.6/redhat/rhel-7.3-x86_64/pgdg-redhat96-9.6-3.noarch.rpm - добавление репозитория

yum install postgresql96-server postgresql96-contrib - установка

/usr/pgsql-9.6/bin/postgresql96-setup initdb - создание папки и инициализация

[root@node1 ~]# su postgres
[postgres@node1 /root]$ cd ~
[postgres@node1 ~]$ /usr/pgsql-9.6/bin/pg_upgrade --old-bindir=/usr/pgsql-9.4/bin/ --new-bindir=/usr/pgsql-9.6/bin/ --old-datadir=/var/lib/pgsql/9.4/data/ --new-datadir=/var/lib/pgsql/9.6/data/ --check - только проверка возможности апгрейда, должно закончиться с результатом *Clusters are compatible*

service postgresql-9.4 stop - остановка сервиса

/usr/pgsql-9.6/bin/pg_upgrade --old-bindir=/usr/pgsql-9.4/bin/ --new-bindir=/usr/pgsql-9.6/bin/ --old-datadir=/var/lib/pgsql/9.4/data/ --new-datadir=/var/lib/pgsql/9.6/data/ - обновление

service postgresql-9.6 start - запуск сервиса

systemctl enable postgresql-9.6 - включение сервиса на автозагрузку

[postgres@node1 ~]$ ./analyze_new_cluster.sh - оптимизация после установки
NOC

Основные настройки кроме башни можно также посмотреть в конфиге на ноде в CLI:

vi /opt/noc/etc/noc.yml

(ссылка на устройство конфигурационных файлов уже приводилась ранее в разделе про создание Object profile).

NOC Shell - используется для автоматизации работы с объектами, в примере у всех записей MO профиль SA меняется на Generic.Host:

cd /opt/noc

./noc shell

from noc.sa.models.profile import Profile
from noc.sa.models.managedobject import ManagedObject
p = Profile.objects.get(name="Generic.Host")
for mo in ManagedObject.objects.filter():
 mo = p
 mo.save()

В примере порядок опроса железок меняется на CLI, SNMP:

./noc shell
from noc.sa.models.managedobjectprofile import ManagedObjectProfile
for mop in ManagedObjectProfile.objects.filter():
 mop.access_preference = "CS"
 mop.save()

Перезапуск сервиса NOC выполнить целиком:

service noc restart
или
/opt/noc/noc ctl restart all

Если посмотреть статус NOC как:

[root@node1 noc]# /opt/noc/noc ctl status
activator-default:activator-default-00 RUNNING pid 5424, uptime 2 days, 1:18:32
activator-default:activator-default-01 RUNNING pid 5425, uptime 2 days, 1:18:32
activator-default:activator-default-02 RUNNING pid 5422, uptime 2 days, 1:18:32
activator-default:activator-default-03 RUNNING pid 5423, uptime 2 days, 1:18:32
activator-default:activator-default-04 RUNNING pid 5420, uptime 2 days, 1:18:32
activator-default:activator-default-05 RUNNING pid 5421, uptime 2 days, 1:18:32
activator-default:activator-default-06 RUNNING pid 5418, uptime 2 days, 1:18:32
activator-default:activator-default-07 RUNNING pid 5419, uptime 2 days, 1:18:32
bi:bi-00 RUNNING pid 5441, uptime 2 days, 1:18:32
bi:bi-01 RUNNING pid 5440, uptime 2 days, 1:18:32
card:card-00 RUNNING pid 5444, uptime 2 days, 1:18:32
card:card-01 RUNNING pid 5445, uptime 2 days, 1:18:32
ch_datasource:ch_datasource-00 RUNNING pid 5428, uptime 2 days, 1:18:32
...

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

[root@node1 noc]# /opt/noc/noc ctl restart activator-default:activator-default-00
activator-default:activator-default-00: stopped
activator-default:activator-default-00: started

[root@node1 noc]# /opt/noc/noc ctl restart activator all
Команды CLI

Список доступных команд для ./noc можно посмотреть на ноде в /opt/noc/commands:

NOC Project настройка

[root@node1 ~]# cd /opt/noc
[root@node1 noc]# ./noc about
15.05.1+microservices.8991.469dbff6
Проблемы SSH

Если соединение сбрасывается, хотя должно работать (всё настроено правильно, с ACL тоже всё в порядке):

Connection refused

В этом случае достаточно перегенерировать сертификат для SSH на устройстве.

Если попробовать подсоединиться через SSH с ноды, например, на CISCO 2950, то получим ошибку:

[root@node1 ~]# ssh -l admin 192.168.64.254
Unable to negotiate with 192.168.64.253 port 22: no matching cipher found. Their offer: 3des-cbc

Связано с неподдерживаемым методом шифрования. Чтобы разрешить 3DES:

[root@node1 ssh]# vi ssh_config

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc - раскомментировать строчку, сохранить

[root@node1 ssh]# service sshd restart
[root@node1 ~]# ssh -l admin 192.168.64.254

The authenticity of host '192.168.64.253 (192.168.64.253)' can't be established.
RSA key fingerprint is SHA256:q9gyy1YGXwzOaI8B/mMDkDc5fTMSyMk/4QeefD0imL0.
RSA key fingerprint is MD5:3f:13:84:3a:8b:37:0b:69:7d:ef:18:c6:34:01:dc:aa.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.64.253' (RSA) to the list of known hosts.
admin@192.168.64.254's password:

Switch2# - подключение успешно установлено

Заключение

Вот та часть, небольшая часть NOC Project, которую удалось изучить мне. Есть ещё очень много интересного для прочтения. Тем не менее надеюсь, что 2 мои статьи будут полезны тем, кто решил разворачивать NOC. Со всем остальным или за всем остальным - добро пожаловать на Telegram-канал: https://t.me/nocproject

NOC Project настройка: 2 комментария

  1. Приветствую. Замечательный материал, уточню пару моментов, если позволите.
    В примерах работы со строками очепятка: "a = a.split() - удалить из сроки начальные и конечные пробелы", надо использовать a.strip(), кстати, ей можно передавать и другие символы для вырезания: a.strip("sl ")

    Список доступных команд для выполнения можно подсмотреть в папке "commands", в старых версиях их можно было увидеть через вывод "./noc", сейчас такой возможности нет.

    Скрипт "login" не является обязательным. Просто, он используется при подборе пользователя/пароля, по нему оценивается - успешно ли зашли на железку. Обычно, хватает реализации "по-умолчанию", расположенной в "sa/profiles/Generic/login.py", но бывают ситуации, когда "умолчательной" реалиазции недостаточно. Кстати, с этим скриптом есть полезный "lifehack": никто не мешает при заходе им на железку проверять что-нибудь, Н-р вбитые настройки и прочее и отдавать "False" если что-то не понравилось. В этом случае, пока, всё не будет приведено в норму - НОК будет всё время подбирать логин/пароль к железке и не будет её опрашивать (при выставленном профиле Аутентификации с подбором логина/пароля). К сожалению, это будет влиять на профиль целиком. Но, никто не мешает клонировать существующий профиль и добавить туда такой "специальный" скрипт.

    Ещё в последних версиях НОКа появилась полноценная поддержка мультилинков. На карте они отображаются "Облачком". Линков, правда, только вручную (через "./noc shell"), но, начало положено!

    Спасибо ещё раз. Очень нехватает статей с первоначальным описанием. Буду следить за продолжениями!

    1. Спасибо, Андрей. Весьма приятно услышать положительную оценку, тем более от гуру NOC Project. Это дорогого стоит, значит не зря. Рад любым замечаниям и дополнениям, так как статью конечно же будут читать и ошибки в ней делу не помогут. Поправки сделаю. Вряд ли возможны полноценные продолжения: 1)выложил всё что знал; 2)неизвестно когда в следующий раз будет профильная работа. Вобщем моё мнение такое: 2 статей вполне достаточно чтобы худо-бедно запустить NOC в продакшен. Ну а дальше личное творчество 🙂

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *