Обновление Smart Monitor

Обратите внимание!

Инструкция описывает процесс обновления Smart Monitor с версии 6.1.* на 6.2.*.

Обратите внимание!

Для корректной работы заметок и другого функционала нужно создать на узлах Smart Monitor Data Storage директорию $OS_HOME/uploads, изменить права на пользователя, под которым работает Smart Monitor Data Storage, подключить к этой директории общую сетевую папку. Воспользуйтесь статьей по настройке

Информация

Условные обозначения:

• SM_INSTALLER - директория, куда разархивируется установочный пакет Smart Monitor версии 6.2
• USER - пользователь системы с правами администратора, обычно это admin
• OS_HOME - домашняя директория OpenSearch, обычно это /app/opensearch/
• OS_DATA - директория, где хранятся проиндексированные данные, обычно это /app/data/opensearch
• OS_IP - IP-адрес одного из серверов кластера OpenSearch
• OSD_HOME - домашняя директория OpenSearch Dashboards, обычно это /app/opensearch-dashboards/
• PATH_SSL - место расположения сертификата, закрытого ключа admin, а также ca-cert, обычно совпадает с /app/opensearch/config/

Первоочередным шагом для обновления является определение текущей установленной версии Smart Monitor. Это можно сделать, просмотрев версии модулей на главной странице или выполнив команду в командной строке:

curl https://$OS_IP:9200/_cat/plugins -k -u $USER

После ввода данной команды потребуется ввести пароль учетной записи $USER. Рекомендуется использовать пользователя admin.

Подробный список нововведений можно посмотреть в статье Что нового в Smart Monitor 6.2.

Рассмотрим процедуру обновления каждого компонента. Установщик 6.2 требуется распаковать в директорию, например, /app/distr/.

Обратите внимание!

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

Рекомендуемые действия

Рекомендуется создать директорию, например, /app/backup, куда следует сохранить:

• директория config, обычно $OS_HOME/config или $OSD_HOME/config

• файлы systemd, обычно это /etc/systemd/system/opensearch.service и /etc/systemd/system/opensearch-dashboards.service, /etc/systemd/system/sme-re.service

• файл /etc/sysctl.d/00-opensearch.conf

• копия настроек Security, сделать это нужно один раз, для чего потребуются сертификат и закрытый ключ admin пользователя (командой ниже создастся директория с текущей датой с настройками security OpenSearch)

  chmod +x $OS_HOME/plugins/opensearch-security/tools/securityadmin.sh
  JAVA_HOME=$OS_HOME/jdk/ $OS_HOME/plugins/opensearch-security/tools/securityadmin.sh -backup /app/backup/security_$(date +%Y%m%d) \
    -icl \
    -nhnv \
    -cacert $OS_HOME/config/ca-cert.pem \
    -cert $OS_HOME/config/admin-cert.pem \
    -key $OS_HOME/config/admin-key.pem

Обновление OpenSearch

Установщик Smart Monitor 6.2 требуется распаковать в директорию, например, /app/distr/. Куда вы распакуете содержимое архива пометьте как $SM_INSTALLER.

tar xzf smart-monitor-installer-*.tar.gz -C /app/distr/
SM_INSTALLER=/app/distr/sm_6.2

Обратите внимание!

Для кластеров состоящих из нескольких узлов рекомендуется отключать аллокацию перед обновлением через консоль разработчика (Навигационное меню - Параметры системы - Консоль разработчика) выполнив команду:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "none"
  }
}

Сделать тоже самое можно из терминала следующей командой:

curl -XPUT -k -u admin "https://$OS_IP:9200/_cluster/settings?pretty" -H "Content-Type: application/json" -d '{"persistent":{"cluster.routing.allocation.enable": "none"}}'

При обновлении узлов кластера не используйте отключение аллокации с помощью скрипта обновления. После обновления всех узлов кластера включите аллокацию:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}

Сделать тоже самое можно из терминала следующей командой:

curl -XPUT -k -u admin "https://$OS_IP:9200/_cluster/settings?pretty" -H "Content-Type: application/json" -d '{"persistent":{"cluster.routing.allocation.enable": "all"}}'

Автоматический режим

Для работы скрипта потребуется наличие следующих предустановленных пакетов:

• curl
• zip
• unzip

Обратите внимание!

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

Скрипт автоматизирует обновление и находится по пути $SM_INSTALLER/opensearch/setup.sh. Для обновления нужно либо передать ключ update при запуске, либо запустить скрипт без параметров и выбрать соответствующий пункт в интерактивном меню:

Select action [default: update]:
  1) install
  2) update
  3) uninstall

Action [update]:

Скрипт поддерживает следующие параметры запуска:

• <action> — действие: install, update или uninstall (установка, обновление или удаление соответственно)
• -c, --config <path_to_config_file_yaml> - указать конфигурационный файл для обновления
• -h, --help - выводит справку о доступных командах

Пример конфигурационного файла: $SM_INSTALLER/opensearch/example_config_opensearch.yaml. Формат файла YAML аналогичен конфигурационному файлу, используемому при установке.

Обратите внимание!

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

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

$SM_INSTALLER/opensearch/setup.sh update

После запуска скрипт автоматически находит пути основных директорий:

• OpenSearch Home Directory - директория расположения OpenSearch, обычно это /app/opensearch
• OpenSearch Conf Directory - директория расположения конфигурационных файлов OpenSearch, обычно /app/opensearch/config/
• OpenSearch Data Directory - директория расположения данных, обычно /app/data/
• OpenSearch Logs Directory - директория расположения логов, обычно /app/logs/

Скрипт обновления не производит никаких действий с директорией data и logs, а директория конфигурационных файлов и systemd файлы будут сохранены во временную директорию $SM_INSTALLER/opensearch/staging/.

Обратите внимание!

Если запустить скрипт повторно, то директория staging очистится вместе со всеми скопированными директория конфигурационных файлов и systemd файлы.

================================================================================
SMART MONITOR UPDATE SCRIPT - OPENSEARCH
================================================================================

Current working directory: /app/distr/sm_6.2/opensearch

Current name of install's archive: opensearch-3.5.0-linux-x64.tar.gz

New version OpenSearch: 3.5.0

================================================================================
-- STEP 1. INSTALLATION DIRECTORIES

opensearch.service file found. Will get necessary paths from there

Final Opensearch home directory: /app/opensearch
Final Opensearch conf directory: /app/opensearch/config
Final Opensearch data directory: /app/data/opensearch
Final Opensearch logs directory: /app/logs/opensearch
Final Java runtime home: /app/opensearch/jdk
Is this correct? [y/n]:

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

На втором шаге нужно ответить на вопрос по использованию пользователя во время обновления. Если не требуется выводить никакой информации, то введите n, если требуется вывод дополнительной информации введите y.

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

-- STEP 2. GET USER

Do you want to see cluster information or manage allocation? [Y/n] :

================================================================================
Your account must have role "sa-monitoring"
Your account must have permission "cluster:admin/settings/update" for manage allocation
================================================================================

Enter username: admin
Enter password for user "admin":
Is this correct? [y/n]:

Перед запуском setup.sh определите, требуется ли обновление в режиме без прав root. Если такой режим не нужен, сначала выполните необходимые подготовительные команды от имени root, а затем запустите setup.sh от имени пользователя, под которым работает OpenSearch (например, opensearch).

Обратите внимание!

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

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

Запустить установщик от пользователя opensearch можно следующей командой:

sudo -u opensearch $SM_INSTALLER/opensearch/setup.sh update

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

Затем требуется ввести пользователя и группу, под которыми работает OpenSearch.

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

-- STEP 3. DISABLE OPERATIONS WHERE ROOT RIGHTS ARE REQUIRED

Want to update SMART MONITOR without root privileges? [y/N]: y

Final you set the non-root flag to: y

Linux username for SMART MONITOR [opensearch]:
Linux groupname for SMART MONITOR [opensearch]:

Final SMART MONITOR username: opensearch
Final SMART MONITOR groupname: opensearch
Is this correct? [Y/n]:

 ATTENTION!
Before updating SMART MONITOR, you must run the following commands as a user with root privileges.
If yo need to disable allocation, run the following command:

curl -XPUT -k -u YOUR_USER_OPENSEARCH:YOUR_USER_OPENSEARCH_PASSWORD_HERE "https://YOUR_IP_OPENSEARCH:9200/_cluster/settings?pretty" -H "Content-Type: application/json" -d '{"persistent":{"cluster.routing.allocation.enable": "none"}}'

Change user, group and directories as needed

systemctl stop sme-re
systemctl stop opensearch
chown -R opensearch:opensearch /app/opensearch /app/opensearch/config /app/data/opensearch /app/logs/opensearch /app/distr/sm_6.1/opensearch

!!! Are you sure you have done everything from the list above? [y/N]:

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

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

-- STEP 4. CONFIGURE ALLOCATION

Do you want to disable allocation during update? [y/N]: n

You don't want to disable allocation: n
Is this correct? [y/n]:

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

get current list of plugins
sm-core
sm-im
sm-inventory
sm-ism-action-clickhouse
sm-job-scheduler
sm-job-scheduler-actions-incident
sm-job-scheduler-actions-mitre
sm-knowledge-center
sm-mitre
sm-mssp
sm-rsm
sm-uba
sme
opensearch-security
Information about current node OpenSearch:
{
  "name" : "sm-node-00",
  "cluster_name" : "sm-cluster",
  "cluster_uuid" : "3XDKoAAEQUa8h1r73lg2gA",
  "version" : {
    "distribution" : "opensearch",
    "number" : "3.5.0",
    "build_type" : "tar",
    "build_hash" : "6adc0bf476e1624190564d7fbe4aba00ccf49ad8",
    "build_date" : "2025-10-29T17:05:01.906258Z",
    "build_snapshot" : false,
    "lucene_version" : "10.2.2",
    "minimum_wire_compatibility_version" : "2.19.0",
    "minimum_index_compatibility_version" : "2.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

!!! AT THIS POINT WE START TO MAKE CHANGES IN OPERATING SYSTEM !!!
Do you want to continue? [y/N]:

Если нажать Enter - обновление прервется, для продолжения нужно нажать y.

По успешному завершению обновления должны увидеть надпись SMART MONITOR SUCCESSFULLY UPDATED!, предварительно будет выведена информация о кластере и текущем узле, если был выбран на втором шаге использование пользователя при обновлении.

-- STEP 10. PRINT INFORMATION
current state of cluster
{
  "cluster_name" : "sm-cluster",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "discovered_master" : true,
  "discovered_cluster_manager" : true,
  "active_primary_shards" : 50,
  "active_shards" : 50,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 15,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 76.92307692307693
}
current state clusters nodes
172.16.0.27 14 99 8 1.47 0.63 0.26 dim data,ingest,master * sm-node-00
Information about current node OpenSearch:
{
  "name" : "sm-node-00",
  "cluster_name" : "sm-cluster",
  "cluster_uuid" : "5V2rIp1sRj-M-ANnGfF0cA",
  "version" : {
    "distribution" : "opensearch",
    "number" : "3.5.0",
    "build_type" : "tar",
    "build_hash" : "6adc0bf476e1624190564d7fbe4aba00ccf49ad8",
    "build_date" : "2025-10-29T17:05:01.906258Z",
    "build_snapshot" : false,
    "lucene_version" : "10.2.2",
    "minimum_wire_compatibility_version" : "2.19.0",
    "minimum_index_compatibility_version" : "2.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

================================================================================
 ATTENTION!
After updating SMART MONITOR, you must run the following commands as a user with root privileges.
Change user, group and directories as needed.

cp /app/distr/sm_6.2/opensearch/staging/services/sme-re.service /etc/systemd/system/
chown root:root /etc/systemd/system/sme-re.service
chcon -Rv -u system_u -r object_r -t bin_t /app/opensearch/bin
chcon -Rv -u system_u -r object_r -t bin_t /app/opensearch/jdk/bin
chcon -Rv -u system_u -r object_r -t var_run_t /app/opensearch/run
chown -R opensearch:opensearch /app/opensearch /app/opensearch/config /app/data/opensearch /app/logs/opensearch
systemctl daemon-reload
systemctl enable sme-re opensearch
systemctl start sme-re
systemctl start opensearch
systemctl status sme-re opensearch

If you disable allocation before, wait 60 seconds and run the following commands as a "opensearch" or user with root privileges:

curl -XPUT -k -u YOUR_USER_OPENSEARCH:YOUR_ADMIN_PASSWORD_HERE "https://127.0.0.1:9200/_cluster/settings?pretty" -H "Content-Type: application/json" -d '{"persistent":{"cluster.routing.allocation.enable": "all"}}'

The following plugins cannot be installed:
-- sm-job-scheduler-actions-incident
-- sm-job-scheduler-actions-mitre

================================================================================
-- SMART MONITOR SUCCESSFULLY UPDATED!
-- For further instructions, please refer to the documentation: https://docs.smartmonitor.ru
================================================================================

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

Если по какой-то причине скрипт обновления не смог обновить какие-то плагины, то он выведет дополнительно в конце информацию об этих плагинах, как на примере выше (текст The following plugins cannot be installed).

Обратите внимание!

Скрипт обновления учитывает текущий список установленных плагинов на узлах OpenSearch. Если требуется установить какой-нибудь плагин дополнительно, то действие стоит производить вручную в конце обновления узла.

Обновление Smart Monitor Web

Для работы скрипта потребуется наличие следующих предустановленных пакетов:

• curl
• zip
• unzip

Скрипт автоматизирует обновление и находится по пути $SM_INSTALLER/opensearch-dashboards/setup.sh. Для обновления нужно либо передать ключ update при запуске, либо запустить скрипт без параметров и выбрать соответствующий пункт в интерактивном меню:

Select action [default: update]:
  1) install
  2) update
  3) uninstall

Action [update]:

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

• <action> — действие: install, update или uninstall (установка, обновление или удаление соответственно)
• -c, --config <path_to_config_file_yaml> - указать конфигурационный файл для обновления
• -h, --help - выводит справку о доступных командах

Пример конфигурационного файла: $SM_INSTALLER/opensearch-dashboards/example_config_dashboards.yaml. Формат файла YAML аналогичен конфигурационному файлу при установке.

При работе скрипт сделает резервную копию файла сервиса systemd, opensearch-dashboards.yml и директории с конфигурациями во временную директорию $SM_INSTALLER/opensearch-dashboards/staging/. Директории data и logs скрипт не затрагивает.

Обратите внимание!

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

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

$SM_INSTALLER/opensearch-dashboards/setup.sh update

Скрипт автоматически определит основные пути текущего сервера до следующих директорий:

• OpenSearch Dashboards Home Directory - директория расположения OpenSearch Dashboards, обычно это /app/opensearch-dashboards
• OpenSearch Dashboards Conf Directory - директория расположения конфигурационных файлов OpenSearch Dashboards, обычно /app/opensearch-dashboards/config/
• OpenSearch Dashboards Data Directory - директория расположения данных, обычно /app/data/
• OpenSearch Dashboards Logs Directory - директория расположения логов, обычно /app/logs/

================================================================================
SMART MONITOR INSTALL SCRIPT - OPENSEARCH DASHBOARDS
================================================================================

Current working directory: /opt/sm_6.2/opensearch-dashboards

Current name of install's archive: opensearch-dashboards-3.5.0-linux-x64.tar.gz

Current version of OpenSearch-Dashboards: 3.5.0

================================================================================
-- STEP 1. INSTALLATION DIRECTORIES

opensearch-dashboards.service file found. Will get necessary paths from there

Final Opensearch Dashboards home directory: /app/opensearch-dashboards
Final Opensearch Dashboards conf directory: /app/opensearch-dashboards/config
Final Opensearch Dashboards data directory: /app/data/opensearch-dashboards
Final Opensearch Dashboards logs directory: /app/logs/opensearch-dashboards
Is this correct? [y/n]:

После ввода директорий требуется подтвердить введенные данные, нажав y, или ввести свои директории вручную нажав n.

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

Обратите внимание!

Полностью выполнить обновление без root привилегий нельзя, требуется выполнить часть операций от пользователя root, затем запустить установщик от имени пользователя, под которым работает Smart Monitor Web, после завершения работы скрипта снова нужно выполнить некоторые операции от пользователя root. Список операций будет выведен в установщике.

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

Запустить установщик от пользователя opensearch можно следующей командой:

sudo -u opensearch $SM_INSTALLER/opensearch-dashboards/setup.sh update

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

Затем требуется ввести пользователя и группу, под которыми работает Smart Monitor Web.

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

-- STEP 2. DISABLE OPERATIONS WHERE ROOT RIGHTS ARE REQUIRED

Want to update SMART MONITOR without root privileges? [y/N]: y

Final you set the non-root flag to: y

Linux username for SMART MONITOR [opensearch]:
Linux groupname for SMART MONITOR [opensearch]:

Final SMART MONITOR username: opensearch
Final SMART MONITOR groupname: opensearch
Is this correct? [Y/n]:

 ATTENTION!
Before updating SMART MONITOR, you must run the following commands as a user with root privileges.
Change user, group and directories as needed

systemctl stop opensearch-dashboards
chown -R opensearch:opensearch /app/opensearch-dashboards /app/opensearch-dashboards/config /app/data/opensearch-dashboards /app/logs/opensearch-dashboards /app/distr/sm_6.2/opensearch-dashboards

!!! Are you sure you have done everything from the list above? [y/N]:

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

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

Current list of plugins:
-- smartMonitor
-- smartMonitorColumnChart
-- smartMonitorCyberSecurity
-- smartMonitorDrawio
-- smartMonitorHeatmapChart
-- smartMonitorHtmlChart
-- smartMonitorIncidentManager
-- smartMonitorInventory
-- smartMonitorKnowledgeCenter
-- smartMonitorLineChart
-- smartMonitorLookupManager
-- smartMonitorMitreAttack
-- smartMonitorPDFExport
-- smartMonitorPieChart
-- smartMonitorSingleValue
-- smartMonitorTable
-- smartMonitorUserBehaviorAnalytics

Current version of OpenSearch-Dashboards: 3.5.0

!!! AT THIS POINT WE START TO MAKE CHANGES IN OPERATING SYSTEM !!!
Do you want to continue? [y/N]:

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

================================================================================
 ATTENTION!
After updating SMART MONITOR, you must run the following commands as a user with root privileges.
Change user, group and directories as needed.

cp /app/distr/sm_6.2/opensearch-dashboards/staging/services/opensearch-dashboards.service /etc/systemd/system/
chown root:root /etc/systemd/system/opensearch-dashboards.service
chcon -Rv -u system_u -r object_r -t bin_t /app/opensearch-dashboards/bin
chown -R opensearch:opensearch /app/opensearch-dashboards /app/opensearch-dashboards/config /app/data/opensearch-dashboards /app/logs/opensearch-dashboards
systemctl daemon-reload
systemctl enable opensearch-dashboards
systemctl start opensearch-dashboards
systemctl status opensearch-dashboards

================================================================================
-- SMART MONITOR DASHBOARDS SUCCESSFULLY UPDATED!
-- For further instructions, please refer to the documentation: https://docs.smartmonitor.ru
================================================================================

При успешном завершении скрипта обновления будет выведен соответствующий текст SMART MONITOR DASHBOARDS SUCCESSFULLY UPDATED.

Обратите внимание!

Чтобы корректно восстановить работу кластера и сбросить накопленную нагрузку на ресурсы после полного обновления всех узлов, остановите узлы в следующем порядке: SM Data Storage Hot, SM Data Storage Cold, SM Master Node. Затем запустите узлы в следующем порядке: SM Master Node, SM Data Storage Hot, SM Data Storage Cold.

Действия после обновления

Миграция настроек лимитов

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

Миграция кластерных настроек

POST _core/migration/6.2.0/migrate_limits/cluster

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

Старый путь после обновления	Новый путь
archived.sme.core.enable_limits	sme.core.limits.enable_limits
archived.sme.core.check_base_limit	sme.core.limits.check_base_limit
archived.sme.core.max_subsearch_hits_count	sme.core.limits.max_subsearch_hits_count
archived.sme.core.list_limit	sme.core.limits.list_limit
archived.sme.core.sort_limit	sme.core.limits.sort_limit

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

HTTP-код	Сообщение или ситуация	Действие
200	Limit settings migrated successfully	Настройки перенесены.
200	No limit settings found to migrate.	Старых настроек нет, изменений не было.
400	Limit settings migration failed due to invalid values: ...	Проверьте архивные значения, исправьте ошибки и повторите запрос.
409	Another limit settings operation is already in progress on this node.	Дождитесь завершения текущей операции.
500	Ошибка миграции или обращения к кластеру.	Устраните причину ошибки и проверьте состояние настроек.
503	Limit settings migration was not acknowledged	Изменение не подтверждено кластером; перед повтором проверьте фактически сохраненные значения.

Проверьте результат запросом:

GET _cluster/settings?include_defaults=true&flat_settings=true

Убедитесь, что настройки с префиксом sme.core.limits присутствуют и их значения соответствуют исходной конфигурации.

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

После проверки кластерных настроек выполните:

POST _core/migration/6.2.0/migrate_limits/users_roles

При выполнении запроса обрабатываются документы из индекса sme.core.limits.index_name (по умолчанию .sm_sme_limits_user). Запись выполняется постранично, поэтому при ошибке часть документов может быть уже сохранена.

Поле	Изменение
allowed_dt_start, allowed_dt_end	Удаляются при успешном преобразовании временного интервала.
max_command_ram_usage	Удаляется без прямой замены.
max_dt_interval	Добавляется на основе прежних временных границ или сохраняется, если документ уже преобразован.

max_dt_interval задает максимально допустимую продолжительность поискового диапазона в секундах. Прежние allowed_dt_start и allowed_dt_end задавали границы окна, поэтому новый параметр не полностью повторяет их назначение. Например, "allowed_dt_start": "now-7d" и "allowed_dt_end": "now" преобразуются в "max_dt_interval": 604800. Если одна граница отсутствует, используются значения по умолчанию: now-10y для начала и now для конца. Календарные периоды фиксируются на момент миграции.

Ответ содержит массив результатов обработки документов с полями document (идентификатор) и message (результат). Возможные коды ответа:

HTTP-код	Значение
200	Все документы обработаны без ошибок.
404	Documents with limits not found in <index>: поиск выполнен, документы лимитов не найдены.
409	Один или несколько документов требуют ручной корректировки; часть могла быть перенесена.
500	Ошибка преобразования, чтения или записи; возможен частично успешный результат без отката записанных документов. Если есть и ошибки записи, и документы для ручной корректировки, возвращается 500.

Сообщение Migrated successfully. Converted calendar periods are fixed at migration time. означает успешную запись; This document has already been migrated. — что изменения не требуются. Migration requires manual correction: <error> указывает на неподдерживаемое значение, а Migration failed: <error> — на ошибку обработки или записи документа.

При ответе 409 или 500 сохраните результат запроса, определите проблемные документы и проверьте их фактическое содержимое. Исправьте неподдерживаемые значения или причину ошибки, затем при необходимости повторите миграцию. Повторный запуск не пересчитывает max_dt_interval в документах, у которых прежние временные границы уже удалены.

После миграции убедитесь, что в успешно обработанных документах нет полей allowed_dt_start, allowed_dt_end и max_command_ram_usage, а max_dt_interval содержит верную продолжительность в секундах. Документы, требующие ручной корректировки, должны сохранить прежние значения; остальные пользовательские и ролевые настройки не должны измениться.

Перенос настроек файлового хранилища

Начиная с версии 6.2.0, Менеджер инцидентов (IM) и База знаний (KWC) работают с файлами через общие подключения и привязки модулей. Старые настройки больше не читаются: без миграции модули не смогут сохранять файлы и выдавать ранее загруженные. Тип хранилища и его настройки при переносе не меняются.

Один раз после выполните запрос:

POST _core/migration/6.2.0/file_storage

Запрос можно повторить: если у привязки уже выбрано подключение, миграция ее не изменит. Код ответа 200 означает, что ошибок нет; если хотя бы один модуль завершился с failed, возвращается 500. Проверьте modules в ответе:

outcome	Значение
migrated	Подключение создано и выбрано в привязке.
already_configured	Подключение уже было выбрано, привязка не изменена.
skipped	Старые настройки отсутствуют или неполны; причина указана в message.
failed	Миграция завершилась ошибкой; причина указана в message, например имя подключения уже занято.

Пример ответа:

{
  "message": "File storage migration completed",
  "modules": [
    {
      "module": "incident_manager",
      "outcome": "migrated",
      "connection_id": "im_file_storage",
      "message": "Binding now uses connection 'im_file_storage'",
      "warnings": []
    },
    {
      "module": "kwc",
      "outcome": "migrated",
      "connection_id": "kwc_file_storage",
      "message": "Binding now uses connection 'kwc_file_storage'",
      "warnings": ["maxSize is set to 5M: the value of the removed setting plugins.kwc.max_file_size cannot be read, change maxSize in the binding if needed"]
    }
  ]
}

После миграции проверьте подключения и привязки модулей. S3-ключи IM не переносятся: сохраните их повторно в разделе Настройки модулей - Файловое хранилище - Настройки подключений. У KWC значение maxSize теперь составляет 5M вместо прежних 20M по умолчанию. У IM без заданного file_max_size прежнее значение по умолчанию составляло 25M. Если модули должны принимать файлы большего размера, измените maxSize в соответствующей привязке.

Активные действия

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

Настройка главного меню

Удалите устаревший раздел РСМ первой версии с помощью значка корзины справа от него. Затем откройте Навигационное меню - Параметры системы - Настройки модулей - Основное - Настройки меню и нажмите Добавить модуль.

Поле	Значение для модуля
Тип элемента	Группа
Системное имя	active-actions
Заголовок	Активные действия
Включить отображение	Включено

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

Поле	Первая страница	Вторая страница
Тип элемента	Страница	Страница
Системное имя	actions	scripts
Заголовок	Активные действия	Скрипты
Включить отображение	Включено	Включено

Нажмите Сохранить изменения и настройте разрешения согласно принятой политике безопасности.

Перенос интерпретаторов SME

Новые скрипты используют справочник интерпретаторов. Интерпретаторы команды script из кластерной настройки sme.core.remote_script.interpreters автоматически в него не попадают. Один раз после обновления выполните запрос без тела:

POST _core/migration/6.2.0/script_interpreters

Запрос можно повторять: запись с уже существующим именем пропускается. Настройка sme.core.remote_script.interpreters при этом не меняется, и команда script продолжает ее использовать. Если имя встречается несколько раз, применяется последний элемент.

Элементы настройки имеют вид имя::путь, например python3::/usr/bin/python3. Переносятся только интерпретаторы Python или PyPy, в том числе версии и варианты python.exe и pythonw.exe. Например, подходят /usr/bin/python3.11, /usr/bin/python3.13t, /opt/pypy/bin/pypy3 и C:\Python311\python.exe. Не подходят /bin/bash, /usr/bin/node, /usr/bin/ipython, /usr/bin/python3-config и путь, заканчивающийся на /python/. В активных действиях пока поддерживаются только Python-скрипты.

Код ответа 200 означает, что интерпретаторы созданы или уже существовали; если поле failed не пусто, возвращается 500. Проверьте поля ответа:

Поле	Значение и действия
created	Созданные интерпретаторы: имя и ID записи.
already_exists	Имена существующих записей, которые миграция не изменила.
invalid	Некорректные элементы имя::путь либо значения с превышением допустимой длины имени или пути. Исправьте настройку и повторите запрос либо создайте записи вручную.
not_python	Пропущенные интерпретаторы других языков. Для команды script они продолжают работать через прежнюю настройку.
failed	Имена и ошибки создания. Устраните причину и повторите запрос: созданные записи будут пропущены.

Пример ответа:

{
  "message": "Script interpreters migration completed",
  "created": {
    "py311": "v5Dfh6EBqr6UwvBa8Etk",
    "pypy": "wZDfh6EBqr6UwvBa8kul",
    "venv": "w5Dfh6EBqr6UwvBa9kuy"
  },
  "already_exists": ["python3"],
  "invalid": ["broken"],
  "not_python": ["bash::/bin/bash"],
  "failed": {}
}

Обратите внимание!

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

Настройка SME RE

Скрипты активных действий запускаются SME RE через /sme_scripts/v1. Для этого на каждом экземпляре SME RE нужны разрешенные интерпретаторы и хранилище токенов, а на каждом узле OpenSearch — тот же токен в хранилище ключей. Пути в справочнике интерпретаторов должны точно совпадать с разрешенными путями SME RE. Без настройки токена или списка интерпретаторов возможны ошибки 401 auth.unauthorized, 422 interpreter.not_allowed и sme_re.token_missing.

Старые маршруты /sme_remote_exec/* и команда script продолжают работать с учетной записью sme.core.remote_script.user и mTLS по server.ssl.*. Заголовок Sm-Access больше не отключает проверку учетной записи на этих маршрутах.

1. Установите SME RE из состава релиза. При запуске он размещает загрузчик скриптов и пакет sm_actions в sme.scripts.loadersDir (по умолчанию ./loaders). Убедитесь, что в PATH доступна команда kill; в минимальных образах ее предоставляет пакет procps. Отсутствие команды регистрируется как ошибка

2. Создайте случайный токен длиной не менее 32 байт и сохраните его в PKCS12-хранилище SME RE, алиас записи должен начинаться на scripts-token-. Например:

   openssl rand -base64 32
   JAVA_HOME=${OS_HOME}/jdk/ ${JAVA_HOME}/bin/keytool -importpass -storetype PKCS12 -keystore ${OS_HOME}/utils/sme-re/scripts-tokens.p12 -alias scripts-token-cluster1

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

3. Настройте application.properties SME RE (или передайте те же параметры при запуске):

   sme.scripts.interpreters=${OS_HOME}/utils/python/bin/python3,/usr/bin/python3,/opt/venv/bin/python3
   sme.scripts.auth.keystorePath=${OS_HOME}/utils/sme-re/scripts-tokens.p12
   sme.scripts.auth.keystorePassword=${SME_RE_KEYSTORE_PASSWORD:}

   Указывайте путь к настоящему бинарному файлу интерпретатора, например для виртуального окружения bin/python3. Обертка или shim может помешать остановить дочерние процессы по истечении срока выполнения. Для разных наборов библиотек используйте отдельные виртуальные окружения. Скрипт получает только PATH, LANG и собственный HOME; библиотеки в окружение интерпретатора устанавливает администратор.

4. Задайте пароль хранилища в окружении сервиса SME RE, например через Environment="SME_RE_KEYSTORE_PASSWORD=<пароль хранилища>" в unit-файле systemd. Защитите этот файл от постороннего доступа

5. Запишите тот же токен в хранилище ключей каждого узла OpenSearch. Основной способ — запрос к ядру, который обновляет все узлы кластера и сразу перечитывает секретные настройки:

   POST _core/keystore/sm.actions.script.sme_re.token?nodeid=node_with_sme:true
   {
     "value" : "<токен>"
   }

   Если хранилище ключей защищено паролем, добавьте в тело "keystore_password": "<пароль>". Если ключ уже существует, замените значение запросом PUT на тот же путь. Альтернативно добавьте токен вручную на каждом узле командой opensearch-keystore add sm.actions.script.sme_re.token, затем выполните POST _nodes/reload_secure_settings без перезапуска. Пока токена нет, плагин sm-actions-api возвращает sme_re.token_missing, а в журнале узла появляется предупреждение sm.actions.script.sme_re.token is not set in the node keystore.

6. Проверьте кластерные настройки адресов SME RE. Они общие со старой командой script и не требуют повторного создания:

   Настройка	Значение по умолчанию	Описание
   sme.core.remote_script.url	["http://127.0.0.1"]	Список хостов SME RE: вызовы идут по кругу, недоступный хост пропускается.
   sme.core.remote_script.port	18080	Порт SME RE.
   sme.core.remote_script.enable_ssl	true	Обращение к SME RE по HTTPS.

7. Сверьте пути интерпретаторов в справочнике и sme.scripts.interpreters. При несовпадении SME RE возвращает 422 interpreter.not_allowed

Чтобы убедиться в корректности настроек, выполните следующие проверки:

• в журнале SME RE при запуске нет ошибки об отсутствии kill и предупреждения No script tokens are accepted
• в журнале узла OpenSearch нет предупреждения о sm.actions.script.sme_re.token
• пробный запуск скрипта из раздела Активные действия завершается со статусом completed

Для смены токена без простоя добавьте запись scripts-token-<метка> в хранилище каждого SME RE, затем замените токен на узлах OpenSearch запросом PUT _core/keystore/sm.actions.script.sme_re.token или вручную через opensearch-keystore add -f sm.actions.script.sme_re.token на каждом узле и POST _nodes/reload_secure_settings. Когда старый алиас перестанет появляться в журнале SME RE, удалите его:

JAVA_HOME=${OS_HOME}/jdk/ ${JAVA_HOME}/bin/keytool -delete -storetype PKCS12 -keystore ${OS_HOME}/utils/sme-re/scripts-tokens.p12 -alias <старый_алиас>

Миграция подавлений планировщика

В версии 6.2.0 каждая запись подавления хранится отдельным документом в индексе .sm_throttling_v2; появились ручное подавление и исключения, а включение подавления у задания задается флагом throttle.enabled. Записи версии 6.1 находятся в .sm_throttling в виде одного документа с массивом записей на задание. Новый механизм их не читает, поэтому после обновления нужно перенести записи и добавить флаг обычным и SP-заданиям.

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

Поведение до миграции

Узел 6.2 не видит записи, созданные узлом 6.1, до переноса .sm_throttling. При первом выполнении задания на узле 6.2 ранее подавленное событие может один раз пройти в действия задания. После этого узел создаст запись в новом индексе и будет подавлять повторы. Возможно не более одного лишнего срабатывания для каждой активной записи подавления.

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

Добавление флага подавления заданиям

POST _core/migration/6.2.0/enabled_throttled

Запрос добавляет throttle.enabled обычным и SP-заданиям, у которых флага еще нет: true, если задан список полей подавления, иначе false. Работу подавления это не меняет: узлы 6.2 уже вычисляют значение сами. Повторный запуск обрабатывает только задания без флага.

Ответ содержит блоки job для обычных заданий и sp для SP-заданий. Поля job.successful и sp.successful показывают число заданий, у которых не было флага. Значения job.version_conflicts и sp.version_conflicts могут быть ненулевыми, если задания сохраняли во время миграции. В таком случае запустите запрос повторно. При ошибке сначала устраните причину из текста ответа.

Проверьте, что оба запроса возвращают "count": 0:

GET .sm_jsc_jobs/_count
{"query": {"bool": {"must_not": {"exists": {"field": "throttle.enabled"}}}}}

GET .smos_jobs_sp_meta/_count
{"query": {"bool": {"must_not": {"exists": {"field": "job_parameter.throttle.enabled"}}}}}

Перенос записей подавления

POST _core/migration/6.2.0/throttling

Запрос переносит записи из .sm_throttling в .sm_throttling_v2, сохраняя срок действия. Записи с истекшим сроком пропускаются. Старый индекс не меняется и не удаляется; новые записи, которые задания создают во время миграции, уже находятся в .sm_throttling_v2 и не затрагиваются. Повторный запуск перезаписывает перенесенные записи теми же значениями без дублей. Если запрос прервался или вернул ошибку, устраните причину и повторите его.

Ответ содержит число прочитанных документов версии 6.1 (по одному на задание с записями подавления), число перенесенных записей и число пропущенных записей с истекшим сроком.

Сравнение событий

В версии 6.1 значения полей события не сохранялись, поэтому перенесенные записи сравниваются с событиями только по хешу. Для дробных чисел и вложенных объектов в версии 6.2.0 хеш вычисляется иначе: такая запись не сработает, и событие один раз пройдет в действия задания.

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

Проверка нового индекса и удаление старого

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

GET .sm_throttling_v2/_count
{"query": {"term": {"origin": "auto"}}}

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

DELETE _core/migration/6.2.0/throttling/legacy_index

Если .sm_throttling уже отсутствует, запрос вернет 404.

Миграция системной SMTP-конфигурации

В версии 6.2.0 действие Отправка email без параметра smtp_id использует системную SMTP-конфигурацию. Ее нужно создать из почтовых настроек планировщика версии 6.1. Пока системной конфигурации нет, узлы 6.2 продолжают отправлять письма без smtp_id по прежним настройкам; при поэтапном обновлении письма не теряются.

После обновления всех узлов выполните запрос:

POST _core/migration/6.2.0/system_smtp

Миграция переносит хост, порт, пользователя, адрес отправителя, протокол и таймаут из настроек GET _core/settings/job-scheduler. Пароль не переносится: он остается в прежнем ключе хранилища ключей и подставляется автоматически. Если системная SMTP-конфигурация уже есть, миграция ее не меняет; повторный запуск безопасен.

Проверьте системную конфигурацию в разделе Навигационное меню - Параметры системы - Настройки модулей - Job Scheduler - SMTP-конфигурации: ее поля должны соответствовать ответу GET _core/settings/job-scheduler. Нажмите Проверить подключение и убедитесь, что соединение установлено. Затем проверьте задание с действием Отправка email без smtp_id: письмо должно отправиться, а действие email в статистике запуска должно иметь статус done.

Миграция подключения к системной базе данных

Начиная с версии 6.2.0, подключение модуля Inventory к PostgreSQL задается в разделе Навигационное меню - Параметры системы - Настройки модулей - Основное - Системная база данных, а не в блоке postgres глобальных настроек модуля. Прежний блок больше не читается: без миграции обновленный алгоритм расчета не работает, а на странице инициализации Inventory выводится уведомление о ненастроенном подключении.

Узлы версии 6.1 продолжают использовать блок postgres, поэтому выполните запрос без тела после обновления всех узлов:

POST _core/migration/6.2.0/inventory_system_db

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

HTTP-код	outcome	Значение
200	MIGRATED	Настройки подключения перенесены.
200	ALREADY_CONFIGURED	Подключение уже было настроено в разделе Системная база данных и не изменено; блок postgres удален из глобальных настроек.
200	SKIPPED	Переносить нечего; причина указана в reason: inv_settings has no postgres block — блока нет или миграция уже выполнена, inv_settings document not found — Inventory не настраивался, Inventory plugin is not installed — модуль не установлен.
500	FAILED	Миграция завершилась ошибкой; причина указана в reason. Устраните ее и повторите запрос.

Если в версии 6.1 подключение к PostgreSQL не настраивалось, настройте его вручную по инструкции из раздела Подключение к системной базе данных.

Миграция UBA

В версии 6.2.0 UBA использует новую модель данных: объекты становятся активами инвентаризации, типы объектов — категориями, а начисления скоринга — сработками. Новый механизм не читает документы версий 5.3–6.1. Миграция должна перенести объекты, политики, правила реагирования и активные начисления, пересобрать профили и выключить задания старого скоринга. Для всех исходных версий 5.3–6.1 предусмотрена одна миграция.

Планируемый состав запросов POST _core/migration/6.2.0/…:

№	Что переносится	Окончание пути запроса
1	Семейства правил	uba_rule_families
2	Объекты	uba_objects
3	Политики	uba_policies
4	Правила реагирования	uba_reactions
5	Профили	uba_profiles
6	Сработки	uba_alerts
7	Старый скоринг	uba_legacy_scoring

Миграция в разработке

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