Руководство администратора Визион
Документ Описание Ссылка на PDF
Руководство администратора v1.4.1 PDF

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

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

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

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

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

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

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

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

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

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

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

Параметр Требование
CPU рекомендованное
Визион.Сервер от 8 ядер
Визион.Прокси от 2 ядер
Визион.Агент от 1 ядра
RAM рекомендованное
Визион.Сервер от 32 Гб;
Визион.Прокси от 16 Гб
Визион.Агент от 4 Гб
ROM рекомендованное
Визион.Сервер - в зависимости от количества ПАК на контуре и требуемой глубины хранения метрики, от 600 Гб SSD на каждый ПАК
Визион.Прокси в зависимости от требуемой глубины кеширования данных от 20 Гб SSD
Визион.Агент в зависимости от требуемой глубины кеширования данных от 5 Гб SSD
Поддерживаемые ОС
ОС АЛЬТ 8 СП СЕРВЕР р9, р10
Astra Linux Special Edition 1.7.3 (Воронеж)
РЕД ОС 7.3 (Муром)
Поддерживаемые браузеры
Google Chrome версий от 116 и выше
Firefox начиная с 60.хх версии

Примечание:

Основной потребитель ресурсов на стороне сервера Визиона - 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 - компонент, регистрирующий оповещения в служебную БД;
  • Grafana backend - компонент, обеспечивающий альтернативную визуализацию собираемых метрик;
  • AlertManager - компонент, обеспечивающий обработку, группировку и отправку оповещений (поддерживает SMTP и веб-хуки);
  • SNMP_notifier - вспомогательный компонент, предназначенный для отправки оповещений с помощью протокола SNMP (Simple Network Management Protocol);
  • TaskDaemon - компонент, отвечающий за выполнение фоновых задач (например, развертывание агентов и их плагинов);
  • Nginx - прокси-сервер, обеспечивающий получение и перенаправление запросов на компоненты Визион.Сервера.

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 Состав сервисов#

Сервис ОС Компонент Порт Протокол
postgresql Визион.Сервер 5432 HTTPS
vision_core Визион.Сервер 8088 HTTPS
nginx Визион.Сервер 443, 80, 8092 HTTPS
grafana Визион.Сервер 3000 HTTPS
victoriametrics_st Визион.Сервер 8428 HTTPS
vmalert_st Визион.Сервер 8880 HTTPS
vision_alertcollector Визион.Сервер 10111 HTTPS
alertmanager Визион.Сервер 9093 HTTPS
snmp_notifier Визион.Сервер 9464 HTTPS
vision_vmagent_proxy Визион.Прокси 8430 HTTPS
vision_vmagent_agent Визион.Агент 7529 HTTPS
plagent Агент Платформы 7550, 7551 HTTPS, gRPC

2.6 Плагины#

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

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

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

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

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

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

Название Мониторинг ПАК Сервер/ВМ** Сервис ОС Порт***
node_exporter ОС сервера все все vision_node_exporter 9101
ipmi_exporter BMC (IPMI) все ВМ с Прокси vision_ipmi_exporter 9290
snmp_exporter коммутатор (SNMP) все ВМ с Прокси vision_snmp_exporter 9116
utlz_exporter утилизация сервера все все серверы vision_utlz_exporter 9092
utlz_exporter_v0* утилизация сервера все все серверы vision_utlz_exporter_v0 17070
one_exporter OpenNebula МВ.ВК узел с OpenNebula frontend vision_one_exporter 9621
ceph_scraper Ceph МВ.ВК ВМ с Прокси
ha_cluster_exporter Pacemaker/Corosync МБД.П узел кластера vision_ha_cluster_exporter 9664
postgres_exporter_agent Postgres МБД.П узел кластера vision_postgres_exporter_local 9187
postgres_exporter_multi Postgres МБД.П узел кластера или узел с Прокси vision_postgres_exporter_multi 9188
sql_exporter Postgres МБД.П узел кластера или узел с Прокси vision_sql_exporter 9399
spectrum_agent_scraper агент Спектра МБД.П узел кластера
supv_exporter сервисы СУПВ МВ.С/ВРМ ВМ с Прокси vision_supv_exporter 9179
haproxy_scraper_local HAProxy МХД.О узлы балансировки
s3gateway_compression_server_scraper шлюз S3 МХД.О узлы балансировки
s3gateway_ostor_server_scraper сервисы S3 МХД.О узлы хранения
nginx_exporter Nginx МХД.О все серверы vision_nginx_exporter 9113
vision_exporter сервисы ОС МХД.О/MБД.П все серверы vision_exporter 7531

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

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

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

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
  1. Распаковать архив с дистрибутивом `.tar.gz``, например:
tar -xzvf vision-distrib-1.4-289.tar.gz
  1. Перейти в директорию дистрибутива, например:
`сd /root/vision-distrib-1.4-289
  1. Запустить скрипт:
./setup.sh
  1. Выбрать одно из действий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sh cd /root

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

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

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

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

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

sh ./setup.sh -s 192.168.1.1

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

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

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

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

sh cd /opt/skala-r/vision

  1. Запустить скрипт check_service.sh:

sh ./check_service.sh

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

По завершении процесса установки должен быть доступен веб-интерфейс Визиона через браузер по его IP-адресу (вводим в адресной строке адрес вида https://192.168.186.1, далее выбираем пункты «Аналитические панели» и «Модуль Администратора».

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

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

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

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

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

  1. Перед настройкой требуется убедиться, что имеется инсталляционная карта с соответствующим описанием ПАК, либо все необходимые параметры и доступы для постановки объектов на мониторинг.
  2. Перейти в веб-интерфейс Визиона, открыв Интернет браузер, и введя в строке адреса IP-адрес сервера Визиона, например, https://<vision-ip>.
  3. Добавить новый ПАК: раздел в боковом меню “Параметры”->“Объекты”, в панели “Контур” нажать кнопку ⠇ и выбрать “Добавить ПАК”.

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

    Пример интерфейса:

Пункт «ПАК»:

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

Пункт «Модуль»:

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

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

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

4.2.1 ПАК#

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

затем нажать кнопку «Далее».

4.2.2 Модуль#

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

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

4.2.3 Сервер#

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

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

4.2.4 ВМ#

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

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

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

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

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

4.2.6 Проверка#

Сводная таблица по всем объектам ПАК, необходимо проверить корректность предоставленных данных.

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

Пример заполненного раздела:

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

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

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

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

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

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

nano /opt/skala-r/vision/server/inventory/PAK-1_2024-06-10_10-10-10.yml

  1. Заменить значения “===REPLACE===” на реальные:
  • ansible_user и ansible_ssh_pass - имя и пароль учетной записи для подключения к хостам по SSH
  • ansible_become_password - пароль учетной записи администратора для установки агента Платформы
  1. Перейти в директорию дистрибутива:

сd ./vision-distrib-1.4-289

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

ansible-playbook -i /opt/skala-r/vision/server/inventory/PAK-1_2024-04-14_23-19-46.yml ./plagent/install.yml

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

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

ansible-playbook -i <INVENTORY_PATH> <PLAYBOOK>

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

где <INVENTORY_PATH> - путь до итогового файла инвентори,  - выполняемое действие:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.1 vision_exporter#

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

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

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

Для получения метрик 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.3 Добавление и обновление плагинов#

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

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

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

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

systemctl restart vision_core.service

  1. Проверьте состояние 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 со следующими полями:

Имя параметра Описание
snmp_version версия SNMP. Допустимые значения: “V2c”, “V3”. По умолчанию “V2c”.
snmp_destination адресат сообщений. По умолчанию “127.0.0.1:162”.
snmp_retries количество повторных посылок сообщения SNMP. По умолчанию 1.
snmp_trap_default_oid OID ловушки, если он не найден в метках сработавшего правила. По умолчанию “1.3.6.1.4.1.98789”.
snmp_timeout_sec длительность таймаута в секундах. По умолчанию 5.
snmp_community коммьюнити SNMP (только для V2c, иначе null). По умолчанию “public”.
snmp_authentication_protocol протокол шифрования пароля (только для V3). Допустимые значения: “MD5”, “SHA”, null. По умолчанию null.
snmp_authentication_username имя пользователя аутентификации SNMP (только для V3). Обязателен*, если указан snmp_authentication_protocol. По умолчанию null.
snmp_authentication_password пароль аутентификации SNMP (только для V3). Обязателен*, если указан snmp_authentication_protocol. По умолчанию null.
snmp_private_protocol протокол передачи данных SNMP (только для V3). Допустимые значения: “DES”, “AES”, null. По умолчанию null.
snmp_private_password Пароль шифрования SNMP (только для V3). Обязателен*, если указан snmp_private_protocol. По умолчанию null.
snmp_security_engine_id ID механизма безопасности SNMP. По умолчанию null.
snmp_context_engine_id ID механизма контекста. По умолчанию null.
snmp_context_name имя контекста. По умолчанию null.

Пример 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-шлюз”)
  1. Нажать кнопку “Добавить”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

./setup.sh

  1. Выбрать действие “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>

  1. Запустить команду, указав путь до файла инвентори (см. п. 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 соответствующих компонентов.

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 Устранение неполадок#

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

Описание Расположение
Исполняемые и прочие файлы /opt/skala-r/vision/<server-proxy-agent>/<имя-компонента>
Файлы конфигурации /opt/skala-r/etc/vision/<server-proxy-agent>/<имя-компонента>
Логи компонентов Системный журнал и/opt/skala-r/var/log/vision/<server-proxy-agent>/<имя-компонента>
Хранилище секретов ^1 /opt/skala-r/vision/.secrets_vault
Nginx ^1 /etc/nginx

^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 Отсутствие метрик при работоспособности всех компонентов#

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

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)

Имя группы Текст подгруппы ID подгруппы
Приложение приложение vision_core 10
Авторизация вход пользователя в систему 21
Авторизация выход пользователя из системы 22
Авторизация информация о входе в систему 23
Авторизация информация о текущем пользователе 24
Запрос метрик (UI) значения метрик за момент времени 31
Запрос метрик (UI) значений метрик за период времени 32
Запрос метрик (внешний) значений метрик за момент времени 41
Запрос метрик (внешний) значений метрик за период времени 42
Запрос метрик (внешний) список меток метрик 43
Запрос метрик (внешний) значений метки метрик 44
Запрос метрик (внешний) статуса TSDB 45
Запрос метрик (внешний) серий метрик 46
Запрос метрик (внешний) значений метрик через федерацию 47
Конфигурирование Визион.Сервера параметры SMTP-шлюза для отправки уведомлений 51
Конфигурирование Визион.Сервера параметры SNMP-notifier для отправки уведомлений 52
Импорт данных импорт данных (список метрик и правил оповещения) 60
Самодиагностика Визион.Сервера здоровье компонентов сервера 71
Самодиагностика Визион.Сервера логи компонентов сервера 72
Инвентори ПАК инвентори файла ПАКа 80
foliage список серверов из приложения Foliage 91
foliage список коммутаторов из приложения Foliage 92
foliage список сетей из приложения Foliage 93
список меток и их значений список меток метрик 101
список меток и их значений значений метки метрик 102
Взаимодействие TaskDaemon с Визион.Сервером уведомление от TaskDaemon 110
Объекты мониторинга объект мониторинга 121
Объекты мониторинга допустимые вложенные типы объектов мониторинга 122
Объекты мониторинга ссылки на объект мониторинга 123
Объекты мониторинга типы объектов мониторинга 124
Объекты мониторинга справочник подтипов объектов мониторинга 125
Компоненты мониторинга компонент мониторинга 130
Плагины общая информация о плагине 141
Плагины экземпляр плагина 142
Плагины таргет плагина 143
Метрики метрика 151
Правила оповещения правило оповещения 161
Получатели уведомлений их группы получатель уведомлений 171
Получатели уведомлений их группы группа получателей уведомлений 172
Оповещения о сработавших правилах оповещение о сработавшем правиле 181
Оповещения о сработавших правилах количество оповещений о сработавших правилах 182
Токены токен доступа 190
Версия Визиона версия Визиона 200

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

Имя действия ID действия
Создание 1
Чтение 2
Редактирование 3
Удаление 4
Получение 5
Отзывается 6
Установка 7
Деинсталляция 8
Запуск 10
Остановка 11
Авторизация 14
Ротация логов 15

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

Текст статуса ID статуса
успешно 0
неуспешно 1
доступ запрещен 2

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

Field Name Description
CEF:Version Версия формата CEF. Константа CEF:0
Device Vendor Название производителя. Константа Skala-r
Device Product Название продукта. Константа Vision
Device Version Версия Визиона
Device Event Class ID Уникальный идентификатор категории события. Формируется путём <группа><действие><статус>
Name Краткое описание события.
Severity Целое число, отражающее важность события. Число от 0 до 10, где 10 обозначает наиболее важное событие.
Extension Список пар “ключ=значение”, содержащих дополнительную информацию о событии

Поля extension CEF

Field Name Description
externalId Уникальный номер строки о событии в рамках одного журнала. Сквозная инкрементация (счетчик). Обнуляется при перезапуске сервиса.
msg Текст сообщения с детальной информацией о событии.
deviceProcessName Полное имя процесса. Константа vision_core
outcome Результат события. success / failure
start Время возникновения события в формате Unix Timestamp.
dhost Имя хоста получателя (Визиона)
dst IP адрес хоста получателя (Визиона)
dpt * Порт на стороне получателя (Визиона)
suser * Имя пользователя, инициировавшего событие
src * IP адрес хоста-источника
shost * FQDN или имя хоста-источника
spt * порт на стороне источника
app * Протокол уровня приложения
^1 при наличии
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"}]}
Поле Описание
createdAt Время возникновения события в формате Unix Timestamp.
userNode Имя хоста получателя (Визиона).
metamodelVersion Константа 1.
module Название продукта. Константа Vision
name Краткое описание события.
userLogin Имя пользователя, инициировавшего событие.
userName Полное пользователя, инициировавшего событие (если доступно).
params- name=message Дополнительная информация о событии.
params- name=serviceVersion Версия Визиона.

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

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

2024-08-02T19:58:04+0300 vision-dev-ps.int.skala-r.tech INFO Чтение: версия Визиона
  • Время возникновения события
  • Имя хоста получателя (Визиона).
  • Уровень журнала
  • Описание события

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

Компонент Сервис ОС Расположение журналов по умолчанию
Визион.Сервер vision_core Системный журнал, /opt/skala-r/var/log/vision/audit/cef/audit.log, /opt/skala-r/var/log/vision/audit/audit.log, /opt/skala-r/var/log/vision/journal/journal.log
Визион.Сервер vision_taskdaemon Системный журнал
Визион.Сервер postgresql Системный журнал и стандартное расположение логов PostgreSQL /var/lib/pgsql/data/log/
Визион.Сервер nginx Системный журнал и стандартное расположение логов nginx /var/log/nginx/
Визион.Сервер grafana Системный журнал и /opt/skala-r/var/log/vision/server/grafana/
Визион.Сервер victoriametrics_st Системный журнал
Визион.Сервер vmalert_st Системный журнал
Визион.Сервер vision_alertcollector Системный журнал и /opt/skala-r/var/log/vision/server/vision_alertcollector/vision_alertcollector.log
Визион.Сервер alertmanager Системный журнал
Визион.Сервер snmp_notifier Системный журнал
Визион.Прокси vision_vmagent_proxy Системный журнал и /opt/skala-r/var/log/vision/proxy/vmagent_proxy/vmagent.log
Агент Платформы plagent Системный журнал
Визион.Агент vision_vmagent_agent Системный журнал и /opt/skala-r/var/log/vision/agent/vmagent_agent/vmagent.log
Визион.Агент vision_node_exporter Системный журнал и /opt/skala-r/var/log/vision/agent/node_exporter/node_exporter.log
Визион.Агент vision_ipmi_exporter Системный журнал
Визион.Агент vision_snmp_exporter Системный журнал
Визион.Агент vision_utlz_exporter Системный журнал и /opt/skala-r/var/log/vision/agent/utlz_exporter/utlz_exporter.log
Визион.Агент vision_utlz_exporter_v0 Системный журнал и /opt/skala-r/var/log/vision/agent/utlz_exporter_v0/utlz_exporter_v0.log
Визион.Агент vision_one_exporter Системный журнал
Визион.Агент vision_ha_cluster_exporter Системный журнал
Визион.Агент vision_postgres_exporter_local Системный журнал
Визион.Агент vision_postgres_exporter_multi Системный журнал
Визион.Агент vision_sql_exporter Системный журнал
Визион.Агент vision_supv_exporter Системный журнал и /opt/skala-r/var/log/vision/agent/supv_exporter/supv_exporter.log
Визион.Агент vision_nginx_exporter Системный журнал и /opt/skala-r/var/log/vision/agent/nginx_exporter/nginx_exporter.log
Визион.Агент vision_exporter Системный журнал и /opt/skala-r/var/log/vision/agent/vision_exporter/vision_exporter.log

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

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