Updating Smart Monitor
This instruction describes the process of updating Smart Monitor from version 4.2.* to 4.3.*.
Information
Conventions:
SM_INSTALLER- the directory where theSmart Monitorversion 4.3 installation package is unpacked.USER- a system user with administrator rights, usuallyadmin.OPENSEARCH_HOME- the OpenSearch home directory, usually/app/opensearch/.OPENSEARCH_DATA- the directory where indexed data is stored, usually/app/data/.OSD_HOME- the OpenSearch Dashboards home directory, usually/app/opensearch-dashboards/.PATH_SSL- the location of the certificate, theadminprivate key, and theca-cert, usually/app/opensearch/config/.
The first step in updating is to determine the currently installed version of Smart Monitor. This can be done by viewing the module versions on the main page or by running the following command in the command line:
curl https://$OPENSEARCH_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.
A detailed list of new features can be found in the article What's New in Smart Monitor 4.3.
Let's consider the update procedure for each component. The 4.2 installer needs to be unpacked into a directory, for example, /app/distr/.
Before starting work, it is strongly recommended to back up the main configuration files and Security settings.
Recommended Actions
It is recommended to create a directory, for example, /app/backup, where you should save:
-
The
configdirectory, usually$OPENSEARCH_HOME/configor$OSD_HOME/config. -
The
systemdfiles, usually/etc/systemd/system/opensearch.serviceand/etc/systemd/system/opensearch-dashboards.service,/etc/systemd/system/sme-re.service. -
The file
/etc/sysctl.d/00-opensearch.conf. -
A copy of the Security settings. This needs to be done once, and requires the certificate and private key of the admin user. (The command below will create a directory with the current date containing the 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
Updating OpenSearch
The Smart Monitor 4.3 installer needs to be unpacked into a directory, for example, /app/distr/. The location where you unpack the archive contents will be referred to as $SM_INSTALLER.
SM_INSTALLER=/app/distr/sm_4.3
For clusters consisting of multiple nodes, it is recommended to disable allocation before upgrading. This can be done through the developer console (Main Menu - Settings - Dev Console) by executing the following command:
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
}
The same can be done from the terminal with the following command:
curl -XPUT -k -u admin "https://$OPENSEARCH_IP:9200/_cluster/settings?pretty" -H "Content-Type: application/json" -d '{"persistent":{"cluster.routing.allocation.enable": "none"}}'
When upgrading cluster nodes, do not use the update script to disable allocation. After upgrading all cluster nodes, enable allocation:
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}
The same can be done from the terminal with the following command:
curl -XPUT -k -u admin "https://$OPENSEARCH_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:
curlzipunzip
If you do not see the message indicating that Smart Monitor has been updated at the end, do not rerun the update script. Take a screenshot of where the script stopped and contact technical support.
The automatic update script automates the update process and is located at $SM_INSTALLER/opensearch/update.sh. You can specify a configuration file $SM_INSTALLER/opensearch/example_config_opensearch.yaml when calling the script. The file format is YAML and is similar to the configuration file used during installation.
The update script supports the following launch parameters:
-c, --config <path_to_config_file_yaml>- specify the configuration file for the update-h, --help- displays help information about available commands
Start the upgrade with nodes that do not have the 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 to the main directories:
OpenSearch Home Directory- the OpenSearch installation directory, usually/app/opensearchOpenSearch Conf Directory- the OpenSearch configuration files directory, usually/app/opensearch/config/OpenSearch Data Directory- the data directory, usually/app/data/OpenSearch Logs Directory- the logs directory, usually/app/logs/
The update script does not perform any actions with the data and logs directories. The configuration files directory and systemd files will be saved to a temporary directory $SM_INSTALLER/opensearch/staging/.
If you run the script again, the staging directory will be cleared.
================================================================================
SMART MONITOR UPDATE SCRIPT - OPENSEARCH
================================================================================
Current working directory: /app/distr/sm_4.3/opensearch
Current name of install's archive: opensearch-2.18.0-linux-x64.tar.gz
New version OpenSearch: 2.18.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 the directories, you need to confirm the automatically found data by pressing y, or enter your directories manually by pressing n.
In the second step, you need to answer the question about allocation. If you enter y, the script will disable allocation before the update and enable it at the end of the script.
-- STEP 2. 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]:
In the third step, you will need to enter the password for the admin user. The password will not be displayed while typing.
-- STEP 3. GET ADMIN PASSWORD
Enter password for user "admin":
If you enter an incorrect password, the allocation will not be disabled even if selected in the previous step, and information about the current node will not be displayed. However, the update will not be interrupted.
Then, preparatory actions will be performed before the update. Before applying the update, you will be asked to continue. No changes are made to the system until this point. Some information about the current node and the cluster as a whole will also be displayed.
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" : "smos-node-00",
"cluster_name" : "smos-cluster",
"cluster_uuid" : "yKPPDCHGSA6rHQT948jokQ",
"version" : {
"distribution" : "opensearch",
"number" : "2.18.0",
"build_type" : "tar",
"build_hash" : "99a9a81da366173b0c2b963b26ea92e15ef34547",
"build_date" : "2024-10-31T19:08:39.157471098Z",
"build_snapshot" : false,
"lucene_version" : "9.12.0",
"minimum_wire_compatibility_version" : "7.10.0",
"minimum_index_compatibility_version" : "7.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]:
Pressing Enter will interrupt the update; press y to continue.
Upon successful completion of the update, you should see the message SMART MONITOR SUCCESSFULLY UPDATED!. Information about the cluster and the current node will be displayed beforehand.
-- STEP 10. PRINT INFORMATION
current state of cluster
{
"cluster_name" : "smos-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 * smos-node-00
Information about current node OpenSearch:
{
"name" : "smos-node-00",
"cluster_name" : "smos-cluster",
"cluster_uuid" : "5V2rIp1sRj-M-ANnGfF0cA",
"version" : {
"distribution" : "opensearch",
"number" : "2.18.0",
"build_type" : "tar",
"build_hash" : "99a9a81da366173b0c2b963b26ea92e15ef34547",
"build_date" : "2024-10-31T19:08:39.157471098Z",
"build_snapshot" : false,
"lucene_version" : "9.12.0",
"minimum_wire_compatibility_version" : "7.10.0",
"minimum_index_compatibility_version" : "7.0.0"
},
"tagline" : "The OpenSearch Project: https://opensearch.org/"
}
The following plugins cannot be installed:
-- sm-job-scheduler-actions-incident
-- sm-job-scheduler-actions-mitre
================================================================================
-- SMART MONITOR SUCCESSFULLY UPDATED!
================================================================================
```==========================================================================
If for some reason the update script was unable to update some plugins, it will display additional information about these plugins at the end, as in the example above (the text The following plugins cannot be installed).
Note that the update script takes into account the current list of installed plugins on OpenSearch nodes. If you need to install any additional plugins, you should do this manually at the end of the node update.
UpdatingOpenSearch Dashboards
This script automates the OpenSearch Dashboards update process. It requires the following pre-installed packages:
curlzipunzip
The automatic update script is located at $SM_INSTALLER/opensearch-dashboards/update.sh. You can specify a configuration file using $SM_INSTALLER/opensearch-dashboards/example_config_dashboards.yaml. The file format is YAML and is identical to the installation configuration file.
The update script supports the following parameters:
-c, --config <path_to_config_file_yaml>- Specifies the configuration file for the update.-h, --help- Displays help information about available commands.
During execution, the script backs up the systemd service file, opensearch-dashboards.yml, and the configuration directory to a temporary directory: $SM_INSTALLER/opensearch-dashboards/staging/.
The update script does not modify the data and logs directories. The configuration directory and systemd files are backed up to the temporary directory $SM_INSTALLER/opensearch-dashboards/staging/.
Running the script again will clear the staging directory.
To update, run the script:
$SM_INSTALLER/opensearch-dashboards/update.sh
The script automatically detects the main paths on the current server for the following directories:
OpenSearch Dashboards Home Directory- The OpenSearch Dashboards installation directory, typically/app/opensearch-dashboardsOpenSearch Dashboards Conf Directory- The OpenSearch Dashboards configuration directory, typically/app/opensearch-dashboards/config/OpenSearch Dashboards Data Directory- The data directory, typically/app/data/OpenSearch Dashboards Logs Directory- The logs directory, typically/app/logs/
================================================================================
SMART MONITOR INSTALL SCRIPT - OPENSEARCH DASHBOARDS
================================================================================
Current working directory: /opt/sm_4.3/opensearch-dashboards
Current name of install's archive: opensearch-dashboards-2.18.0-linux-x64.tar.gz
Current version of OpenSearch-Dashboards: 2.18.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 the directories are displayed, confirm the information by pressing y, or enter your directories manually by pressing n.
The script then performs preparatory actions for the update. Before applying the update, it prompts for confirmation. Up to this point, no actions affecting the system's operability are performed. Information about the current node and the cluster will also 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: 2.18.0
!!! AT THIS POINT WE START TO MAKE CHANGES IN OPERATING SYSTEM !!!
Do you want to continue? [y/N]:
Upon successful completion of the update script, the following message is displayed: SMART MONITOR DASHBOARDS SUCCESSFULLY UPDATED.
Migration of System Search Jobs, Dashboards, and Tags
In version 4.3, a single index is used to store system and user search jobs, dashboards, and tags. To migrate, open the developer console (Main Menu - System Settings - Developer Console).
To migrate system search jobs, execute:
POST /_reindex
{
"source":{
"index":".sm_jsc_jobs_system"
},
"dest":{
"index":".sm_jsc_jobs"
}
}
After the migration is complete, you can delete the old index:
DELETE .sm_jsc_jobs_system
To migrate system dashboards, execute:
POST /_reindex
{
"source":{
"index":".sm_dashboards_system"
},
"dest":{
"index":".sm_dashboards"
}
}
After the migration of system dashboards is complete, you can delete the old index:
DELETE .sm_dashboards_system
To migrate system tags, execute:
POST /_reindex
{
"source":{
"index":".sm_sme_tags_system"
},
"dest":{
"index":".sm_sme_tags"
}
}
After the migration of system tags is complete, you can delete the old index:
DELETE .sm_sme_tags_system
Storage Format for Multi-Select Fields in Search Jobs
The migration stage for the multi-select storage format in search jobs should be performed only after migrating the system search jobs in the previous stage.
In version 4.3, the storage format for multi-select fields has changed. First, create a copy of the current search jobs index. To migrate to the new format, open the developer console (Main Menu - System Settings - Developer Console) and execute the command:
POST _reindex
{
"source":{
"index":".sm_jsc_jobs"
},
"dest":{
"index":".sm_jsc_jobs_backup"
}
}
After the copy is created, delete the old index:
DELETE .sm_jsc_jobs
Then perform the migration:
POST _reindex
{
"source":{
"index":".sm_jsc_jobs_backup"
},
"dest":{
"index":".sm_jsc_jobs"
},
"script": {
"source": """
void updateMvFields(Map map) {
Map changedFields = new HashMap();
for (entry in map.entrySet()) {
if (entry.getValue() instanceof List || entry.getValue() instanceof Set) {
Set tmpValues = new HashSet();
for (custom_field in entry.getValue()) {
if (custom_field instanceof Map) {
tmpValues.add(custom_field.get("label"));
}
}
changedFields.put(entry.getKey(), tmpValues)
}
}
map.putAll(changedFields);
}
for (action in ctx._source.actions) {
if (action.containsKey("incident")) {
if (action.incident.containsKey("custom_fields")) {
updateMvFields(action.incident.get("custom_fields"));
}
}
}
""",
"lang": "painless"
}
}
Incident Indices
Version 4.3 introduced the ability to change the index for recording incidents using suffixes. To do this, open the developer console (Main Menu - System Settings - Developer Console) and execute the command:
POST _core/im_settings/incident_indexes
{
"suffixes":[]
}
Limiting Lookup Size in RAM
Starting from version 4.2.1, limits were introduced on the RAM usage of lookups during their execution. If you have Smart Monitor version 4.2.1 or higher, this action was performed earlier and does not need to be repeated. To set the parameter, open the developer console (Main Menu - System Settings - Developer Console) and execute the command:
PUT _core/limits_user/base_limit
{
"max_lookup_size": 500000000
}
Migration of Navigation Menu Settings
Version 4.3 introduced the ability to configure a role-based model for the navigation menu. Open the developer console (Main Menu - System Settings - Developer Console) and execute the command:
DELETE .sm_nav_settings
Then execute the migration script below:
POST _reindex
{
"source": {
"index": ".sm_settings",
"query": {
"term": {
"_meta.id.keyword": {
"value": "nav-settings"
}
}
}
},
"dest": {
"index": ".sm_nav_settings"
},
"script": {
"source": """
void updateNavigationItem(Map item, List sections) {
if (item.containsKey("itemType")) {
String itemType = item.get("itemType");
if (itemType.equals("single")) {
item.put("itemType", "dashboard");
}
if (itemType.equals("module")) {
item.put("itemType", "group");
}
if (itemType.equals("group")) {
if (item.containsKey("group-sections")) {
renameToSections(item, "group-sections");
}
}
if (itemType.equals("dashboard")) {
if (item.containsKey("dashboard-parts")) {
renameToSections(item, "dashboard-parts");
}
}
if (itemType.equals("dropdown")) {
item.put("itemType", "group");
if (item.containsKey("dropdown-parts")) {
renameToSections(item, "dropdown-parts");
}
}
List itemSections = item.get("sections");
if (itemSections != null && itemSections.size() != 0) {
List innerSections = new ArrayList();
for (Map innerItem : itemSections) {
updateNavigationItem(innerItem, innerSections);
}
if (innerSections.size() != 0) {
item.put("sections", innerSections);
}
}
sections.add(item);
}
}
void renameToSections(Map item, String key) {
def oldValue = item.get(key);
item.put("sections", oldValue);
item.remove(key);
}
List data = ctx._source.data;
List updatedData = new ArrayList();
for (Map navItem : data) {
updateNavigationItem(navItem, updatedData)
}
ctx._source.data = updatedData;
"""
}
}
For proper user access management in the system, it is recommended to configure the role-based model.
To configure the role-based model:
- navigate to
Main Menu-System Settings-Security Settings-Roles, where all available roles are displayed - create a new role or edit an existing one, setting cluster and index permissions
- assign the role to the appropriate users in the
Userssection
More detailed information on creating and configuring roles is available in the corresponding article on configuring the role-based model.