Validate the Installation

Follow the steps below to validate that the installation was successful.

Opensearch/Elasticsearch requires Java11. Java 11 is included with the installation of the RPM packages as a dependency.

If Opensearch/Elasticsearch fails to start due to an incorrect Java/JDK version, follow these steps.

Run the following command to configure the system to use the new Java version:
```
alternatives --config java
```
This command prompts you to select which 'java' should be in the system PATH. At the prompt, type the number which corresponds with the Java 11 installation. For example, if the prompt includes:
```
Selection    Command
-----------------------------------------------
*+ 1         java-8-openjdk.x86_64 (/usr/lib/jvm/java-8-openjdk-8.1.0.7-0.el7_6.x86_64/bin/java)
+ 2          java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.5.10-0.el7_7.x86_64/bin/java
```
Press 2 and hit Enter. To confirm the change has taken effect, run the following command:
```
java -version
```
The output should show the latest version of openjdk. This version will be at least 11.0.5.
For versions of Moogsoft Enterprise up to and including v8.1.x:
```
service elasticsearch restart
```
For versions of Moogsoft Enterprise at least v8.2.x:
```
service opensearch restart
```

Perform the following steps to ensure that Moogsoft Enterprise v7.3 has been successfully installed or upgraded:

Check that the UI login page displays "Version 8.x" at the bottom.
Log into the UI with username "admin" and password "admin". You should change the default username and password when you have logged in for the first time.
Select the Help icon (question mark) > Support Information. Check that the System Information shows "Version 8.x" and the correct schema upgrade history if you have performed an upgrade.

Note

If you have already completed this step previously (as part of this upgrade process) on the current host, you can skip this step.

Run the Install Validator utility to ensure that all Moogsoft Enterprise files were deployed correctly in $MOOGSOFT_HOME:

$MOOGSOFT_HOME/bin/utils/moog_install_validator.sh

Run this utility to confirm that all Apache Tomcat files were deployed correctly in $APPSERVER_HOME:

$MOOGSOFT_HOME/bin/utils/tomcat_install_validator.sh

If there are webapp differences, run the following command to extract the webapps with the correct files:

$MOOGSOFT_HOME/bin/utils/moog_init_ui.sh -w

Note

If you have already completed this step previously (as part of this upgrade process) on the current host, you can skip this step.

Run the Database Validator utility to validate the database schema:

$MOOGSOFT_HOME/bin/utils/moog_db_validator.sh

Note

Some schema differences are valid, for example those related to custom_info (new columns added etc).

An additional schema upgrade step is required if you are upgrading from v7.0.x, v7.1.x, or v7.2.x.

This additional step is documented on the Post-upgrade steps page.

Until you have complete this step, you should expect to see the following differences in the output of the Database Validator utility:

Differences found in 'historic_moogdb' tables:
41,49c41,43
<   primary key (`alert_id`),
<   unique key `idx_signature` (`signature`),
<   key `idx_first_event_time` (`first_event_time`),
<   key `idx_state_last` (`state`,`last_state_change`),
<   key `idx_severity` (`severity`,`state`),
<   key `idx_agent` (`agent`(12)),
<   key `idx_source` (`source`(12)),
<   key `idx_type` (`type`(12)),
<   key `idx_manager` (`manager`(12))
---
>   primary key (`signature`),
>   key `alert_id` (`alert_id`),
>   key `first_event_time` (`first_event_time`,`alert_id`)
93,94c87
<   key `timestamp` (`timestamp`,`type`),
<   key `idx_type_time` (`type`,`timestamp`)
---
>   key `timestamp` (`timestamp`,`type`)
241,242c234
<   key `sig_id` (`sig_id`,`action_code`,`timestamp`),
<   key `idx_action_sig` (`action_code`,`sig_id`)
---
>   key `sig_id` (`sig_id`,`action_code`,`timestamp`)

The differences above will not have any functional impact, but you must complete the rest of the upgrade to ensure the system is performant and the schema is ready for future upgrades.

If you have performed an upgrade and you see errors similar to the following:

Differences found in 'moogdb' tables:
57a58
>  key 'filter_id' ('filter_id'),
194a196
>  key 'enrichment_static_mappings_ibfk_1' ('eid'),
1196a1199
>  key 'sig_id' ('sig_id'),
1325a1329
>  key 'filter_id' ('filter_id'),

Run the following commands to resolve these index-related problems:

mysql moogdb -u root -e "alter table alert_filters_access drop key filter_id"
mysql moogdb -u root -e "alter table situation_filters_access drop key filter_id"
mysql moogdb -u root -e "alter table enrichment_static_mappings drop key enrichment_static_mappings_ibfk_1"
mysql moogdb -u root -e "alter table sig_stats_cache drop key sig_id"

Validate a high availability installation

Follow these instructions to validate a high availability (HA) installation:

Run the Apache Tomcat install validator utility on any UI server where apache-tomcat is installed and running. In a standard HA installation, apache-tomcat is running on the UI 1 and UI 2 servers.
See Set Up the User Interface Role for HA for more information.
For a non-root deployment of Moogsoft Enterprise, run the database validator utility once on any server.
For an RPM deployment, run the utility on the server with the moogsoft-db package installed.
See Set Up the Database for HA for more information.
Run the install validator utility on any server that has a running Moogsoft Enterprise component.
Run the ha_cntl utility on all HA servers before data is ingested into the system to make sure all expected HA components are running successfully.

Validate the database settings

When you have finished installing Moogsoft Enterprise, you should tune and validate your database settings. The appropriate settings for your database will vary depending on your system, deployment, database type and other factors. This topic provides general guidance on the following scenarios:

Scenario 1: You are setting up a production environment with a Percona XtraDB Cluster and have used the install_percona_nodes script to create the cluster.
Scenario 2: You are setting up a production environment with a Percona XtraDB Cluster, but have not used the install_percona_nodes script to create the cluster.
Scenario 3: You are setting up a non-production or QA environment with MySQL Community.

Scenario 1

In the install_percona_nodes script, the Percona nodes are deployed with the following my.cnf file:

[mysqld]
# GENERAL #
basedir                        = /usr/
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /var/run/mysqld/mysqld.sock
pid-file                       = /var/run/mysqld/mysqld.pid
port                           = 3306

# MyISAM #
key-buffer-size                = 32M
myisam-recover-options         = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 128M
max-connect-errors             = 1000000

# DATA STORAGE #
datadir                        = /var/lib/mysql/

# CACHES AND LIMITS #
tmp-table-size                 = 32M
max-heap-table-size            = 32M
query-cache-type               = 0
query-cache-size               = 0
max-connections                = 500
thread-cache-size              = 128
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 8000
max_prepared_stmt_count        = 1048576
group_concat_max_len           = 1048576

# INNODB #
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = <VARIABLE>
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table          = 1
innodb-buffer-pool-size        = <VARIABLE>
innodb_buffer_pool_instances   = <VARIABLE>
innodb_autoinc_lock_mode       = 2

# LOGGING #
log-timestamps                 = SYSTEM
log-error                      = /var/log/mysql-error.log
log-queries-not-using-indexes  = 0
slow-query-log-file            = /var/log/mysql-slow.log
slow-query-log                 = 0

# REPLICATION #
binlog_format                  = ROW
sync_binlog                    = 0

# PERF #
performance_schema             = ON

# Moogsoft MySQL 5.6 optimizations
default_tmp_storage_engine     = MyISAM

# wsrep settings
wsrep_provider                 = /usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address          = gcomm://
wsrep_log_conflicts
wsrep_cluster_name             = pxc-cluster
wsrep_node_name                = pxc-node-$(hostname)
pxc_strict_mode                = ENFORCING
wsrep_sst_method               = xtrabackup-v2
wsrep_sst_auth                 = "<VARIABLE>:<VARIABLE>"
wsrep_slave_threads            = <VARIABLE>
wsrep_sync_wait                = 0
wsrep_provider_options         = "gcache.size=4G"
wsrep_retry_autocommit         = 10

[mysqldump]
quick
quote-names
max_allowed_packet             = 16M

[client]
default-character-set=utf8
port                           = 3306
socket                         = /var/run/mysqld/mysqld.sock

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
socket                         = /var/run/mysqld/mysqld.sock
nice                           = 0

[mysql]

[isamchk]

If you have used the install_percona_nodes script to create the cluster, you should not need to tune your database settings.

If you do want to tune your settings, Moogsoft recommends that you set the following variables based on system resources:

innodb-buffer-pool-size: Set this to 80% of system RAM if you set the -d (dedicated) flag. Otherwise, set this to 50% of system RAM.
innodb_buffer_pool_instances:
- If the buffer pool size is greater than 16 GB, set this to a number between "2" and "64" to divide the buffer pool size into chunks of approximately 8 GB in size.
- If the buffer pool size is less than 16 GB, set this to "8".
innodb-log-file-size: Set this to the larger of the following two values:
- Approximately 2% of the buffer pool size.
- 1 GB.
wsrep_slave_threads = If the number of processor cores is greater than or equal to 32, set this to the number of processor cores divided by four. Otherwise, set this to "8".

Scenario 2

If you have set up a production environment with a Percona XtraDB Cluster, but have not used the install_percona_nodes script to create the cluster, you should tune your database settings in line with Scenario 1.

Scenario 3

If you have set up a non-production or QA environment with MySQL Community, you should tune your database settings by following the guidance in the default my.cnf.

The default moog_init_db script does not attempt to automatically set any of these variables. You must manually set these variables post-install.

# INNODB #
# Important: innodb-buffer-pool performance tuning
# On servers with >= 16GB RAM that run MySQL and Moog applications, consider setting
# innodb-buffer-pool-size to 50% of system RAM.
# On servers where only MySQL is running, consider setting innodb-buffer-pool-size
# to 80% of system RAM.
innodb-buffer-pool-size        = 2G

# If innodb-buffer-pool-size >= 16G, then uncomment and set innodb_buffer_pool_instances
# to divide buffer pool into ~8G chunks. Otherwise leave commented to use default of 8
# e.g: innodb-buffer-pool-size=32G innodb_buffer_pool_instances=4
# e.g: innodb-buffer-pool-size=80G innodb_buffer_pool_instances=10
#innodb_buffer_pool_instances = 8

# Set innodb-log-file-size to 1G or ~2% of buffer pool size, whichever is the larger
# e.g: innodb-buffer-pool-size=64G innodb_log_file_size=1280M
innodb-log-file-size           = 1G

# Set innodb-flush-log-at-trx-commit to 0 on systems where throughput is valued
# over risk of data loss in the event of a mysql crash
innodb-flush-log-at-trx-commit = 1

In this section:

Validate the Installation

Note

Note

Note

Validate a high availability installation

Validate the database settings

Scenario 1

Scenario 2

Scenario 3

Search results