Version: 6.1

Smart Monitor Update

Attention!

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

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

Let's consider the update procedure for each component. Installer 6.1 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.

Recommended Actions

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

Attention!

For clusters consisting of multiple nodes, it is recommended to disable allocation before updating through the developer console (Navigation Menu - 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 script automates the update process and is located at $SM_INSTALLER/opensearch/setup.sh. To update, either pass the update action when running the script, or run the script without arguments and select the appropriate option from the interactive menu:

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

Action [update]:

The script supports the following startup parameters:

<action> - action to perform: install, update, or uninstall
-c, --config <path_to_config_file_yaml> - specify configuration file for update
-h, --help - displays help on available commands

Example configuration file: $SM_INSTALLER/opensearch/example_config_opensearch.yaml. The YAML file format is similar to the configuration file used during installation.

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/setup.sh update

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.1/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/setup.sh update

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.1/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.1/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 script automates the update process and is located at $SM_INSTALLER/opensearch-dashboards/setup.sh. To update, either pass the update action when running the script, or run the script without arguments and select the appropriate option from the interactive menu:

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

Action [update]:

The update script supports the following startup parameters:

<action> - action to perform: install, update, or uninstall
-c, --config <path_to_config_file_yaml> - specify configuration file for update
-h, --help - displays help on available commands

Example configuration file: $SM_INSTALLER/opensearch-dashboards/example_config_dashboards.yaml. The YAML file format is similar to the configuration file used during installation.

The script creates backup copies of the systemd service file, opensearch-dashboards.yml, and the configuration directory in the temporary $SM_INSTALLER/opensearch-dashboards/staging/ directory. The script does not modify the data or logs directories.

Attention!

If the script is run again, the staging directory is cleared and the previous backup is lost. If you need the backup, copy it from this directory before rerunning the script.

To update, run the script:

$SM_INSTALLER/opensearch-dashboards/setup.sh update

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.1/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/setup.sh update

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

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

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

Lookup Manager

Important

After the update, manually remove the obsolete lookup creation page from the main menu.

Go to Main Menu - System Settings - Module Settings - Main - Menu Settings
Expand the Lookup Manager group with the system name lookup-manager
Click the trash icon next to the Lookup Creation page
Click Save Changes

After removal, only the Lookup List page should remain in the Lookup Manager group.

Updating the peval Function

To update the peval random function, run the following request in the Dev Console (Main Menu - System Settings - Dev Console):

POST _core/migration/6.1.0/peval_random_migration

Incident Manager Migration

Important

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

Migrating the `fields` Field from `object` to `flat_object` for `.smos_incident-*` Indexes

Important

After migrating the fields field from object to flat_object, the fields.* fields in the .smos_incident-* index will no longer be available for aggregations.

The migration changes the fields field type from object to flat_object in all indexes whose names match the .smos_incident-* pattern. The operation runs asynchronously. After it starts, the request returns a migration_id, which is used to track the status and perform subsequent operations.

The migration also:

stores service records in the .sm_fields_flat_object_migration index
creates the sm_incidents_template OpenSearch index template, which sets the fields field type to flat_object in new indexes

tip

To view the template, go to System Settings - Index Management - Templates.

Prerequisites

Before starting the migration, make sure that:

Sufficient shard capacity is available. During migration, the source and backup indexes exist at the same time, so the number of shards associated with the migrated indexes temporarily increases approximately twofold. If there are many indexes, the cluster.max_shards_per_node setting or another cluster shard limit may be exceeded

Check the current settings and shard status:

GET /_cluster/settings?include_defaults=true&filter_path=**.max_shards*
GET /_cat/shards?v&h=index,state,docs,store

For instructions on resolving shard limit errors, see Errors While Processing Specific Indexes.

The cluster is operational. The cluster status must be green or yellow. Do not start the migration if the status is red

GET _cluster/health

No other migration is active. Only one migration can run at a time. An attempt to start a second migration returns an error
Sufficient disk space is available. During migration, the source and backup indexes exist at the same time, so their peak disk usage may be approximately twice the original size. The available disk space must be at least equal to the current size of the data being migrated. Allow additional space for segments, service data, and concurrent write operations
No indexes are blocked. Make sure none of the indexes being migrated have the read-only, read_only_allow_delete, or write block enabled. Run the following request to check:

GET .smos_incident-*/_settings/index.blocks*

No backup indexes from a previous migration remain. Before starting, check for indexes with the .backup-.smos_incident- prefix:

GET /_cat/indices/.backup-.smos_incident-*?v

warning

Do not delete the indexes until you have confirmed that they are not associated with an active migration and are not the only remaining copy of the data.

The user has sufficient permissions. The user on whose behalf the migration runs must have permissions to:
- read and write documents
- create and delete indexes
- read and modify index mappings and settings
- create or update an index template

Migration Procedure

The migration must be performed on an index that is not being modified. Therefore, you can run the migration in one of two ways:

Stop all writes to the .smos_incident-* indexes and run the migration according to the instructions below. In this case, the index template is loaded automatically.
Manually run the following request to load the index template:

POST /_core/migration/6.1.0/im_reload_template

Wait until the beginning of the next week. New indexes will then be created with the correct mapping, after which the old indexes can be migrated. Run the migration according to the instructions below.

Migration Instructions

Start the migration

POST /_core/migration/6.1.0/im_fields_to_flat_object

The response returns the migration identifier. Save the migration_id value because it is required for monitoring and subsequent operations.

{
   "migration_id": "Pte3ZJ8BL4fIwRYMyNYo",
   "status": "ACCEPTED"
}

Monitor the migration

GET /_core/migration/6.1.0/im_fields_to_flat_object/{migration_id}

The status field in the response can have the following values:

Status	Description
`ACCEPTED`	The migration has been accepted but has not started
`RUNNING`	Indexes are being processed
`COMPLETED`	All indexes have been migrated successfully
`COMPLETED_WITH_ERRORS`	Some indexes were migrated, while others failed
`FAILED`	The migration could not start

The indices field contains the status of each index:

Index Status	Description
`RUNNING`	The index is being processed
`COMPLETED`	The index was migrated successfully
`SKIPPED`	The index was skipped
`FAILED`	An error occurred while processing it

The errors_by_index field contains a detailed error description for each index.

Wait for one of the following final statuses:

for COMPLETED, proceed to verify the results and clean up
for COMPLETED_WITH_ERRORS, review errors_by_index, restore or reprocess the affected indexes, and then perform cleanup
for FAILED, resolve the cause of the error before restarting the migration

Clean up after a successful migration

info

After receiving the COMPLETED status, check the mapping and document count for each migrated index:

GET .smos_incident-*/_mapping?filter_path=*.mappings.properties.fields
GET .backup-.smos_incident-*/_mapping?filter_path=*.mappings.properties.fields

GET /<index_name>/_count
GET /.backup-<index_name>/_count

After the migration is complete, delete the backup copies after confirming that they do not contain the only remaining copy of the data:

DELETE /_core/migration/6.1.0/im_fields_to_flat_object/{migration_id}/backups

Delete the service records associated with this migration from the .sm_fields_flat_object_migration index. Run this request after deleting the backup copies. Backup copies of indexes whose migration failed are not deleted.

DELETE /_core/migration/6.1.0/im_fields_to_flat_object/{migration_id}/cleanup

Potential Errors and Solutions

Errors Before Index Processing Starts

Error creating or updating the template

Cause. The user has insufficient permissions, index creation is blocked at the cluster level, or the existing template conflicts with the template being created.

Solution. Check the existing template and the user's permissions. Do not delete the existing template until you have confirmed that it is not used by other indexes or system components. After resolving the cause, restart the migration.

Another migration is already running

Cause. A migration with a different migration_id is already running.

Solution. Check the status of the active migration:

GET /_core/migration/6.1.0/im_fields_to_flat_object/{migration_id}

Errors While Processing Specific Indexes

When an error occurs, the index receives the FAILED status and the migration continues processing the remaining indexes.

Reindexing errors

Possible causes include insufficient resources during reindexing or a document count mismatch after reindexing is complete. Depending on the migration stage, the data is located in either the source or backup index. Review the error details in errors_by_index, and restart the migration.

Error while creating the migrated index

This error occurs if the source index was deleted but the new index was not created or reindexing into it was not completed. All data is stored in the .backup-<index_name> backup index.

Required actions:

Make sure that the backup index exists and contains data:
```
GET .backup-<index_name>/_count
```

Manually create the source index with the required mapping and reindex the data from the backup:

POST _reindex
{
  "source": { "index": ".backup-<index_name>" },
  "dest":   { "index": "<index_name>" }
}

If the index being migrated contains a large amount of data, create an index with the original mapping and restart the migration after resolving the cause of the error.

Shard count limit exceeded

Cause. The cluster shard limit described in Prerequisites has been exceeded.

Solution. Free unused shards or temporarily increase the corresponding limit. If cluster operating policies do not allow the limit to be increased, restart the migration until all indexes have been processed. Before each restart, delete the backup copies of successfully migrated indexes.

Scroll context expired

Cause. Reindexing is performed in batches using the Scroll API. If processing the next batch takes longer than the Scroll context lifetime, OpenSearch deletes the context and the operation fails.

Solution. Reduce the cluster load. After the current migration stops, delete the incomplete backup index and restart the migration.

Index skipped

The cause is specified in the message field. An index is usually skipped if the fields field is missing or already has the flat_object type.

Backup index already exists

Cause. A previous migration failed after creating the backup index but before deleting it.

Solution.

make sure that no other migration is running
check the existence and contents of the corresponding backup index
delete the backup index only if it does not contain the only remaining copy of the data
restart the migration

Index is blocked

Solution. If necessary, remove the write or metadata modification blocks configured for the index.

Errors After Migration Completion

Backup copies cannot be deleted.

If the deletion request returns errors in the errors field, resolve them or delete the backup indexes manually:

DELETE /.backup-<index_name>

The service index cannot be cleaned up.

If the request fails, you can delete the records manually. Before deleting them, make sure that the migration completed successfully:

POST /.sm_fields_flat_object_migration/_delete_by_query
{
  "query": {
    "term": { "migration_id.keyword": "<migration_id>" }
  }
}

Configuring SLA Scripts

To run the selected scripts in SLA policies, specify the Smart Monitor URL in the cluster settings:

PUT _cluster/settings
{
  "persistent": {
    "sm.im.adhoc.url": "https://example.com:8080"
  }
}

IM: Content Configuration

Version 6.1.0 adds an SLA statistics dashboard and updates the incident statistics dashboard.

To install the updates:

Go to Main Menu - Module Settings - Content Management
Select the Incident Manager module
Select version sm_incident_manager_system_6.1.0
Follow the installation instructions

To view the SLA statistics dashboard, the user must have the search permission for the .sm_im_sla_states-* index.

RSM

Important

If you have purchased a Service Monitor Toolkit license, proceed to the next step.

Starting with this release, the RSM 1.0 module is no longer supported. In the remainder of this documentation, RSM refers to RSM 2.0. Before migrating and updating, make sure that the data has been migrated successfully and is no longer associated with the RSM 1.0 module.

If you have not previously created a menu for RSM, create a navigation menu item to add the new module. Go to Main Menu - System Settings - Module Settings - Main - Menu Settings, and click Add Module. If the RSM module already exists, rename it according to the settings below.

Complete the module fields as follows:

Field Name	Value
Item Type	Group
Title	RSM
System Name	rsm
Enable Display	Yes, the checkbox must be selected

If you have a menu item associated with the first version of RSM, delete it.

Service Monitor Toolkit

Service Monitor Toolkit Migration: Adaptive Metrics

Important

If the Service Monitor Toolkit module is not installed or you do not have a license, skip this step.

To update the data storage schema, run the following requests in the Developer Console (Main Menu - System Settings - Developer Console):

POST _core/migration/6.1.0/base_metric_permissions
{
  "backup_index": ".sm_rsm_v2_metrics_permissions_migration_backup",
  "owner": "admin",
  "read": {"roles": [], "users": ["*"]},
  "write": {"roles": ["*"], "users": []},
  "overwrite_permissions": false
}


POST _core/migration/6.1.0/adaptive_models_v1_to_v2
{
  "backup_index": ".sm_rsm_v2_adaptive_parameters_migration_backup",
  "delete_existing_backup": true
}

If you have not previously created a menu for Service Monitor Toolkit, create a navigation menu item to add the new module. Go to Main Menu - System Settings - Module Settings - Main - Menu Settings, and click Add Module. If the Service Monitor Toolkit module already exists, rename it according to the settings below.

Complete the module fields as follows:

Field Name	Value
Item Type	Group
Title	Service Monitor Toolkit
System Name	rsm
Enable Display	Yes, the checkbox must be selected

Starting with version 6.1.0, two new sections are available: Maintenance Windows and Adaptive Models.

In the Service Monitor Toolkit module, click Add Section, and complete the fields for Maintenance Windows as follows:

Field Name	Value
Item Type	Page
Title	Maintenance Windows
System Name	maintenance
Enable Display	Yes, the checkbox must be selected

In the Service Monitor Toolkit module, click Add Section, and complete the fields for Adaptive Models as follows:

Field Name	Value
Item Type	Page
Title	Adaptive Models
System Name	adaptive-models
Enable Display	Yes, the checkbox must be selected

Information​

Recommended Actions​

OpenSearch Update​

Automatic Mode​

Smart Monitor Web Update​

Post-Update Actions​

Lookup Manager​

Updating the peval Function​

Incident Manager Migration​

Migrating the fields Field from object to flat_object for .smos_incident-* Indexes​

Configuring SLA Scripts​

IM: Content Configuration​

RSM​

Service Monitor Toolkit​

Service Monitor Toolkit Migration: Adaptive Metrics​

Updating the Main Menu​

Information

Recommended Actions

OpenSearch Update

Automatic Mode

Smart Monitor Web Update

Post-Update Actions

Lookup Manager

Updating the peval Function

Incident Manager Migration

Migrating the `fields` Field from `object` to `flat_object` for `.smos_incident-*` Indexes

Configuring SLA Scripts

IM: Content Configuration

RSM

Service Monitor Toolkit

Service Monitor Toolkit Migration: Adaptive Metrics

Updating the Main Menu