NOC Project настройка

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

Первую часть (об установке через башню) пришлось убрать в связи с законом о запрете на популяризацию VPN. Уж сорян. Кроме этого появился новый простой метод установки. Пока не пробовал. Если действительно всё просто, то возможно мой громоздкий рассказ про установку через башню вообще излишен.

Делалось в 2018 году. Начну потихоньку переписывать.

Ещё раз обсудим зачем NOC нужен.

Сбор конфигов. Не просто сбор, а по версиям. Можно сравнивать версии, понимать что изменилось и как повлияло.
Учёт оборудования по локациям. Есть NetBox, но это не то. NetBox по сути бухгалтерская книга. Неудобная, скудная, нечитаемая. В NOC ты заходишь в запись устройства и получаешь овердофига информации.
Карта сети (сегмента). Живая карта. В отличии от нарисованной в Visio. Если повезёт, то железки на карте сами слинкуются. А вот в Visio карта всегда не соответствует. Сколько ты её ни правь, она постоянно устаревает. Иногда ты сидишь день, всё выправил, интерфейсы подписал, на следующий день уже изменения.
Массовое накатывание команд. Выбрал пару десятков устройств, забил команды, 10-20 секунд и команды применились. Самое полезное средство чтобы причёсывать и вычищать конфиги устройств. С удобством, с комфортом. Приводя их к стандарту (свой стандарт ессно должен быть в каждой компании).
Поиск линка в MacDB. Такое действо нужно каждый день или даже несколько раз в день. Вместо того чтобы искать линк в консолях нескольких устройств, всё делается за пару секунд. Если удастся правильно настроить сбор MACs с линков.

Ты действительно инженер и работаешь с крупными сетями? Тогда такой инструмент как NOC (или подобный) тебе необходим. Дружу с NOC с 2017 года, мнение своё не поменял.

Теперь о грустном. Пусть простят меня разрабы (если прочитают). Факт есть факт. Ничего более глючного чем NOC, я не встречал. Всё тут криво-косо. И если у тебя сегодня хоть что-то работает в NOC, завтра вполне вероятно перестанет без видимых причин. Опять же за 5 лет ровно ничего не изменилось. Казалось бы отладьте базовый функционал, да? Нет, мы будем внедрять такую новую функцию, мы будем переводить NOC вот на то, потом на это. В результате всё ломается. Поэтому самое первое и важное правило:

Делайте резервную копию (или хотя бы snapshot) стабильного состояния VM ноды. Иначе придётся горько разочароваться.

Браузер

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

Consul

Работоспособность ноды можно отслеживать в Consul по урлу http://node_ip:8500. Сразу видно какие сервисы работают.

Может ещё для чего-то можно использовать (скорее всего), но я к сожалению не владею такой инфой.

Выгрузка баз

Сначала выгрузим Postgre, почитать:

# mkdir /opt/noc/postgredump
# chown -R postgres:postgres /opt/noc/postgredump
# sudo su - postgres
-bash-4.2$ pg_dump noc | gzip > /opt/noc/postgredump/noc.dump.gz
-bash-4.2$ exit

Когда делал, получил следующее:

pg_dump: server version: 14.7; pg_dump version: 9.2.24
pg_dump: aborting because of server version mismatch

Исправляем:

# sudo -s
# find / -name pg_dump -type f 2>/dev/null
/usr/bin/pg_dump
/usr/pgsql-14/bin/pg_dump

# sudo ln -s /usr/pgsql-14/bin/pg_dump /usr/bin/pg_dump --force

Затем Mongo, почитать тут:

# mongodump -u noc -p пароль --db noc --out /opt/noc/mongodump/

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

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

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

Вот так выглядит сейчас основное окно NOC. Есть подсказки при наведении на элементы как меню, так и форм для заполнения. Не везде, но там где они есть — полезно читать. Пока поправил досюда.

Users

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

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

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

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

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

Есть нюансы:

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

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

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

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

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

На мой взгляд сообщения из 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 (действие по умолчанию, не применять авто сегментацию):

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

Service activation

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

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

SA - Get Now

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

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

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

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

SA - MO

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

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

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

Важный момент: для устройства всегда есть 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

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.

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

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

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

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

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

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

Создание Object profile

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

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

Выбрать 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 — как раз то самое цифровое значение.

Таким образом можно удалять объект МО либо пользователя. Один раз получилось так, что сам объект удалился, а связанные с ним данные из базы 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), остальные не знаю:

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

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

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

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

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

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

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

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

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

Важный момент: если всё же сбор метрик не работает, нужно указать адрес именно как localhost, а не IP. Статья в помощь.

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

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 устройстве — на остальных результат аналогичен (на самом деле при разных версиях прошивки устройств некоторых вендоров (Qtech, Arlan, ..), как оказалась, результат очень даже может отличаться).

В последнее время всё чаще используем массовое выполнение на 100-200-400 устройствах. Где-то пара устройств на сотню отрабатывает с ошибкой "Нет активных сервисов SAE". Увеличил количество сервисов SAE с 4 до 6. Релиз 19.1.

SA - Reports

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

Inventory

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

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

Network map

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

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

и ещё:

Отображение устройств по имени/по IP;
Отображение загрузки линков;
Расчёт 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, выбрав устройство:

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

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

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

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

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

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

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

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()

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

Таким образом можно связать 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 и этот непорядок сразу бросался в глаза на карте сегмента.

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, тут сводная информация по количеству алармов/эвентов.

IPAM

IPAM работает, настройка следующая:

IPAM - Setup - Prefix Profile, создаём новый профиль префикса;

IPAM - Assigned Addresses, назначить этот профиль в префикс;

Service Activation - Setup - Managed Object Profiles, для выбранных профилей оборудования (или для всех) на закладке Box discovery включить сбор;

Теперь в логах Box для выбранного оборудования можно увидеть, что адреса собираются:

По мере отработки Box на устройствах, страница Assigned Addresses в IPAM будет заполняться:

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

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

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

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

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

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

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

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

Поискать ошибку на канале Telegram, возможно она уже обсуждалась;
Поискать на баг-трекере;
Ничего не найдено — выложить на баг-трекер и задать вопрос на канале 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
...
[root@node1 noc]# ./noc fix apply fix_rebuild_datastream

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

Доработка возможна, если в башне выбран ENV Develop или Evaluation, при ENV Productive какие-либо доработки невозможны.

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

А что делать когда нет подходящего профиля SA, а устройство нужное и важное?

Добавить новый вопрос с хотелкой на GitLab и ждать;
Попробовать самому разработать отдельный профиль для этой железки и наполнить его рабочими скриптами.

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

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

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

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

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

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

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

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

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

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

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

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, то скрипт исчезнет из веба. Скрипт может быть нерабочим, но синтаксически он должен быть составлен правильно.

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

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

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

Восстановление оригинальных файлов

Как понимаю, оригинальность файлов проверяется по их хешу.

Никто не мешает скопировать оригинальные файлы перед началом правки;
Если копий оригинальных файлов нет, то восстанавливаем их.

Как это сделать. Удаляем из профиля правленные файлы (предварительно сохранив где-то), далее: git stash и деплой. Сразу после начала деплоя все оригинальные версии будут на своих местах. Сохраняем их. После окончания деплоя git pop, оригинальные версии правленых фалов исчезнут, закидываем снова оригинальные файлы из сохранения и git add -A. Всё готово.

Полезное

Просмотр 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

NOC

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

vi /opt/noc/etc/noc.yml

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
...

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

Соответственно перезапускать можно каждый конкретный инстанс или инстансы данного вида скопом:

[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:

[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, которую удалось изучить мне.