1 ОБЩИЕ СВЕДЕНИЯ#

1.1 Наименование программы#

Полное наименование: Система мониторинга ПАК семейства Скала^р: ПО «Скала^р Визион».

Краткое наименование: Визион.

1.2 Область применения#

Основным назначением ПО «Скала^р Визион» (далее Визион) является предоставление возможности контроля жизненного цикла ПАК (машин) производства Скала^р, обслуживаемых персоналом, к квалификации которого не предъявляется серьезных требований. Осуществляется процесс мониторинга программных компонентов ПАК, сбор информации о количестве и составе управляемых объектов, метрик. Обеспечивает оповещение о событиях при сбое работы объектов мониторинга.

1.3 Уровень подготовки администратора#

Администратор должен обладать следующими навыками:

- установка, настройка системного программного обеспечения в ОС Linux;

- просмотр и редактирование файлов с использованием команд ls, cat, less, vim, nano.

1.4 Системные требования#

Примечание:

Основной потребитель ресурсов на стороне сервера Визиона - VictoriaMetrics

Оценка требований к ресурсам (при периоде извлечения данных каждые 15 секунд для всех временных рядов):

• 1 ГБ ОЗУ на 1 млн активных временных рядов;
• ядро ЦП на каждые 300 тыс. вставленных точек данных в секунду;
• менее байта на точку данных (среднем 0.2-0.5 Б/точка);
• входящий трафик 100 байт на каждую принятую точку данных;
• на долю служебных метрик самого мониторинга приходится около 7 тыс. временных рядов.

На примере S3: на не нагруженном стенде из 4 узлов хранения и 2 балансировщиков, получается порядка 30 тыс. активных временных рядов, что примерно соответствует 120 Кб на одну точку времени или 700 Мб в день при периоде извлечения данных каждые 15 секунд для всех временных рядов.

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

2 СОСТАВ КОМПОНЕНТОВ#

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

- Визион.Сервер - предоставляет функционал единой точки доступа к управлению мониторингом; устанавливается в одном экземпляре на контур (совокупность ПАК);

- Визион.Прокси - промежуточное звено, аккумулирует метрики с узлов ПАК; устанавливается по одному на каждый ПАК, возможно совмещение с сервером Визиона при использовании единой точки Визиона в каждом ПАК (Машине);

- Визион.Агент - агент мониторинга, обеспечивающий сбор данных с узла; устанавливается на узел ПАК или на виртуальную машину

- Агент Платформы - сервис, позволяющий серверу Визиона конфигурировать агенты мониторинга по HTTPS. Агент необходимо развернуть на все узлы, на которые, впоследствии, будут установлены агенты мониторинга.

Все компоненты должны находится в одной сети.

Оптимальным решением является выделение под Визион.Сервер и Визион.Прокси отдельных виртуальных серверов в рамках узлов управления Машин.

Архитектурная схема

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

2.1 Визион.Сервер#

В состав Визион.Сервера входят следующие компоненты:

• Визион backend - бекенд, обеспечивающий API и осуществляющий управление и координацию всех сервисов;
• PostgreSQL - служебная база данных;
• VictoriaMetrics - база данных временных рядов для хранения метрик;
• VMAlert - компонент, предназначенный для генерации оповещений на основе данных в Victoriametrics и правил алертинга (триггеров);
• AlertCollector - компонент, регистрирующий оповещения в служебную БД;
• IAMSyncer - iamsyncer, компонент для синхронизации данных о ролях и пользователях между IAM и vision-core;
• Grafana backend - компонент, обеспечивающий альтернативную визуализацию собираемых метрик;
• AlertManager - компонент, обеспечивающий обработку, группировку и отправку оповещений (поддерживает SMTP и веб-хуки);
• SNMP Notifier - вспомогательный компонент, предназначенный для отправки оповещений с помощью протокола SNMP (Simple Network Management Protocol);
• TaskDaemon - компонент, отвечающий за выполнение фоновых задач (например, развертывание агентов и их плагинов);
• Nginx - прокси-сервер, обеспечивающий получение и перенаправление запросов на компоненты Визион.Сервера;
• Utilizer - компонент, осуществляющий расчет утилизации CPU/RAM/ROM на основе данных от node_exporter.

2.2 Визион.Прокси#

В состав Визион.Прокси входит единственный компонент - VMagent, обеспечивающий перенаправление поступающих метрик в Визион.Сервер.

2.3 Визион.Агент#

В состав Визион.Агента входят следующие компоненты:

- VMagent - компонент, обеспечивающий сбор метрик с плагинов

- Плагины - дополнительно устанавливаемые модули (экспортеры и параметры скрепинга метрик), расширяющие состав, собираемых системой мониторинга, метрик.

2.4 Агент Платформы#

Агент Платформы представлен единственным компонентом - PLagent.

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

В данные момент установка возможна на следующих ОС:

• Alt Linux Server 8 СП p9 (c9f2)
• Alt Linux Server 8 СП p10 (c10f1)
• Astra Linux 1.7.3 (Воронеж)
• РЕДОС 7.3

На целевых системах должны присутствовать следующие пакеты:

• freeipmi (если предполагается присутствие плагина ipmi на узле, как правило, это ВМ Визиона на служебном узле)
• lsblk (для плагина utlz_exporter, необходима поддержка ключей -o и -J)
• sudo (> 1.6.9p15)

Перед началом развертывания агентов необходимо обеспечить сетевую связность между узлами и доступность серверов с хоста Визиона, а также наличие доступа к ним по протоколу SSH (порт 22).

2.5 Состав сервисов#

2.6 Плагины#

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

Каждому плагину соответствует свой тип объекта мониторинга, с которого извлекается соответствующее ему множество метрик.

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

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

В случае, если плагин не использует экспортер, он является плагином-скреппером, сбор метрик осуществляется непосредственно с эндпоинта объекта мониторинга.

В состав Визиона входят следующие плагины:

^1 utlz_exporter_v0 по умолчанию нет необходимости устанавливать, только по запросу. Для работы ему требуется дополнительный файл конфигурации, который доставляется на хосты с помощью плейбука playbooks/utlz_v0_config.yml.

^2 На агенты каких серверов или ВМ рекомендуется добавлять плагины.

^3 Порт, занимаемый экспортером по умолчанию. Порты конфигурируются в настройках плагина в интерфейсе Визиона.

2.6.1 Версионирование ПО плагинов#

3 УСТАНОВКА ПРОГРАММЫ#

Перед началом установки необходимо убедиться в доступности узлов ПАК с хоста Визиона. Проверить доступность можно при помощи команды ping.

Если в выводе команды ping содержатся ошибки, необходимо убедиться в том, что в инсталляционной карте содержатся корректные данные, обеспечена сетевая связность между узлами и файрвол не блокирует доступ по протоколу SSH (порт 22).

В приведенных в данном руководстве примерах команд в качестве интерпретатора команд терминала используется Bash.

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

В данном руководстве приводятся примеры команд для версии Визиона 1.4 Номер версии используется в имени файла с архивом дистрибутива, например vision-distrib-<version>.gz.

На момент выполнения установки или обновления “Визиона” пользователем, версия может отличаться.

Актуальную инструкцию для сборки можно посмотреть в файле README.MD в архиве дистрибутива.

Алгоритм установки компонентов Визиона и его настройки:

1. Установка Визион.Сервер
2. Конфигурация объектов мониторинга
3. Формирование инвентори-файла
4. Установка агентов Платформы
5. Настройка плагинов

Зависимости:

- ansible >= 2.9

- sshpass

- nginx

- postgresql = 11|12

Данные пакеты и их зависимости будут установлены или обновлены при развертывании с помощью плейбуков ansible. При невозможности их автоматической установки требуется вручную установить данные пакеты. Все необходимые зависимости включены в состав дистрибутива для возможности установки Визиона без подключения к глобальной сети Internet.

3.1 Установка Визион.Сервер в интерактивном режиме#

Дистрибутив Визиона представляет собой tar.gz архив. Далее описана работа с дистрибутивом.

Для установки Визиона в состав дистрибутива входит скрипт установки setup.sh. Установка должна выполнятся на целевом узле (либо виртуальной машине) и требует привилегий суперпользователя.

1. Открыть терминал и перейти в директорию с архивом дистрибутива, например, /root:

cd /root

2. Распаковать архив с дистрибутивом `.tar.gz``, например:

tar -xzvf vision-distrib-1.4-289.tar.gz

3. Перейти в директорию дистрибутива, например:

`сd /root/vision-distrib-1.4-289

4. Запустить скрипт:

./setup.sh

5. Выбрать одно из действий:

   • 3. Установить пакеты зависимостей из репозитория дистрибутива в случае отсутствия пакетов в системном репозитории ОС;
   • 4. Установить пакеты зависимостей из репозитория OC.

Будут установлены все пакеты зависимостей для соответствующих операционных систем. Так же для запуска этой операции можно вызвать команду ./setup.sh -g (./setup.sh -p в случае отсутствия пакетов в системном репозитории ОС).

При невозможности автоматической установки пакетов, требуется вручную установить пакеты из списка, содержащегося в файле ./os_packages/<YOUR_OS>/package_list (см. документацию на операционную систему).

По окончанию установки пакетов ее лог будет сохранен в файл:

/opt/skala-r/var/log/vision/vision_packages.log.<ДАТА_УСТАНОВКИ>.

6. Запустить скрипт ``./setup.sh` и выбрать действие “1. Установить сервер Визиона.”.

Будут установлены все необходимые компоненты, запущены требуемые сервисы. Так же для запуска этой операции можно вызвать команду ./setup.sh -i

В процессе установки будет предложено выбрать IP-адрес, на который в последствии будут отправляться метрики с агентов мониторинга. Как правило, он соответствует IP-адресу компонента Визион.Сервер в сети, в которой находятся все компоненты мониторинга (менеджмент-сеть).

7. Запустить скрипт ./setup.sh и выбрать действие 5. Импортировать данные для конкретного заказчика.

Выбрать текущего заказчика/проект для которого устанавливается Визион. Если заказчика нет в списке, пункт можно пропустить.

По окончанию установки лог, сформированный в процессе инсталляции, будет сохранен в файл:

/opt/skala-r/var/log/vision/vision_install.log.<ДАТА_УСТАНОВКИ>

3.2 Установка Визион.Сервер в автоматическом режиме#

Поддерживается автоматическая установка с передачей IP-адреса, на который в последствии будут отправляться метрики с агентов мониторинга. Как правило, он соответствует IP-адресу сервера Визиона в сети, в которой находятся все компоненты мониторинга (менеджмент-сеть).

Установка должна выполнятся на целевом сервере (виртуальной машине).

Требования при установке:

• наличие привилегии суперпользователя;

• наличие необходимых пакетов в системном репозитории ОС.

1. Открыть терминал и перейти в директорию с архивом дистрибутива, например:

sh cd /root

2. Распаковать архив с дистрибутивом, например:

sh tar -xzvf vision-distrib-<version>.tar.gz

3. Перейти в директорию дистрибутива, например:

sh сd /root/vision-distrib-<version>

4. Запустить скрипт ./setup.sh с ключом -s, указав IP-адрес сервера Визиона, например:

sh ./setup.sh -s 192.168.1.1

Автоматически будут установлены пакеты зависимостей из системного репозитория ОС и непосредственно сервер Визиона (аналогично п.3.1).

3.3 Проверка корректности установки Визион.Сервер#

Для проверки корректности установки:

Запустите скрипт ./setup.sh из директории с дистрибутивом и выберите действие 6. Проверка работы сервисов.

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

cd /opt/skala-r/vision
./check_service.sh

Критерием корректности развертывания является значение active для всех сервисов, приведенных в таблице в выводе скрипта check_service.sh.

Сервис vision_iamsyncer не запускается автоматически после установки Визион. Подробнее в инструкции

По завершении процесса установки должен быть доступен веб-интерфейс Визиона через браузер по его IP-адресу https://<vision-ip>.

3.4 Просмотр логов компонента#

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

journalctl -u <имя сервиса> --since "начало интервала YYYY-MM-DD hh:mm:ss" --until "конец интервала YYYY-MM-DD hh:mm:ss"

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

journalctl -fu <имя сервиса>

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

journalctl -u <имя сервиса> --since "начало интервала YYYY-MM-DD hh:mm:ss" --until "конец интервала YYYY-MM-DD hh:mm:ss"

Например:

journalctl -u vision_core --since "2024-04-26 11:05:00" --until "2024-04-26 11:10:00"

3.5 Просмотр журналов Визион.Сервер#

Журнал Визион.Сервера размещаются в директории /opt/skala-r/var/log/vision/journal, а журнал аудита - в /opt/skala-r/var/log/vision/audit.

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

sh tail -n 20 /opt/skala-r/var/log/vision/journal/journal.log tail -n 20 /opt/skala-r/var/log/vision/audit/audit.log

3.6 Резервное копирование ВМ Визион#

Инструкция по резервному копированию и восстановлению работоспособности ВМ Визион находится в разделе “Дополнительная документация”.

4 КОНФИГУРАЦИЯ ОБЪЕКТОВ МОНИТОРИНГА#

После развертывания Визион.Сервер, необходимо ввести информацию об объектах мониторинга в систему. В консоли администратора мониторинга предусмотрен пользовательский интерфейс для настройки объектов. Алгоритм настройки выглядит следующим образом:

1. Перейти в веб-интерфейс Визиона, открыв Интернет-браузер, ввести в строке для адреса IP-адрес сервера Визиона https://<vision-ip>.
2. Перейти в раздел в боковом меню “Параметры” -> “Объекты”, в панели “Контуры” нажать кнопку ⠇ , выбрать “Добавить ПАК”. Ввести информацию о ПАК.
3. В случае отсутствия на добавляемом ПАК агентов Платформы, необходимо его развернуть в соответствии с разделом 6 настоящего Руководства.
4. Перейти во вкладку “Агенты” и нажать кнопку “Сконфигурировать агенты”.
5. Нажать на иконку 🖉 и включить необходимые плагины.
6. Перейти в пункт меню “Конструктор выражений”, ввести выражение up{_pak_id="<ИМЯ_ПАК>"} и проверить, что работают все сконфигурированные плагины (в наличии временные ряды с именем метки “job” и значениями имен агентов).

4.1 Подготовка к настройке#

Перед настройкой требуется убедиться, что имеется инсталляционная карта с соответствующим описанием ПАК, либо все необходимые параметры и доступы для постановки объектов на мониторинг.

Перейти в веб-интерфейс Визиона, открыв Интернет браузер, и введя в строке адреса IP-адрес сервера Визиона, например, https://<vision-ip>.

Добавить новый ПАК: раздел в боковом меню “Параметры”->“Объекты”, в панели “Контур” нажать кнопку ⠇ и выбрать “Добавить ПАК”.

Откроется форма «Добавление ПАК». Пример интерфейса:

Требуется ввести данные во все разделы (в соответствии с инсталляционной картой) и нажать кнопку “Добавить” внизу экрана, чтобы сохранить введенную конфигурацию. В случае, если обязательные поля остались незаполненными, то при попытке сохранить они будут подсвечены цветной рамкой и соответствующим текстом и данные не будут сохранены до тех пор пока все обязательные поля не будут заполнены. Также поля будут подсвечены в случае ввода значений, которые уже используются в других ПАК, и сохранение таких данных будет невозможно.

При заполнении формы для добавления и удаления строк используются элементы управления:

При нажатии кнопки “Отменить” сохранение будет отменено и введенные данные потеряны.

Возможен альтернативный ввод параметров через импорт CSV файла. Для этого используются элементы управления:

Необходимо экспортировать настройки в CSV файл, изменить их и импортировать измененный файл.

Описание полей формы приведено в разделах ниже.

4.1.1 Описание функций импорта и экспорта настроек в csv-файл#

В режиме создания/редактирования ПАКа имеется возможность импорта/экспорта настроек ПАКа.

В поле изменения компонентов (модули, серверы, ВМ, коммутаторы и т.д.) ПАКа имеются кнопки

При нажатии кнопки импорта появляется окно файлового менеджера, в котором требуется выбрать csv-файл с настройками компонента ПАКа.

Примечание: импорт осуществляется в режиме дозаписи настроек.

При нажатии кнопки экспорта осуществляется скачивание csv-файла в выбранную папку. При этом csv-файл имеет имя аналогичное имени ПАКа в формате PAK_<имя_ПАКа>. Скачанный csv-файл содержит текущие настройки компонента ПАКа.

4.2 Заполнение формы «Добавление ПАК»#

4.2.1 ПАК#

• «Имя» - ввести идентификатор ПАК (в дальнейшем изменить невозможно без реинсталляции)
• «Тип» - выбрать из справочника тип ПАК в соответствии с поставкой
• «Описание» – ввести произвольный вспомогательный текст

4.2.2 Модуль#

Заполнение информации о модулях. Тип модуля берется из инсталляционной карты. Список меняется в зависимости от предварительно выбранного типа ПАК.

• «Имя» - идентификатор модуля (в дальнейшем изменить невозможно без реинсталляции)
• «Тип» – тип модуля, в соответствие с типом ПАК. Требуется выбрать из списка
• «Описание» – ввести произвольный вспомогательный текст

4.2.3 Сервер#

Требуется ввести информацию об узлах.

• «Имя» - идентификатор сервера (в дальнейшем изменить невозможно без реинсталляции)
• «Модуль» – выбрать из заведенных ранее в пункте Модуль
• «Тип» – выбрать из справочника
• «Адрес» – адрес, по которому будет установлен агент
• «Адрес BMC» – адрес, по которому будут производить опрос агенты мониторинга, расположенные на Визион.Прокси

4.2.4 ВМ#

Требуется ввести информацию о виртуальных машинах, в том числе сервисных (Визиона, Генома и т.д.).

• «Имя» - идентификатор ВМ (в дальнейшем изменить невозможно без реинсталляции)
• «Сервер» – принадлежность ВМ к физическому узлу (серверу)
• «Адрес» – адрес ВМ в соответствии с инсталляционной картой

4.2.5 Коммутатор#

Требуется ввести информацию о коммутаторах из инсталляционной карты.

• «Имя» - идентификатор коммутатора (в дальнейшем изменить невозможно без реинсталляции);
• «Модуль» – принадлежность к модулю, выбрать из заведенных ранее
• «Тип» – тип целевого назначения коммутатора
• «Адрес» – адрес коммутатора.

4.3 Редактирование ПАК#

Редактировать ПАК: раздел в боковом меню для ПАК нажать кнопку ⠇ и выбрать “Редактировать”.

Форма редактирования ПАК:

В форме редактирования ПАК используются те же элементы что и в форме добавления ПАК, но нет возможности изменять имена объектов.

4.4 Дублирование ПАК#

В случае, если требуется создать структуру ПАК, аналогичную уже существующему ПАК, можно воспользоваться функцией дублирования.

Дублировать ПАК: раздел в боковом меню для ПАК нажать кнопку ⠇ и выбрать “Дублировать”.

Форма выглядит как при добавлении ПАК, но все объекты уже созданы и остается изменить их имена и заполнить поля:

Возможно также удалять и добавлять объекты при необходимости.

5 ФОРМИРОВАНИЕ ИНВЕНТОРИ-ФАЙЛА#

Для проведения сервисных операций с узлами ПАК может потребоваться так называемый инвентори-файл, описывающий перечень узлов и их технические учетные записи (ТУЗ). С использованием Ansible производится автоматизация управления конфигурациями и выполнение задач на этих узлах.

Данный файл может быть получен из веб-интерфейса Визиона для уже добавленных ПАК.

В этом случае достаточно выбрать необходимый ПАК, нажать ⠇, пункт “Инвентори”. Файл-инвентори скачается, и так же будет доступен в директории /opt/skala-r/vision/server/inventory/. Имя файла состоит из имени ПАК и даты экспорта, например, PAK-1_2024-06-10_10-10-10.yml.

6 УСТАНОВКА АГЕНТОВ ПЛАТФОРМЫ#

1. Сформировать инвентори файл для ПАК (см. п.5)

2. Перейти в директорию дистрибутива:

сd /root/vision-distrib-<version>

3. При необходимости, сконфигурировать установку агента Платформы при помощи файла ./plagent/_plagent_settings.yml

4. Запустить установщик setup.sh и выбрать пункт 7. Установка plagent:

./setup.sh

5. Выбрать номер сформированного инвентори из пункта 1.

6. При необходимости, отредактировать инвентори, введя y (если не нужно, то n). Указать текстовый редактор для запуска (по умолчанию nano).

В инвентори заменить значения ===REPLACE=== для следующих ключей: - Учетная запись для подключения к узлам по SSH - ansible_user - ansible_ssh_pass - Учетная запись под которой выполняется плейбук - ansible_become_user - обычно root - ansible_become_password - обычно аналогичное значение ansible_ssh_pass - Ключ vars:` содержит глобальные параметры. Если у части узлов учетные данные отличаются, вы можете указать аналогичные ключи к конкретным узлам, таким образом переопределив значения глобальных.

Сохранить файл.

7. По завершению установки удалить заполненный инвентори.

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

Так же в рамках автоматизации работы с агентами Платформы доступны некоторые сервисные команды.

Общий вид команд для их запуска:

ansible-playbook -i <INVENTORY_PATH> <PLAYBOOK>
ansible-playbook -i <INVENTORY_PATH> -l <HOST> <PLAYBOOK>

где

• <INVENTORY_PATH> - путь до итогового файла инвентори;
• <PLAYBOOK> - выполняемое действие:
  • ./plagent/install.yml - установить агенты Платформы;
  • ./plagent/status.yml - вывести статус агентов Платформы;
  • ./plagent/stop.yml - остановить агенты Платформы;
  • ./plagent/start.yml - запустить агенты Платформы;
  • ./plagent/remove.yml - удалить агенты Платформы;
• <HOST> - имя сервера(ов) из инвентори, для которых необходимо выполнить команду, например server1.

7 НАСТРОЙКА АГЕНТОВ И УСТАНОВКА ВИЗИОН.ПРОКСИ#

7.1 Конфигурирование агентов#

Последовательность действий:

1. Перейти во вкладку “Агенты” и нажать кнопку “Сконфигурировать агенты”.

Откроется форма настроек.

2. В настройках указать:

• Расположение прокси-сервера Визиона. На выбранный узел будет установлен компонент Прокси-сервер Визиона, а также на нем требуется сконфигурировать плагины, которые обозначены типом «ВМ с прокси» в пункте 2.6 данного руководства.

• Расположение агентов: по умолчанию, в форме отобразятся все серверы и ВМ, которые были ранее указаны в списке объектов. Для корректного расположения, на серверах должны быть предварительно установлены агенты Платформы.

• Плагины – состав конфигурационных файлов, содержащих в себе инструкции для настройки агентов и расстановки экспортеров. На данном шаге необходимо выбрать Плагины в соответствие с типом узла. Для узла, который будет выбран как Прокси, требуется выбрать плагины, реализующие сбор метрик снаружи относительно объекта мониторинга. Рекомендуется расставлять плагины по таблице применимости, указанной в разделе 2.6 данного руководства.

  Если в столбце Сервер/ВМ указано «ВМ с прокси» - плагин рекомендуется разместить на ВМ, выбранную Прокси. Остальные плагины конфигурируются на усмотрение пользователя, в зависимости от расположения сервисов на узлах.

После расстановки всех агентов и нажатия кнопки «Сохранить», поменяются статусы агентов. В случае успеха будет указан статус «Установлен». Если агент не будет настроен, отобразится статус Ошибка. Требуется проверить логи и сетевую связность между компонентами, а также наличие агента Платформы на всех узлах, за которыми требуется осуществлять мониторинг.

7.2 Конфигурирование плагинов#

Для конфигурирования плагинов необходимо перейти в раздел “Объекты” - на вкладку «Плагины»

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

Часть плагинов используют настройки, которые были заданы при развертывании Визиона. Для тех, которые не получат доступ к данным, будет выведен статус “Ошибка”. Требуется осуществить настройки.

Перед добавлением убедиться, что при установке плагина его порт не конфликтует с другим ПО.

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

Для проверки корректности настроек, перейдите в пункт меню “Конструктор выражений”, введите выражение up{_pak_id="<ИМЯ_ПАК>"} и проверьте что работают все сконфигурированные плагины (в наличии временные ряды с именем метки “job” и значениями имен плагинов).

Параметры всех плагинов приведены в документе .

Далее будут приведены особенности конфигурации некоторых плагинов.

7.2.1 vision_exporter#

Плагин предназначен для сбора метрик о состоянии сервисов ОС, пользовательских сессиях, некоторой информации S.M.A.R.T, состоянии БД Greenplum, а также о состоянии дисковых массивов, организованных с помощью ПО RAIDIX ERA и лицензиях на ПО RAIDIX ERA.

В поле Enabled Modules нужно включить модули:

• smart, session, services - для мониторинга МХД.О
• eraraid - для мониторинга конфигураций, включающих программный модуль RAIDIX ERA
• greenplum - для мониторинга состояния БД Greenplum

Для получения метрик eraraid в МХД.О/МБД.П нужно включить одноименный модуль в поле Enabled Modules.

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

services:
  SERVICENAME.service:                   # имя сервиса
    monitor_service: [true|false]        # Мониторинг uptime и active сервиса (обязательный параметр, для firewalld указать false) 
    monitor_port: PORT                   # Мониторинг порта сервиса
    monitor_specific_config: firewalld   # Мониторинг конфигурации заранее заданным способом (указывать только для firewalld)

Для МХД.О (S3) рекомендуется следующая конфигурация:

• узел балансировки

services:
  firewalld:
    monitor_service: false
    monitor_specific_config: firewalld

  nginx.service:
    monitor_service: true
    monitor_port: 6006

  haproxy.service:
    monitor_service: true
    monitor_port: 80

  postgresql.service:
    monitor_service: true
    monitor_port: 5432

  s3gateway-compression-server.service:
    monitor_service: true
    monitor_port: 5001

  s3gateway-control-server.service:
    monitor_service: true
    monitor_port: 3000

  s3gateway-proxy-server.service:
    monitor_service: true
    monitor_port: 4000

• узел хранения

services:
  nginx.service:
    monitor_service: true
    monitor_port: 80

  s3gateway-ostor-server.service:
    monitor_service: true
    monitor_port: 5002

  vstorage-csd.target:
    monitor_service: true

  vstorage-mdsd.target:
    monitor_service: true

  ostor-cfgd.service:
    monitor_service: true

  ostor-agentd.service:
    monitor_service: true

При необходимости скорректировать состав и параметры сервисов, проверьте порты работы указанных сервисов.

7.2.2 nginx_exporter#

Плагин предназначен для локального сбора метрик c Nginx. На данный момент используется для мониторинга компонентов МХД.О.

Плагин представляет собой экспортер, который получает состояние Nginx с помощью модуля http_stub_status_module и преобразует в метрики.

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

1. Выполните на узле кластера S3 команду nginx -V 2>&1| grep -o http_stub_status_module и убедитесь, что Nginx собран с модулем http_stub_status_module.
2. В файле конфигурации Nginx (по умолчанию, /etc/nginx/nginx.conf) в блоке server должен присутствовать следующий роут:

location = /nginx_status {
    stub_status;
}

В интерфейсе Визиона укажите эндпоинт в конфигурации плагина в поле Nginx Scrape Uri. Например, http://127.0.0.1:88/nginx_status.

7.2.3 haproxy_scraper_local#

Плагин предназначен для локального сбора метрик c HAProxy. На данный момент компонент используется в МХД.О на узлах балансировки.

Перед настройкой плагина вы можете убедиться, что HAProxy скомпилирован с Prometheus Exporter с помощью команды haproxy -vv. В выводе вы должны увидеть Built with the Prometheus exporter as a service.

При наличии модуля предоставления метрик необходимо, чтобы включить его в файле конфигурации HAProxy (по умолчанию: /etc/haproxy/haproxy.cfg).

Пример раздела frontend:

frontend prometheus
   bind :8008
   mode http
   http-request use-service prometheus-exporter
   no log

В интерфейсе Визиона укажите адрес HAProxy в конфигурации плагина в разделе Таргеты в параметре Адрес. Например, 127.0.0.1:8008, в случае установки плагина локально и предоставления метрик по порту :8008.

7.2.4 s3gateway_ostor_server_scraper#

Плагин предназначен для локального сбора метрик c s3gateway_ostor_server. На данный момент компонент используется в МХД.О на узлах хранения.

В s3gateway_ostor_server присутствует встроенная поддержка предоставления метрик.

В интерфейсе Визиона укажите адрес s3gateway_ostor_server в конфигурации плагина в разделе Таргеты в параметре Адрес. Например, 127.0.0.1:7002, в случае установки плагина локально и предоставления метрик по порту :7002.

7.2.5 s3gateway_compression_server_scraper#

Плагин предназначен для локального сбора метрик c s3gateway_compression_server (компонент используется в МХД.О на узлах балансировки).

В s3gateway_compression_server присутствует встроенная поддержка предоставления метрик.

В интерфейсе Визиона укажите адрес s3gateway_compression_server в конфигурации плагина в разделе Таргеты в параметре Адрес. Например, 127.0.0.1:7001, в случае установки плагина локально и предоставления метрик по порту :7001.

7.2.6 node_exporter#

Особое внимание обращать на машине МВ.ДИ на конфликт портов с другим ПО.

7.2.7 bash_exporter#

Внимание! Плагин bash_exporter устанавливается отдельно от основного дистрибутива Визиона.

Необходимо в настройках плагина указать путь к bash скрипту:

На файл скрипта необходимо назначить права на исполнение для пользователя vision.

В процессе исполнения скрипт должен отдавать значения метрик в формате prometheus.

Примечание: bash_exporter выполняет скрипты из-под отдельного пользователя vision_bash_exporter

7.2.8 systemd_exporter#

Необходимо в настройках плагина указать сервисы, которые необходимо включить в сбор метрик (include units) либо исключить (exclude units): Если поле include units не заполнено и поле exclude units также не заполнено, то это означает, что будут собираться метрики по всем сервисам.

7.2.9 kafka_exporter#

Плагин обладает множественными настройками:

Описание настроек:

7.2.10 process_exporter#

Плагин обладает возможностью конфигурации:

Параметры конфигурации плагина:

• children (по умолчанию: true) - обеспечивает, что любой процесс, который иначе не принадлежал бы к своей собственной группе, присоединяется к первой найденной группе (если такая существует) при перемещении вверх по дереву процессов.
• threads (по умолчанию: true) - показатели будут разбиты по названию потока, а также по названию группы.
• recheck (по умолчанию: false) - пересмотр имен процессов при каждом сборе метрик, так как процессы могут изменять свои имена, это может привести к тому, что процесс попадет не в ту группу, если мы впервые увидим его до того, как он получит свое собственное имя.
• recheck duration (по умолчанию: 0) - включить проверку имен процессов только на определенный период после запуска плагина. Отключает постоянную проверку recheck

Для настройки мониторинга процессов в форме конфигурации плагина в поле Plugin Configuration вы можете добавить конфигурацию в формате yaml (пустое поле конфигурации заменится стандартной конфигурацией по умолчанию):

process_names:  
  - name: "{{.Comm}}"
    cmdline:
    - '.+'

другой пример конфигурации:

process_names:
  - comm:
    - chromium-browse
    - bash
    - prometheus
    - gvim
  - exe:
    - /sbin/upstart
    cmdline:
    - --user
    name: upstart:-user

7.2.11 sql_exporter#

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

7.2.12 blackbox_exporter#

Плагин устанавливает экспортер и создаёт задачу сбора метрик с него компонентом vmagent_agent.

7.2.13 greenplum_sql_exporter#

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

7.2.14 clickhouse_sql_exporter#

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

7.2.15 picodata_scraper#

Следует указать в таргетах адрес и порт для сбора метрик Picodata.

7.2.16 graphite_exporter#

Плагин устанавливает экспортер и создаёт задачу сбора метрик с него компонентом vmagent_agent.

Конфигурация graphite_exporter в UI Визиона осуществляется через соответствующее поле “Конфигурация дополнительного маппинга”, где задаются правила сопоставления и преобразования. Формат - YAML.

Основные параметры#

Пример правила сопоставления

Простое правило:

- match: 'servers.*.cpu.*'
  name: 'cpu_usage_$2'
  labels:
    server: '$1'
    type: '$2'

Regex:

- match: 'servers\.([^\.]+)\.disk\.([^\.]+)\.([^\.]+)'
  match_type: regex
  name: 'disk_$3'
  labels:
    server: '$1'
    device: '$2'

Конфигурирование

Присутствуют следующие строки:

match:

• Регулярное выражение для сопоставления метрик(и) Graphite.
• Используется для захвата частей метрики, которые можно использовать в name и labels. Также предназначен для оптимизации преобразования, позволяя использовать шаблоны для однотипных метрик Пример: servers..cpu. — будет сопоставлять метрики, такие как servers.web01.cpu.user или servers.db01.cpu.system.

name:

• Имя метрики в Prometheus.
• Можно использовать группы захвата из match (например, $1, $2). Пример: cpu_usage_$2: если вторая группа захвата – это user, то имя метрики будет cpu_usage_user.

labels:

• Метки, которые будут добавлены к метрике в Prometheus.
• Ключи – это имена меток, которые задаются пользователем, значения – группы захвата из match. Значение также может быть фиксированным (заданным пользователем) Пример: server: ‘$1’ — если первая группа захвата — это web01, то метка будет server=“web01”.

match_type (опционально):

• Тип сопоставления: glob (по умолчанию) или regex.
• glob — простой шаблон с использованием *, ?, […] и др.
• regex — полноценное регулярное выражение

Группы захвата:

• Группы захвата ($1, $2, и т.д.) соответствуют частям метрики, захваченным в match.
• Пример: servers..cpu.: к первой звезде относится группа захвата $1, ко второй – $2.

Способ применения

Чтобы задать маппинг, следует перечислить все необходимые преобразования в UI Визиона согласно описанному формату. Дополнительно ничего вводить не следует.

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

Применяемые шаблоны в Визионе для Kafka и Hadoop

В применяемых в Визионе шаблонах используются два подхода:

1. Динамическое формирование имён метрик
2. Явно прописанное имя Первый подход используется преимущественно для Kafka, второй - преимущественно для Hadoop. Явно прописанное имя необходимо для более удобного использования в алертинге.

Используются следующие метки:

• cluster: Имя кластера (из группы захвата ${1}).

• host: Имя хоста (из группы захвата ${2}).

• service: Тип сервиса, прописан явно (например, ReplicaManager, Broker, HDFS, Hive)

• rate - Частота, связанная с измерениями внутри метрики (OneMinuteRate, FiveMinuteRate) и др.

• collector - Коллектор метрики

7.3 Добавление и обновление плагинов#

Выполнить следующие действия на виртуальной машине сервера Визиона:

1. Распаковать архив с новым/обновленным плагином в директорию /opt/skala-r/vision, например:

tar -xzf plugin_acrhive.tar.gz -C /opt/skala-r/vision

2. Перезапустить сервис vision_core:

systemctl restart vision_core.service

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

systemctl status vision_core.service

journalctl -fu vision_core -n 20

7.4 Снятие ПАК с мониторинга (деинсталляция Визиона с узлов ПАК).#

Внимание! Данные действия необратимы. В процессе удаления будут деинсталлированы все агенты мониторинга, их плагины, а также Визион.Прокси.

Перейти в веб-интерфейс Визиона, открыв Интернет браузер, и введя в строке адреса IP-адрес сервера Визиона https://<vision-ip>.

Перейти в боковом меню в раздел “Параметры”->“Объекты”, в панели “Контур” выбрать удаляемый ПАК, нажать кнопку ⠇ и выбрать “Удалить”. Согласиться с удалением, нажав кнопку “Удалить”.

8 НАСТРОЙКА ОТПРАВКИ УВЕДОМЛЕНИЙ ПО SMTP#

Для интеграции с шлюзом SMTP, требуется осуществить настройки подключения, затем осуществить подписку пользователей на рассылку уведомлений.

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

1. Перейти в веб-интерфейс Визиона, открыв Интернет браузер, и введя в строке адреса IP-адрес сервера Визиона (https://<vision-ip>), после чего выбрать пункт “Модуль администратора”.
2. Перейти в раздел “Настройки SMTP” и заполнить все поля валидными значениями. Поле “Основной адрес получателя” заполняется адресом электронной почты, на которую будут приходить уведомления о сработанных правилах оповещения, для которых нет подписок конкретных групп рассылок. Нажмите на кнопку “Сохранить”.
3. Перейти в раздел “Список получателей” и создать получателя уведомлений с каналом E-mail и адресом электронной почты, на которую будут приходить уведомления о сработанных правилах оповещения.
4. Перейти в раздел “Группы рассылки”, создать группу, добавить в эту группу получателя. Добавить условие в этой группе: например, severity = critical.
5. Перейти в раздел “Правила оповещения”, создать новое правило с важностью critical (в целях тестирования добавить правило оповещения, которое точно сработает, пример: ввести в поле ввода PromQL выражение up == 1).
6. Перейти в раздел “Уведомления” и дождаться срабатывания правила оповещения.
7. Войти в электронную почту, указанную на шаге 3, и дождаться получения письма о сработанном правиле оповещения из шага 5.

9 НАСТРОЙКА ОТПРАВКИ УВЕДОМЛЕНИЙ ПО SNMP#

9.1 Настройка SNMP notifier#

Необходимо задать параметры отправки уведомлений мониторинга по SNMP путём POST запроса к API Визиона https://<vision_host>:8092/vision/api/v1/config/snmp_notifier_config с телом JSON со следующими полями:

Пример Curl для SNMP V3:

curl -k -X 'POST' 'https://<vision_host>:8088/vision/api/v1/config/snmp_notifier_config'   -H 'accept: application/json'   -H 'Content-Type: application/json'   -d '{
  "snmp_version": "V3",
  "snmp_destination": "127.0.0.1:162",
  "snmp_retries": 1,
  "snmp_trap_default_oid": "1.3.6.1.4.1.98789",
  "snmp_timeout_sec": 5,
  "snmp_authentication_protocol": "MD5",
  "snmp_authentication_username": "username",
  "snmp_authentication_password": "password",
  "snmp_private_protocol": "AES",
  "snmp_private_password": "password",
  "snmp_security_engine_id": "xxxxxxxxxx"
}'

9.2 Настройка перечня уведомлений, отправляемых по SNMP#

1. Перейти в веб-интерфейс Визиона, открыв Интернет браузер, и ввеcти в строке адреса IP-адрес сервера Визиона (https://<vision-ip>), после чего выбрать пункт “Модуль администратора”.
2. В боковом меню выбрать раздел “Параметры”, пункт: “Группы рассылки”.
3. Нажать кнопку “Добавить” и создать новую группу рассылки.
4. В открывшейся форме для группы рассылки заполнить параметры (в скобках – примеры заполнения):

• Имя (“Группа А”)
• Детальное описание (“Группа поддержки 1 линии”)
• Условия отправки уведомлений (
  • если необходимо получать абсолютно все уведомления по SNMP установить следующие значения:
    • Метка: “severity”;
    • Оператор: выбрать все допустимые значения
  • Получать только критические:
    • Метка: “severity”;
    • Значение: “critical”)
• Получатели (“SNMP-шлюз”)

5. Нажать кнопку “Добавить”.

10 НАСТРОЙКИ БЕЗОПАСНОСТИ#

10.1 Межкомпонентное взаимодействие#

В целях повышения безопасности работа между компонентами Визиона реализована через TLS и Basic Auth.

Настройка аутентификации и размещение сертификатов выполняется автоматически при развертывании компонентов Визиона.

Параметры технической учетной записи для авторизации между компонентами конфигурируются в файле _deploy_settings.yml, расположенном в корне дистрибутива - basic_auth_username и basic_auth_password (имя пользователя и пароль соответственно).

Описание компонентов Визион

Описание конфигурационного файла vision_core (config.yml)

Описание параметров конфигурации плагинов

Описание учетных записей Визион

11 УСТАНОВКА ОБНОВЛЕНИЙ ПРОГРАММЫ#

Для установки и для обновления “Визиона” используется один и тот же пакет установочных файлов, поставляемый в виде архива.

Обновление выполняется путем установки новой версии поверх существующей.

Обратите внимание! В данной версии обновление с сохранением файлов конфигурации (таких, как .secrets_vault, config.yml, grafana.yml) не доступно и они будут перезаписаны.

Данные базы данных временных рядов, пользовательские дашборды, а также информация о зарегистрированных ПАК, конфигурации агентов и плагинов будут сохранены.

12 УДАЛЕНИЕ ВИЗИОНА#

12.1 Удаление Визион.Сервер#

1. Открыть терминал и перейти в директорию с дистрибутивом:

сd /root/vision-distrib-<version>

2. Запустить скрипт

./setup.sh

3. Выбрать действие “2. Удалить сервер Визиона.”

Будут удалены все компоненты Визиона. При необходимости можно очистить пользовательские данные (метрики Victoriametrics, данные служебной БД Vision и данные Grafana). Так же для запуска этой операции можно вызвать команду ./setup.sh -r.

По окончанию удаления его лог будет сохранен в /opt/skala-r/var/logs/vision_remove.log.<ДАТА_УДАЛЕНИЯ>.

При необходимости удалить агенты мониторинга (см. п.12.2).

12.2 Ручное удаление агентов мониторинга#

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

1. Перейти в директорию дистрибутива, например:

сd /root/vision-distrib-<version>

2. Запустить команду, указав путь до файла инвентори (см. п. 6), например, /opt/skala-r/vision/server/inventory/PAK-1_2024-06-10_12-34-56.yml

ansible-playbook -i /opt/skala-r/vision/server/inventory/PAK-1_2024-03-04_21-32-48.yml ./playbooks/agent_delete.yml

12.3 Ручное удаление агентов мониторинга старых версий#

В случае удаления агентов мониторинга предыдущих версий < 1.2, необходимо:

1. Установить новую версию Визион.Сервера
2. Зарегистрировать ПАК
3. Сформировать файл инвентори
4. Выполнить шаги по ручному удалению

12.4 Известные проблемы при удалении Визиона и агентов мониторинга#

При удалении Визиона могут возникнуть следующие проблемы:

• Проблемы с правами доступа к временным файлам Ansible. Если пользователь, под которым был установлен Визион, больше не существует или у текущих пользователей нет прав на временные файлы Ansible, то для корректного удаления необходимо проверить корректность прав для директорий /tmp/.ansible, ~/.ansible.

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

13 ХРАНЕНИЕ СЕКРЕТОВ#

13.1 Общая концепция#

В целях безопасности в Визионе организовано безопасное хранение секретов (паролей, токенов и т.п.) в защищенном виде. Данная информация храниться в Ansible Vault и считывается в момент старта компонента vision-core.

Для оперирования содержимым хранилища требуется ключ, выдаваемый разработчиком Визиона. Расположение файла хранилища - /opt/skala-r/vision/.secrets_vault.

13.2 Работа с хранилищем секретов#

Просмотр содержимого хранилища:

ansible-vault view /opt/skala-r/vision/.secrets_vault

Редактирование содержимого хранилища:

ansible-vault edit /opt/skala-r/vision/.secrets_vault

В обоих случаях потребуется ввести пароль от хранилища после вывода Vault password.

13.3 Описание хранимых секретов#

vault.auth.client_secret- секрет, используемый для подключения сервера Визиона к Keycloak;

vault.database.password - пароль, для подключения к служебной БД Postgres;

vault.general.cookie_secret_key - ключ, используемый для работы с cookie;

vault.plagent.token - токен для подключения к агенту Платформы;

vault.smtp_config.smtp_auth_password - пароль для подключения к почтовому шлюзу для отправки сообщений о сработавших правилах оповещений;

vault.snmp_notifier.snmp_*_password - пароли для подключения к SNMP-шлюзу для отправки сообщений о сработавших правилах оповещений посредством SNMP-трапов (для SNMP v3 протоколов шифрования паролей authentication и protocol);

vault.*.basic_auth_password - пароли HTTP Basic Auth соответствующих компонентов.

vault.grafana.security.admin_password - Пароль администратора Grafana по умолчанию, можно изменить перед первым запуском Grafana или в настройках профиля.

vault.grafana.auth.generic_oauth.client_secret - Секрет клиента, предоставленный приложением OAuth2 для Grafana.

vault.grafana.metrics.basic_auth_password - Пароль BasicAuth для получения метрик Grafana.

14 ПРОВЕРКА ПРОГРАММЫ#

14.1 Отображение веб-интерфейса#

По завершении процесса установки должен быть доступен веб-интерфейс ПО Визион через браузер по адресу http://<хост Визиона>, далее пункт Аналитические панели и Модуль Администратора.

14.2 Проверка работоспособности сервисов#

Для проверки успешности установки каждого компонента зайти по ssh на ВМ Визион.Сервер и запустить команду:

cd /opt/skala-r/vision

./check_service.sh

В результате, вывод должен быть следующий:

Критерием успешности развертывания является значение active для перечисленных сервисов, перечисленных в разделе 2.5 данного руководства.

При статусе равном failed обратиться к пункту 3 для получения дополнительной информации.

Конфигурация компонентов после развертывания находится в директориях /opt/skala-r/etc/vision/<server|proxy|agent>/<vision_component>

15 Устранение неполадок#

Расположение файлов всех компонентов и плагинов унифицировано между Визион.Сервером/Прокси/Агентом.

^1 только для Визион.Сервер

15.1 Запуск ansible-playbook#

Список часто встречающихся проблем:

• Failed to parse <путь-до-инвентори-файла> - убедитесь в корректности yml-файла. Например, частая проблема - несоблюдение отступов.

• Permission denied, please try again. - убедитесь в корректности данных для доступа к узлу.

• Failed to connect to the host - убедитесь в правильности адреса узла и проверьте возможность подключения к нему по ssh.

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

15.2 Установка/конфигурация/удаление агентов/плагинов через интерфейс#

Управление агентами мониторинга происходит через агента Платформы, который необходимо развернуть на все сервера, на которые в последствии будут установлены Визион.Агент и Визион.Прокси. Проблемы при установке/конфигурации/удалении агентов/плагинов могут быть связаны с работоспособностью агента Платформы или с постановкой задач к нему через TaskDaemon.

15.2.1 Не изменяется статус агентов/плагинов#

Если при попытке установить/конфигурировать/удалить агенты/плагины не меняется статус сущности, то необходимо проверить работу компонента TaskDaemon.

systemctl status vision_taskdaemon.service

15.2.2 Статус “Ошибка” в интерфейсе#

В интерфейсе в статусе агентов/плагинов вы можете увидеть статус “Ошибка”.

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

• для агентов

curl -k https://<vision-ip>:8092/vision/api/v1/component/?object_id=<имя-объекта>

• для плагинов

curl -k https://<vision-ip>:8092/vision/api/v1/plugin_job/?object_id=<имя-объекта>

где <имя-объекта> - это имя проблемного сервера, виртуальной машины или ПАКа.

Тело ответа будет содержать поле data с массивом информации об агентах/плагинах. Найдите необходимый элемент массива. Описание последней ошибки содержится в поле task_error_detail агента/плагина.

Ошибка “No route to host” указывает на то, что компьютер не может установить соединение с целевым сервером. Возможные причины:

• Неверный адрес: убедитесь, что в интерфейсе Визиона указан корректный адрес хоста.

• Блокировка брандмауэром: проверьте настройки брандмауэра узла, чтобы убедиться, что они не блокируют соединение.
• Проблемы с маршрутизацией: возможно, между Визион.Сервером и целевым узлом нет сетевого пути.

Ошибки “Connection refused”/“timed out” указывают на недоступность Агента Платформы. Возможные причины: агент Платформы не установлен или не запущен. Проверьте статус службы и при необходимости перезапустите.

systemctl status plagent.service

В случае работоспособности агента Платформы, выполните curl-запрос версии к нему

• с узла, на котором он расположен:
  • по 127.0.0.1;
  • по IP узла по которому к нему должен обращаться Визион;
• с Визион.Сервера по IP проблемного узла.

curl -k -H 'Authorization: Bearer <your-token>' https://<ip-узла>:7550/v1/version 

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

15.3 Агенты установлены, но метрики отсутствуют#

Необходимо убедиться от какой части системы отсутвуют данные. Перейдите в веб-интерфейс VictoriaMetrics, открыв Интернет браузер, и введя в строке адреса IP-адрес сервера Визиона (https://<vision-ip>/vision/victoriametrics/vmui). В открывшемся интерфейсе вы сможете проверить начилие временных рядов в системе, используя PromQL-запросы.

При недоступности интерфейса VictoriaMetrics, проверьте работу сервиса victoriametrics_st.service и nginx.service.

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

15.3.1 Отсутствие данных с Прокси#

PromQL-запрос: up{_pak_id="<ИМЯ-ПАК>", job="vmagent_proxy"}

Если временной ряд отсутствует, то проверьте работоспособность systemd сервиса vision_vmagent_proxy.service на узле, где он установлен (выбирается при установке Агентов).

Если сервис имеет статус active, но данных в базе временных рядов нет: убедитесь, что с узла, где расположен Прокси, есть возможность отправлять данные в VictoriaMetrics по https. Например, результат такого curl должен быть OK:

curl -k https://<user>:<pass>@<ip-vision>/vision/victoriametrics/health

15.3.2 Отсутствие данных с Агентов#

PromQL-запросы:

• up{_node_id="<ИМЯ-СЕРВЕРА>", job="vmagent_agent"}
• up{_vm_id="<ИМЯ-ВМ>", job="vmagent_agent"}

Если временной ряд отсутствует, то проверьте работоспособность systemd сервиса vision_vmagent_agent.service на узле, где он установлен.

Если сервис имеет статус active, но данных в базе временных рядов нет: убедитесь, что с узла, где расположен Агент, есть возможность отправлять данные в Прокси по https в порт 8430 (см. п 1.3). Например, результат такого curl должен быть OK:

curl -k https://<user>:<pass>@<ip-vision>:8430/health

15.3.3 Отсутствие данных с плагинов (экспортеры/скреперы)#

PromQL-запросы:

• up{_node_id="<ИМЯ-СЕРВЕРА>", job="<ИМЯ-ПЛАГИНА>"}
• up{_vm_id="<ИМЯ-ВМ>", job="<ИМЯ-ПЛАГИНА>"}

Если временной ряд отсутствует, то проверьте работоспособность systemd сервиса vision_<ИМЯ-ПЛАГИНА>.service на узле, где он установлен (только в случае экспортера, см. п.1.4).

Если временной ряд присутствует, но его значение равно 0, то проверьте параметры плагина в интерфейсе Визиона на корректность (см. п.7.1). Например, данные авторизации, адрес сервиса/источника метрик, порт и т.п.

15.3.4 Превышение таймаута сбора метрик с помощью плагинов#

PromQL-запрос: scrape_duration_seconds{_pak_id="<ИМЯ-ПАК>"} > scrape_timeout_seconds{_pak_id="<ИМЯ-ПАК>"} * 0.5

График с данным запросом отображает проблемы с продолжительностью сбора метрик.

Если временные ряды присутствуют, то необходимо в интерфейсе Визиона в параметрах соответствующих плагинов (имя плагина соответствует метке job) увеличить таймаут в поле “Scrape Timeout”, но не выше, чем “Scrape Interval”.

15.4 Отсутствие метрик при работоспособности всех компонентов#

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

15.5 После изменения времени на сервере Визиона алерты продолжают приходить со старым временем#

При смене времени на сервере Визиона необходимо перезапустить сервисы vmalert_st и alertmanager:

systemctl restart vmalert_st
systemctl restart alertmanager

16 Журналирование и аудит#

16.1 Конфигурирование логирования vision_core#

Файл конфигурации логирования vision_core расположен в /opt/skala-r/etc/vision/server/vision_core/log_config.yml.

Для изменения конфигурации логирования необходимо обладать правами root.

Пример файла конфигурации

# Аудит
audit:
  # Уровень сообщений, которые логируются DEBUG|INFO|WARNING|ERROR|CRITICAL
  level: INFO

  # Параметры форматов записи логов
  formatters:

    # Формат CEF
    cef:
      # Вкл/выкл запись логов в формате CEF
      enable: true

      # Управление ротированием файлов логов
      rotate:
        filepath: "/opt/skala-r/var/log/vision/audit/cef/audit.log"
        maxBytes: 104857600  # максимальный размер файла логов
        backupCount: 5       # количество сохраненных логов "<filepath>.<n>" по maxBytes

    # Формат JSON (ГосТех)
    json:
      enable: true
      rotate:
        filepath: "/opt/skala-r/var/log/vision/audit/audit.log"
        maxBytes: 104857600
        backupCount: 5

  # Фильтрация записей по группам/действиям/статусам событий
  # Например, ["11-15", "2"] — исключить с 11 по 15 включительно и 2 ID
  # Перечень срезов vision-core/docs/events
  filters:
    groups: []
    actions: []
    status: []

# Журналирование, аналогично параметрам аудита
journal:
  level: INFO
  formatters:
    text:
      enable: true
      rotate:
        filepath: "/opt/skala-r/var/log/vision/journal/journal.log"
        maxBytes: 104857600
        backupCount: 5
  filters:
    groups: []
    actions: []
    status: []

Все ключи являются необязательными.

Предоставляется возможность настройки логгеров audit и journal:

• level - уровень логирования. Допустимые значения: DEBUG, INFO, WARNING, ERROR, CRITICAL.
• formatters - параметры форматов записи логов. Допустимые ключи для audit: cef, json, для journal: text.
  • enable - включение/выключение записи логов в данном формате. Допустимые значения: true, false.
  • rotate - управление ротированием файлов логов
    • filepath - путь до файла в который будут записываться логи данного формата.
    • maxBytes - максимальный размер файла логов в байтах.
    • backupCount - количество сохраняемых файлов логов.
• filters - параметры фильтрации записей по группам/действиям/статусам событий в формате ключ-значение, где
  • ключи groups/actions/status (значения ключей приведены в разделе 16.1.1)
  • значения - массив строк, перечисляющий ID groups/actions/status

16.1.1 Значения ключей, используемых для фильтрации событий#

Для исключения событий из процесса журналирования соответствующие идентификаторы (ID) должны быть перечислены в разделе filters файла конфигурации (см. Раздел 16.1).

Ключи для групп событий (groups)

Ключи для действий (actions)

Ключи для статусов событий (status)

16.2 Описание формата логов#

16.2.1 Аудит vision_core#

16.2.1.1 Формат CEF#

Пример записи

CEF:0|Skala-r|Vision|dev-281|20000020|Чтение: версия Визиона|3|externalId=4 msg=Чтение: версия Визиона deviceProcessName=vision_core outcome=success start=1722617884852 dst=192.168.186.138 dhost=vision-dev-ps.int.skala-r.tech suser=admin src=192.168.186.1 shost=192.168.186.1 spt=42658 a  
pp=HTTPS dpt=8088

Заголовок CEF

Поля extension CEF

16.2.1.2 Формат JSON#

Пример записи

{"createdAt": "1722617884851", "userNode": "vision-dev-ps.int.skala-r.tech", "metamodelVersion": "1", "module": "Vision", "name": "Чтение: версия Визиона", "userLogin": "admin", "userName": "admin", "params": [{"name": "message", "value": "Чтение: версия Визиона"}, {"name": "serviceVersion", "value": "dev-281"}]}

16.2.2 Журналирование (journal) vision_core#

Пример записи

2024-08-02T19:58:04+0300 vision-dev-ps.int.skala-r.tech INFO Чтение: версия Визиона

• Время возникновения события
• Имя хоста получателя (Визиона).
• Уровень журнала
• Описание события

16.3 Расположение журналов компонентов#

16.3.1 Аудит компонентов Визиона#

Запись происходит в журнал аудита /opt/skala-r/var/log/vision/audit/<COMPONENT>/<SERVICE>/audit.log в формате CEF.

17 Ролевая модель#

17.1 Концепция ролевой модели Визион#

Визион допускает работу пользователей вообще без какой-либо аутентификации (любой пользователь, зашедший на веб-страницу по адресу Визион, получает полный набор полномочий), либо с аутентификацией через один из совместимых провайдеров (IAM):

• Keycloak ,
• Avanpost FAM ,
• Basis Virtual Security .

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

Учётной записи пользователя на стороне провайдера аутентификации назначается одна или несколько ролей.

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

Важно! Имя роли в провайдере аутентификации должно совпадать с именем роли в Визион

Важно! Настройка автоматизированных рассылок уведомлений в текущей версии Визион доступна только для провайдера аутентификации Keycloak.

17.2 Аутентификация и авторизация пользователя#

Аутентификация пользователя — процедура проверки его подлинности путём сверки введённого пароля с хранимым в базе данных провайдера аутентификации. При успешной аутентификации Визион получает от провайдера аутентификации информацию о наборе назначенных ему ролей.

Авторизация пользователя — предоставление ему полномочий на выполнение определённых действий в Визион на основе набора назначенных ролей и соответствующих этим ролям полномочий.

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

Пользователю может быть отказано в авторизации, при этом будет выведено окно:

Такое возможно, если:

• учётной записи пользователя не назначены роли на стороне провайдера аутентификации,
• роли учётной записи назначены на стороне провайдера аутентификации, но не созданы на стороне Визион,
• роли созданы на стороне Визион, но им не назначены полномочия.

В случае, если провайдер аутентификации недоступен, администратор может перевести Визион в режим обслуживания, воспользовавшись инструкцией . Этот режим предназначен для временного использования и только администратором Визион.

17.3 Роли администраторов#

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

Соответствие между именами ролей администраторов на стороне провайдера аутентификации и именами ролей на стороне Визион задаётся в конфигурационном файле vision_core в блоке auth:

Важно! Имя роли в провайдере аутентификации должно совпадать с именем роли в Визион

auth:
  ...
  admin_role_codes:
    role_model: role_model
    obj_model: obj_model
    vsn_config: vsn_config

В случае, если используются имена ролей администраторов “по умолчанию”, блок admin_role_codes может отсутствовать. При необходимости, можно изменить имена ролей администраторов на стороне Визион. Чтобы изменения, внесённые в конфигурационный файл, вступили в силу, необходимо перезапустить компонент vision_core командой systemctl restart vision_core

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

Все остальные (не административные) роли настраиваются администратором в интерфейсе пользователя Визион, как описано ниже.

17.4 Управление ролями пользователей#

Управление ролевой моделью Визиона доступно только пользователям с ролью администратора информационной безопасности. Под управлением ролевой моделью понимается:

• создание ролей (раздел “17.4.1”),
• назначение полномочий на объекты Контура, плагины и дашборды (раздел “17.4.2”),
• переименование существующих ролей (раздел “17.4.3”),
• удаление ролей (раздел “17.4.4”),
• создание роли с набором полномочий, взятых из другой роли (раздел “17.4.5”).

Особенности применения полномочий, назначенных роли, описаны в разделе “17.5”. Для осуществления действий по управлению ролями администратор информационной безопасности должен перейти в раздел “Безопасность - Ролевая модель”:

Справа от имени роли находится меню роли, определяющее возможные действия с ролью:

17.4.1 Добавление роли#

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

Нажмите на кнопку “Добавить роль”. В появившемся окне введите имя роли и нажмите “Сохранить”. Имя роли должно отличаться от имен уже созданных ролей.

После создания новой роли необходимо сохранить полномочия, иначе пользователь не сможет авторизоваться.

17.4.2 Назначение полномочий для роли#

Назначение полномочий для ролей пользователей осуществляется путем выбора чек-бокса на пересечении объекта и роли в таблице полномочий. Пустой чек-бокс соответствует отсутствию полномочия. После выбора полномочий необходимо нажать на кнопку “Сохранить”. Если нажать на кнопку “Сбросить”, то изменения, внесенные с момента последнего сохранения, будут отменены.

17.4.3 Переименование роли#

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

В меню роли выберите “Переименовать”. В появившемся окне введите новое имя роли и нажмите “Сохранить”. Имя роли должно отличаться от имен уже созданных ролей.

17.4.4 Удаление роли#

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

В меню роли выберите “Удалить”. В появившемся окне подтвердите удаление.

Удаление роли на стороне Визион не приведёт к удалению ролей на стороне провайдера аутентификации.

17.4.5 Дублирование роли#

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

В меню роли выберите “Дублировать”. В появившемся окне введите имя новой роли и нажмите “Сохранить”. Имя роли должно отличаться от имен уже созданных ролей. Созданная роль будет содержать полномочия роли, которая была выбрана для дублирования.

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

17.5 Применение полномочий#

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

17.5.1 Доступ к разделам Визион#

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

“есть” - означает, что раздел отображается в интерфейсе пользователя, при этом все пользователи имеют полномочия просмотра, но только роли администраторов имеют полномочия на изменение.

“нет” - означает, что раздел не отображается в интерфейсе пользователя и недоступен ни на просмотр ни на изменение.

Раздел “О программе” доступен пользователям с любыми ролями.

Иллюстрация доступа к общим меню для стартовой страницы Визион и страницы статистики уведомлений:

Иллюстрация доступа к разделам для страницы “Визион (администрирование)”:

17.5.2 Список уведомлений#

В разделе “Уведомления” пользователи с ролями администраторов видят весь список уведомлений, создаваемых всеми объектами Контура.

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

• на объекты Контура (ПАКи)
• на категории алертов.

Например, если роль имеет полномочия только на ПАК с именем “ПАК1” и на категорию алертов “server”, пользователь, которому назначена только эта роль, увидит только уведомления касающиеся ПАК1 и его серверной инфраструктуры.

Список категорий алертов:

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

17.5.3 Стартовая страница Визион#

На стартовой странице пользователям с ролями администраторов доступна информация по всем ПАКам Контура. Остальные пользователи увидят только те ПАКи и уведомления, на которые имеют полномочия (см. раздел 17.5.2).

17.5.4 Страница статистики уведомлений#

На странице статистики уведомлений пользователям с ролями администраторов доступна информация по всем ПАКам Контура. Остальные пользователи увидят только статистику по тем ПАКам и тем уведомлениям, на которые имеют полномочия (см. раздел 17.5.2).

17.5.5 Дашборды#

Дашборды отображаются в интерфейсе Grafana. Пользователь с ролью Администратора Мониторинга (vsn_config) имеет административные полномочия в Grafana и может создавать или изменять дашборды. Пользователи с ролями Администратора объектной модели (obj_model) или Администратора ИБ (role_model) могут просматривать все дашборды, но не могут создавать или изменять их. Остальные пользователи имеют возможность просматривать дашборды, на которые их ролям назначены полномочия в разделе “Безопасность - Ролевая модель”.

Например, ролям r_networks, r_servers и r_dba назначены следующие полномочия на дашборды:

Тогда пользователи с ролью “r_networks” и “r_servers” увидят дашборды, входящие в группу “Главная”, а пользователи с ролью “r_dba” увидят дашборды, входящие в группу “МБД.П”.

В случае, если Администратор Мониторинга создает новые дашборды в Grafana, он должен вручную назначить им полномочие “view” для групп, соответствующих ролям Администратора ИБ (role_model) и Администратора ОМ (obj_model).

17.5.6 Функционал рассылки уведомлений#

Группы рассылки уведомлений создаются автоматически при сохранении полномочий для роли (значение поля “Добавление” равно “Авто”).

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

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

Получатели для таких групп рассылки (их e-mail адреса) добавляются автоматически из провайдера аутентификации на периодической основе (значение поля “Добавление” равно “Авто”).

Администратор может вручную отключить пользователя от рассылки уведомлений используя переключатель в поле “Активно”.

Более подробно настройка провайдера аутентификации и Визион для автоматизированных рассылок уведомлений описана в инструкции .

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

17.6 Поддержка устаревших ролей reader и writer#

Роли reader и writer, которые использовались в предыдущих версиях Визион, не поддерживаются в новой ролевой модели. Администратору необходимо добавить недостающие роли и назначить полномочия. Например, администратор может добавить роль с именем reader и назначить полномочия на просмотр всех объектов Контура и все плагины, тогда пользователи с ролью reader смогут просматривать уведомления для объектов всего Контура.

17.7 Ролевая модель для Grafana#

Grafana не требует отдельной авторизации через провайдера аутентификации, авторизация пользователя происходит через Визион. Для этого в конфигурационном файле vision_core должен быть выставлен параметр enabled: true в блоке auth.

Пользователь Визион с ролью администратора мониторинга (vsn_config) обладает ролью administrator в Grafana и имеет полномочия создавать и изменять дашборды. Все остальные пользователи имеют только полномочия просмотра дашбордов.

При создании новой роли в Визион автоматически создается соответствующая группа (team) в Grafana. В разделе “Ролевая модель” администратор ИБ видит все настроенные в Grafana дашборды и назначает полномочия на них для ролей пользователя.

Когда пользователь заходит в интерфейс Grafana, то он видит только те дашборды, на которые назначены полномочия для групп (teams) соответствующих его ролям в Визион.

18 СМЕНА ТЕХНОЛОГИЧЕСКИХ ПАРОЛЕЙ#

18.1 Смена пароля для AlertManager#

При смене пароля для комопнента alertmanager необходимо также изменить пароль у всех компонентов, которые с ним взаимодействуют. Это все компоненты , у которых alertmanager указан в пункте “Используемые УЗ компонентов Визиона”: vision_core, victoriametrics_st, vmalert_st.

1. Произвести генерацию пароля при помощи команды:

date | md5sum | awk '{ print $1 }' или openssl rand -base64 16

2. Перейти в хранилище секретов:

Для оперирования содержимым хранилища требуется ключ, выдаваемый разработчиком Визиона. Потребуется ввести пароль от хранилища после вывода Vault password. Отредактировать поле со значением alertmanager в хранилище ansible-vault edit /opt/skala-r/vision/.secrets_vault

3. Перейти в файл конфигуации компонента alertManager в /opt/skala-r/etc/vision/server/alertmanager/web.yml и отредактировать:

Секция basic_auth_users, параметр vision

Пароль захеширован при помощи bcrypt, чтобы его расхешировать, необходимо выполнить команду: import bcrypt; print(bcrypt.hashpw("СЕКРЕТ".encode("utf-8"), bcrypt.gensalt()).decode())

4. Перейти в файл конфигурации VictoriaMetrics и поменять пароль компонента victoriametrics_st /opt/skala-r/etc/vision/server/victoriametrics_st/victoriametrics_st.yml

где - job_name: alertmanager, заменить пароль basic_auth - password

Пароль захеширован, чтобы его расхешировать, необходимо выполнить команду: /opt/skala-r/etc/vision/server/vision_venv/bin/python3 >>> import skalar.vision.common.encode >>> skalar.vision.common.encode.encode_password('Pass')

Вместо ‘Pass’ указать сгенерированный пароль на шаге 1.

5. Перейти в файл конфигурации компонента vmalert_st и поменять пароль: /opt/skala-r/etc/vision/server/vmalert_st/environment.env

где - job_name: notifier.url=https://127.0.0.1:9093/vision/alertmanager/ заменить пароль для notifier.basicAuth.password

6. Перейти в файл конфигурации компонента visioncore и поменять пароль:

??? Под вопросом, возможно, visioncore трогать не нужно ???

7. Перезагрузить комопненты visioncore, alertmanager, victoriametrics_st, vmalert_st

18.2 Смена пароля для Grafana#

1. Перейти в хранилище секретов:

Для оперирования содержимым хранилища требуется ключ, выдаваемый разработчиком Визиона. Потребуется ввести пароль от хранилища после вывода Vault password.

Отредактировать поле со значением vault.grafana.basic_auth_password в хранилище ansible-vault edit /opt/skala-r/vision/.secrets_vault