OP5 Monitor ["OP5 Monitor"]
["User Guide"]

# Upgrade

## Overview

You can upgrade your OP5 Monitor instance using the Red Hat Enterprise Linux `yum` command for online servers.

This section walks you through the upgrade steps and requisite information you may need to know beforehand.

Note: If you are running OP5 Monitor in a distributed or load-balanced environment, you must ensure that servers are running the same version of the software. For more information, see Scale up your monitoring environment.

## Before you begin

Before you upgrade OP5 Monitor, we strongly advise you perform the following tasks:

- Read the OP5 Monitor release notes for the version you are upgrading to, paying particular attention to the Known issues section.
- Read the OP5 Monitor 9.x Compatibility Matrix for the supported versions.
- Deploy the upgrade in a development or UAT environment first, which is as similar to your production environment as possible. Perform tests in that environment and ensure there is no incompatibility with your current deployment.
- Perform necessary backups and snapshots of your production system before deploying the upgrade, and establish a rollback plan in case the upgrade fails.

## Upgrade to OP5 Monitor 9

Take note of the following information when upgrading to OP5 Monitor 9:

- Logger data will not be restored on the OP5 Monitor 9 system since it is no longer available and supported.

- Upgrading OP5 Monitor 8 on CentOS or RHEL 7 in-place is not supported. A new installation of a supported EL8 OS needs to be set up on another server (virtual or physical), or otherwise replace the current installation on the same server.

- Migration to OP5 Monitor 9 is only supported from OP5 Monitor 8.3.8 or newer.

### Upgrade

If you are running an old version of OP5 Monitor, use `yum` to update to the latest version available through the repositories. If you are on an older version, it may not support EL7, therefore updating OP5 Monitor first is always recommended.

Automatic updates stay in the same major version. This means that if you are on version 8.x, there will not be an automatic upgrade to version 9.x.

Run `yum` in the command line of your server or virtual machine:

    # yum update

### Verify your OP5 Monitor version

Run the following script to ensure that you are using the latest version of OP5 Monitor:

    # cat /etc/op5-monitor-release
    VERSION=X.Y.Z

When creating and restoring `op5-backup` files, the versions have to match exactly. Do not import a backup file that was created on another version of OP5 Monitor.

### Disable notifications and stop OP5 Monitor

To disable notification through the web (runtime setting):

1. Open OP5 Monitor in your browser.

2. Go to Manage > Process Information > Options (right corner) > Operations > Disable Notifications.

3. Restart OP5 Monitor.

You can also disable notifications directly in `naemon.cfg`, which is recommended, followed by a restart of OP5 Monitor: `enable_notifications=0`.

For more information about `naemon.cfg`, see Main Configuration File Options.

### Check compatibility

Install and run the `op5-check-migration` tool to check for potential problems with migrating to OP5 Monitor 9, such as if the plugins that are in use on your system are available on OP5 Monitor.

Install `op5-check-migration` tool:

    # yum install op5-extra-tools-check-migration

Run `op5-check-migration` to create a report of potential problems. If no problems are reported, your OP5 Monitor configuration should work on version 9.

In this example, `op5-check-migration` reports that one service is using the plugin `check_json` which is not available in OP5 Monitor 9. If you proceed with the migration, that service check will fail since it cannot execute the plugin.

To resolve this issue, do any of the following:

- Remove the affected services.

- Temporarily disable checks or notifications of the affected services until you can fix the problem on the migrated system.

- For simple scripts without third-party dependencies, copy the script and install it as a custom plugin on the OP5 Monitor 9 system.

For a complete list of check commands and services that use the plugins, refer to the `op5-plugin-report-*.json` file, section `problem_plugins` , created by the report.

    # op5-check-migration
    ==========================================================
    = Running check: plugins
    ==========================================================
    Checking plugin usage of all services in the configuration.
    This may take a while, depending on the size of your configuration...
    ==========================================================
    = Running check: license
    ==========================================================
    ==========================================================
    = Report: plugins
    2022-02-07 file:///home/aksel/vimwiki_html/diary/2022-02-07.html
    1 of 3 2/7/22, 10:00
    ==========================================================
    *** Current OP5 Monitor configuration
    Number of services: 128
    Number of check commands in use by services: 30
    Number of plugins used: 18
    Plugins used:
     $USER1$/check_by_snmp_cpu
     $USER1$/check_by_snmp_disk
     $USER1$/check_by_snmp_disk_io
     $USER1$/check_by_snmp_extend
     $USER1$/check_by_snmp_load_avg
     $USER1$/check_by_snmp_memory
     $USER1$/check_by_snmp_procs
     $USER1$/check_dig
     $USER1$/check_dummyv2
     $USER1$/check_http
     $USER1$/check_json
     $USER1$/check_k8s.py
     $USER1$/check_nrpe
     $USER1$/check_nrpe4
     $USER1$/check_smtp
     $USER1$/check_ssh
     $USER1$/check_vmware_v2
     $USER2$/check_icmp
    *** Plugin usage report
    Problems found:
    Plugin 'check_json' used by 1 check commands and 1 service checks:
     > 'check_json' is currently not available in the target version.
    All check commands and services that use the deprecated plugins are listed in /var/tmp/op5-plugin-report-2022-01-28_122527.json
    plugins result: failed
    ==========================================================
    = Report: license
    ==========================================================
    *** check_op5_license
    Plugin output: 0 year(s) 6 month(s) 17 day(s) left
    Plugin check result: OK
    license result: success
    ==========================================================
    = Summary
    ==========================================================
    1/2 checks completed successfully
    Failed checks: plugins

Your current custom plugins are included in the migration backup created with `op5-backup` and will be restored on the OP5 Monitor 9 system.

If the `op5-check-migration --check license` command returns an error, please submit a report to ITRS Support. License failures will affect access to the application.

### Run the backup

    # mon stop
    # op5-backup --migrate

From help:

    -g|--migrate

    System migration to the next major version of CentOS release.
    No other options are needed. If you are using this on a 32-bit
    system, you will automatically perform an architecture change.
    This is the only time when the 'migrate' module is in use.
    If you do not use the 'migrate' module you need to specify
    mode manually with -m charch if you are moving from a 32-bit
    system.

    (...)

    To make a backup to be used when migrating to a new major system
    where you want to restore on the same server after you have
    reinstalled the operating system. This backup will include all
    backup modules available, which means that you will have not only
    the OP5 Monitor products in the backup, but also a system backup that will
    be used in the restore. This will not include all kinds of system
    settings, only the ones needed by OP5 Monitor products.

For more information about the different modules backup, inspect the scripts under: `/etc/op5-backup/modules`.

### Inspect the backup log and verify the backup

Logs from running the `op5-backup` can be found in:`/var/log/op5-backup/.`

For example:

     # grep -i error backup-20200311-094153.log

To verify the backup file, run:

    # tar tvf <backup-file>
    # op5-restore -l -b <backup-file>

### Transfer the backup file to your new server

At this point, your new server should already be running EL8. Your new server can be the same physical machine or a new virtual machine. Since there are several different ways to install an EL8 OS, we recommend that you refer to the documentation for RHEL or CentOS Stream for the installation procedure.

You should also have the latest OP5 Monitor 9 installed on the new server which you can download from the ITRS downloads.

### Restore the backup file

Note: The following commands should be run from a virtual console in vCenter or a physical console on the server, as the `op5-restore` procedure will overwrite network configuration.

If you are migrating to a new server and choose to apply network settings from the backup, shut down the old server before running the restore procedure to avoid IP address conflicts on the network.

1. Run `op5-restore`:

       # op5-restore -b <backup-file>

2. Reboot the server when the restore is complete.

3. Verify that the network settings are correct. If the old server had an advanced network configuration, manual configuration is necessary on the new server.

4. Verify functionality in the GUI.

5. Verify email and SMS notifications, if configured.

6. If checks are failing, ensure that you have installed any necessary dependencies that may have existed on the old server, for example, the VMware SDK, Dell OMSA, or any custom Perl modules.

7. If everything works as expected, you can re-enable notifications in the user interface of Ninja component: Manage > Process Information > Options (right corner) > Operations > Enable Notifications, or in the `naemon.cfg`.

## Upgrade with yum

For the migration tool to work, ensure that you are using the latest version of OP5 Monitor.

### Check which updates are available

You can check which updates are available at any time by running the following command:

    # yum check-update

### Upgrade to latest minor version

1. Log in to the console locally or remotely using SSH.

   Note: If you are logging in remotely with SSH, it is recommended to perform your update in a tmux or screen session so that the process is not interrupted if there is a network problem.

2. Enter the following command:

       # yum clean all && yum update

If there are any updates, information about what is going to be updated is displayed on the screen and you need to confirm if you want to continue or not.

## After upgrade

After the upgrade is complete, perform the following tasks:

- Check the correct version is installed.
- Run the same tests in your production environment as you ran in preparation for upgrade. For more information, see Before you begin.
- If you encounter any critical problems, consider rolling back the upgrade.

Was this topic helpful?
Your thoughts...
How can we improve this topic?
It did not answer my question(s)
Confusing
Missing screenshot or graphics
Missing technical details
Information is out of date
Your thoughts...
Thank you for your feedback!