Skip to main content
Version: 6.0

Smart Monitor Update

Attention!

This instruction describes the process of updating Smart Monitor from version 5.3.* to 6.0.*.

Attention!

For correct operation of notes and other functionality, you need to create directory $OS_HOME/uploads on Smart Monitor Data Storage nodes, change permissions for the user under which Smart Monitor Data Storage operates, and connect a shared network folder to this directory. Refer to setup article

Information

Conditional designations:

  • SM_INSTALLER - directory where Smart Monitor installation package version 6.0 is extracted
  • USER - system user with administrator rights, usually admin
  • OS_HOME - OpenSearch home directory, usually /app/opensearch/
  • OS_DATA - directory where indexed data is stored, usually /app/data/opensearch
  • OS_IP - IP address of one of the OpenSearch cluster servers
  • OSD_HOME - OpenSearch Dashboards home directory, usually /app/opensearch-dashboards/
  • PATH_SSL - location of certificate, private admin key, and ca-cert, usually coincides with /app/opensearch/config/

The primary step for updating is determining the currently installed Smart Monitor version. This can be done by viewing module versions on the main page or executing a command in the command line:

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

After entering this command, you will need to enter the password for the $USER account. It is recommended to use the admin user.

Detailed list of new features can be viewed in the article What's New in Smart Monitor 6.0.

Let's consider the update procedure for each component. Installer 6.0 needs to be extracted to a directory, for example, /app/distr/.

Attention!

Before starting work, it is strictly recommended to make a backup of main configuration files and Security settings.

It is recommended to create a directory, for example, /app/backup, where you should save:

  • config directory, usually $OS_HOME/config or $OSD_HOME/config

  • systemd files, usually /etc/systemd/system/opensearch.service and /etc/systemd/system/opensearch-dashboards.service, /etc/systemd/system/sme-re.service

  • file /etc/sysctl.d/00-opensearch.conf

  • Security settings backup, this needs to be done once, for which you will need the certificate and private admin user key (the command below will create a directory with the current date with OpenSearch security settings)

    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 Update

Smart Monitor 6.0 installer needs to be extracted to a directory, for example, /app/distr/. Mark where you extract the archive contents as $SM_INSTALLER.

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

For clusters consisting of multiple nodes, it is recommended to disable allocation before updating through the developer console (Navigation Menu - System Settings - Developer Console) by executing the command:

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

You can do the same thing from the terminal with the following command:

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

When updating cluster nodes, do not use allocation disablement with the update script. After updating all cluster nodes, enable allocation:

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

You can do the same thing from the terminal with the following command:

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

Automatic Mode

The script requires the following pre-installed packages to work:

  • curl
  • zip
  • unzip
Attention!

If at the end you don't see the inscription that Smart Monitor has been updated, do not run the update script again, take a screenshot of where the script stopped and contact technical support.

The automatic update script automates actions during updating and is located at $SM_INSTALLER/opensearch/update.sh. When calling the script, you can specify a configuration file $SM_INSTALLER/opensearch/example_config_opensearch.yaml. The YAML file format is similar to the configuration file during installation.

The update script supports the following startup parameters:

  • -c, --config <path_to_config_file_yaml> - specify configuration file for update
  • -h, --help - displays help on available commands
Attention!

Start updating with nodes without master role, data nodes can connect to older versions of master nodes, but not vice versa.

To start the update, run the script:

$SM_INSTALLER/opensearch/update.sh

After launching, the script automatically finds the paths of main directories:

  • OpenSearch Home Directory - OpenSearch installation directory, usually /app/opensearch
  • OpenSearch Conf Directory - OpenSearch configuration files directory, usually /app/opensearch/config/
  • OpenSearch Data Directory - data directory, usually /app/data/
  • OpenSearch Logs Directory - logs directory, usually /app/logs/

The update script does not perform any actions with data and logs directories, and configuration files directory and systemd files will be saved to temporary directory $SM_INSTALLER/opensearch/staging/.

Attention!

If you run the script again, the staging directory will be cleared along with all copied configuration files directory and systemd files.

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

Current working directory: /app/distr/sm_6.0/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
Is this correct? [y/n]:

After entering directories, you need to confirm the automatically found data by pressing y, or enter your directories manually by pressing n.

On the second step, you need to answer the question about using a user during the update. If no additional information output is required, enter n, if additional information output is required, enter y.

User can be used for information output or for allocation management, accordingly different sets of permissions are required. For simple information output, sa-monitoring role permissions are sufficient.

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

On the next step, you can disable all operations requiring privilege escalation to root user.

Attention!

It is impossible to completely perform the update without root privileges, part of operations need to be performed as root user, then run the installer as the user under which OpenSearch operates, after the script finishes, some operations need to be performed again as root user. The list of operations will be displayed in the installer.

If commands are not executed before updating, data loss is possible.

You can run the installer as opensearch user with the following command:

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

The first question will be about disabling commands requiring privilege escalation to root user.

Then you need to enter the user and group under which OpenSearch operates.

Next, information will be displayed with a list of operations that need to be performed before running the update script.

-- 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 you 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.0/opensearch

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

At the end, you need to confirm that all commands were executed as root user. Enter y to confirm or the update will be aborted.

On the next step, if user usage was selected during the update, you need to answer the allocation question. If you enter y, the script will disable allocation before updating and enable it at the end of script operation.

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

Then preparatory actions will be performed before updating, before applying the update, a question about continuing will be asked, until this moment no actions affecting system operability are performed. Also, some information about the current node and cluster as a whole will be displayed, if user usage was selected on the second step.

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

If you press Enter - the update will be interrupted, to continue you need to press y.

Upon successful completion of the update, you should see the inscription SMART MONITOR SUCCESSFULLY UPDATED!, preliminary information about the cluster and current node will be displayed, if user usage was selected on the second step.

-- 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.0/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
================================================================================

If updating without using commands requiring privilege escalation to root user was selected, an informational block with a list of commands that need to be executed as root user will be displayed.

If for some reason the update script could not update some plugins, it will additionally display information about these plugins at the end, as in the example above (text The following plugins cannot be installed).

:::warning[Attention!] The update script takes into account the current list of installed plugins on OpenSearch nodes. If you need to install some plugin additionally, the action should be performed manually at the end of node updating. :::

Smart Monitor Web Update

The script requires the following pre-installed packages to work:

  • curl
  • zip
  • unzip

The automatic update script automates actions during updating and is located at $SM_INSTALLER/opensearch-dashboards/update.sh. When calling the script, you can specify a configuration file $SM_INSTALLER/opensearch-dashboards/example_config_dashboards.yaml. The YAML file format is similar to the configuration file during installation.

The update script supports the following startup parameters:

  • -c, --config <path_to_config_file_yaml> - specify configuration file for update
  • -h, --help - displays help on available commands

When working, the script will make a backup copy of the systemd service file, opensearch-dashboards.yml and configuration directory to temporary directory $SM_INSTALLER/opensearch-dashboards/staging/.

The update script does not perform any actions with data and logs directories, and configuration directory and systemd files will be saved to temporary directory $SM_INSTALLER/opensearch-dashboards/staging/.

Attention!

If you run the script again, the staging directory will be cleared.

To update, run the script:

$SM_INSTALLER/opensearch-dashboards/update.sh

The script will automatically determine the main paths of the current server to the following directories:

  • OpenSearch Dashboards Home Directory - OpenSearch Dashboards installation directory, usually /app/opensearch-dashboards
  • OpenSearch Dashboards Conf Directory - OpenSearch Dashboards configuration files directory, usually /app/opensearch-dashboards/config/
  • OpenSearch Dashboards Data Directory - data directory, usually /app/data/
  • OpenSearch Dashboards Logs Directory - logs directory, usually /app/logs/
================================================================================
SMART MONITOR INSTALL SCRIPT - OPENSEARCH DASHBOARDS
================================================================================

Current working directory: /opt/sm_6.0/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]:

After entering directories, you need to confirm the entered data by pressing y, or enter your directories manually by pressing n.

On the next step, you can disable all operations requiring privilege escalation during updating to root user.

Attention!

It is impossible to completely perform the update without root privileges, part of operations need to be performed as root user, then run the installer as the user under which Smart Monitor Web operates, after the script finishes, some operations need to be performed again as root user. The list of operations will be displayed in the installer.

If commands are not executed before updating, data loss is possible.

You can run the installer as opensearch user with the following command:

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

The first question will be about disabling commands requiring privilege escalation to root user.

Then you need to enter the user and group under which Smart Monitor Web operates.

Next, information will be displayed with a list of operations that need to be performed before running the update script.

-- 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.0/opensearch-dashboards

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

At the end, you need to confirm that all commands were executed as root user. Enter y to confirm or the update will be aborted.

Then preparatory actions will be performed before updating, before applying the update, a question about continuing will be asked, until this moment no actions affecting system operability are performed. Also, some information about the current node will be displayed.

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

If updating without using commands requiring privilege escalation to root user was selected, an informational block with a list of commands that need to be executed as root user will be displayed.

================================================================================
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.0/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
================================================================================

Upon successful completion of the update script, the corresponding text SMART MONITOR DASHBOARDS SUCCESSFULLY UPDATED will be displayed.

Post-Update Actions

RCM

Layer Migration

It is recommended to migrate each RCM layer separately. To get the id, open the layer, it will appear in the browser address bar. To migrate, you need to execute the following queries in the developer console (Navigation Menu - System Parameters - Developer Console):

POST _core/migration/6.0.0/migrate_layers/<id>

To migrate all layers at once, execute the command:

POST _core/migration/6.0.0/migrate_layers

During the migration process, backup copies of layer indexes are created. Pre-check all RCM layers, after which you can delete the backups:

DELETE _core/migration/6.0.0/backup

To begin, delete the first version of the RCM section by clicking the trash icon on the right.

If you haven't created a menu for RCM v2 before, then to add a new module you need to create a navigation menu item, for this open the menu Navigation Menu - System Parameters - Module Settings - Main - Menu Settings. Click the Add Module button. If you already had an RCM v2 module, then rename it according to the settings below.

Fill in the fields for the module as follows:

Field NameContent
Item TypeGroup
System Namersm-v2
TitleRCM
Enable DisplayYes, the flag should be enabled

Inside the RCM module, click the Add Section button.

Fill in the fields for the section as follows:

Field NameContent
Item TypePage
System Nametree
TitleHealth Models
Enable DisplayYes, the flag should be enabled

Inside the RCM module, click the Add Section button.

Fill in the fields for the section as follows:

Field NameContent
Item TypePage
System Namemodels
TitleModel Settings
Enable DisplayYes, the flag should be enabled

Inside the RCM module, click the Add Section button.

Fill in the fields for the section as follows:

Field NameContent
Item TypePage
System Namemetrics
TitleMetrics
Enable DisplayYes, the flag should be enabled

Click the Save Changes button. Edit the permission settings according to your security policy.

The menu item can be added via JSON structure. To do this, open the menu Navigation Menu - System Parameters - Module Settings - Main - Menu Settings, open the JSON Structure tab, add the following fragment to the top list via comma:

{
"itemType": "group",
"name": "rsm-v2",
"title": "RCM",
"enabled": true,
"sections": [
{
"itemType": "page",
"name": "tree",
"title": "Health Models",
"enabled": true
},
{
"itemType": "page",
"name": "models",
"title": "Model Settings",
"enabled": true
},
{
"itemType": "page",
"name": "metrics",
"title": "Metrics",
"enabled": true
}
]
}

Incident Manager Migration

Attention!

If the Incident Manager module is not installed, proceed to the next step.

Field Migration, Creating the First Incident Type

Migration is necessary to transfer the Incident Manager operation to the mode with Incident Types. Before starting work, create backup copies of old field settings in the developer console (Navigation Menu - System Parameters - Developer Console):

POST _core/migration/6.0.0/im_fields_backup

Then execute the field migration:

POST _core/migration/6.0.0/im_fields

After execution, check that all fields from the Incident Card are in Navigation Menu - Module Settings - Incident Manager - Incident Fields, and an incident type with the name Standard Incident Type appears in Incident Types.

In this type, all fields are filled with the previously specified default values. There is a default view where all fields and active actions are available for viewing and editing.

It is recommended to work and check the system's performance, after checking you can delete the field backups:

DELETE _core/migration/6.0.0/im_fields_backup

Adding New Incident Type ID to Search Tasks

To generate new incidents with an incident type, execute the commands sequentially:

POST _core/migration/6.0.0/add_incident_type
POST _core/migration/6.0.0/add_incident_type_sp

Migrating Old Incidents to New Type (Optional)

If you need to transfer existing incidents to use a certain type, execute the following command:

POST _core/migration/6.0.0/old_incidents_type
{
"index": [".smos_incident...*" ] - indexes where incidents are stored, you can use a pattern, but it is recommended not to take large volumes at once. It is advisable to migrate 4-5 weekly partitions at a time
"incident_type_id": "" - identifier of the type to which the selected incidents should be transferred
}