Opsview Knowledge Center

Migrating to New Hardware

Learn how to migrate your Opsview Monitor environment to new hardware

In this section, we offer step-by-step instructions providing you with specific guidance to successfully migrate Opsview Monitor to a different hardware platform.

If you have a distributed environment then you should disable slave devices on the old Opsview Monitor installation to avoid any contention between the master servers.

Also, If you are migrating to a new architecture, you should read through these steps in this document as it will guide you through how you should export your data.

The data can be migrated to a system running the same or a later version of Opsview Monitor, but you cannot migrate to an older version. We assume that you have a new installation of Opsview Monitor on your new server; see Installing Opsview Monitor for more information.

Please note, there will be an outage to the Opsview Monitor service during the migration.

Migration Considerations

In this section, we provide for your reference a few considerations that are beyond the scope of this document, yet should be reviewed prior to committing to migrating to new hardware.

Opsview Agents / NRPE

If you have set up security on your Nagios(R) Remote Plugin Executor (NRPE) agents by limiting the IP address of the servers permitted to interrogate them, then do not forget to include the new server's IP address.

SNMP

If you limit Simple Network Management Protocol (SNMP) communication to specific IP addresses, then ensure that your devices have been updated to allow add the new servers to this list.
Likewise, if you send SNMP traps to the Opsview Monitor master, ensure the traps are redirected to the new server. To do this, simply edit the nsc.ini file on Windows or nrpe.cfg on Linux and change the 'allowed_hosts' directive to include the IP address of the Opsview Monitor servers.

Firewalls

If you have set up a firewall for web access to the Opsview Monitor master, this will need to be updated to allow access to the new Opsview Monitor master's IP address.

Performing the Migration

Building the New Opsview Monitor Master

You will need to install Opsview Monitor on your new hardware (server); see section Installing Opsview Monitor for step-by-step instructions.

Migrating Configuration Files

You should migrate any configuration files that you may have customized to your new server, such as those listed here.

  • /usr/local/nagios/etc/opsview.conf (Ensure it is pointing to the correct database)
  • /usr/local/nagios/etc/map.local
  • /usr/local/nagios/etc/sw.key
  • /usr/local/nagios/etc/sw/* (directory with all files within)
  • /usr/local/opsview-web/opsview_web_local.yml
  • /usr/local/nagios/share/stylesheets/custom.css
  • Apache configuration files

Migrating Custom plugins

You should transfer any additional plugins or custom scripts (event handlers or notification scripts) from the old server to the new one, ensuring file ownership and permissions are preserved.

Stopping Opsview Monitor

To stop Opsview Monitor on the old and the new server, run the commands as shown in the example below:

  /opt/opsview/watchdog/bin/opsview-monit stop opsview-web
  /opt/opsview/watchdog/bin/opsview-monit stop opsview

Migrating the Nagios® Core Logs

If you want to keep the old Nagios® Core log files (which are used for the Nagios® Core availability reports), move all files contained within the /usr/local/nagios/var/archives directory to the new server. Additionally, you will need to move the /usr/local/nagios/var/nagios.log file into the same area bearing in mind the naming convention used.

Migrate Existing Status Data

If you wish to keep existing status data, including downtimes, acknowledgements and Nagios® comments, you will need to copy the file /usr/local/nagios/var/retention.dat to the new server.

Migrating Databases

You should migrate your existing database to the new server. However, initially you should follow the backup and restore guide in section Databases on a different server.

Next you should ensure that database permissions are correctly defined by running the command, as shown below, as MySQL root on the new Opsview Monitor server.

  /usr/local/nagios/bin/db_mysql -u root -p<PASSWORD>

Finally, upgrade the Opsview database schemas on the new server, using the commands shown below:

  su - nagios /usr/local/nagios/installer/upgradedb.pl

Upgrading Slaves

In a distributed environment, run the command (as shown below) to test communications from the new master server to the Slave Nodes and correct any errors.

  send2slaves -t

You should also run the command (as shown below) to ensure slaves are updated with the latest code.

  send2slaves

Starting Opsview Monitor

Finally, to start Opsview Monitor on your new hardware, run the commands:

  /usr/local/nagios/bin/rc.opsview gen_config
  /opt/opsview/watchdog/bin/opsview-monit start opsview-web

Host Migration via a spreadsheet

This process covers importing your Opsview Monitor configuration from an Excel spreadsheet and is designed to help with the following scenarios:

  • You are migrating from another system which is not supported by an Opsview Monitor migration tool
  • You have an asset tracking or CMDB tool with the required information
  • You have an existing spreadsheet detailing your IT infrastructure
  • You wish to perform a bulk import of your host configuration into Opsview Monitor

Spreadsheet Compatibility

The importer tool reads Excel format files using Spreadsheet-ParseExcel. This reads Excel 95 - 2003 binary files. It has been tested with spreadsheets edited in Mac Office Excel 2008 and Open Office 3 - please see that link to see the currently supported spreadsheets.

Planning your migration

Only hosts will be affected. Other related items - such as service checks, host templates, host groups - should already be defined.

Using the Migration Tool

Locate the Excel spreadsheet at /usr/local/nagios/installer/import_excel.xls. Instructions are on the first worksheet.

When the spreadsheet has been updated, it must be copied to a suitable location on the Opsview master server. Then run the following command as the 'nagios' user:

/usr/local/nagios/bin/import_excel -y -o /tmp/results.xls /tmp/updatedimport.xls

The results.xls file will have information about success or failures.

Troubleshooting

If you run without the -y flag, then the spreadsheet is read, but no changes are made to the database.

If you want more debug information, you can set the following in /usr/local/nagios/etc/Log4perl.conf:

log4perl.logger.import_excel=DEBUG

This will show the data from the spreadsheet that is passed through to the host synchronisation method. If you think you have found a problem in how the data is read, you can take the output from here and contact us for support

Import comments

If the import has failed, there will be comments next to each row in the results spreadsheet. These are the possible errors:

{field}: Invalid

The field failed a validation constraint. There could be invalid characters or incorrect lengths in the data

No related object for {field} '{info}'

When trying to search for a related object (such as a host group, a host icon, service checks or time periods), could not find the object based on the search. Check in the web user interface if the related object exists.

Host group is not a leaf

In Opsview, a host can only belong to one host group and that host group must be a leaf host group. Click on the Configuration-> Host Groups link on the left hand navigation to see the list of leaf host groups that can be used for importing.

No name specified

The host is missing a name field

Service check {name} is listed in service checks and excluded service checks

You cannot have the same service check listed in both columns.

Spreadsheet field information

This section of the documentation will detail the spreadsheet format and the acceptable values for each column.

The second worksheet in the import_excel.xls contains the data that will be imported into Opsview and each row in this worksheet should map to an individual host in Opsview.

For the columns whose headers are highlighted in orange, the values in each row will be updated as part of the import process. For the remaining columns, the fields in the rows will be left unaltered.

Note that the column header names are read by the import process and should not be changed.

'Action' column

This column dictates the action to be performed for the row of data in the worksheet. Acceptable cell values are:

  • 'Update' - Opsview will be updated with the remaining data in the row.
  • A blank cell - the row will be ignored by the import process.

'Host' column

This column contains the unique Opsview host name, as described here

If the named host already exists in Opsview, then the existing host will be updated in the Opsview configuration. If it does not already exist, then the host will be created within Opsview. Acceptable cell values are:

  • Any alpha-numeric characters.

'Hostname or IP' column

This column specifies the Opsview 'Primary hostname/IP address' field value, as detailed here. Acceptable cell values are:

  • Any alpha-numeric characters, forming a string value.
  • Numberic characters and 'period' characters, separating the IP address octets.

'Other addresses' column

This column specifies the Opsview 'Other hostnames/IP addresses' field value, as detailed here. The list of hostnames/IP addresses should be comma delimited. Acceptable cell values are:

  • Any alpha-numeric characters, forming a string value.
  • Numberic characters and 'period' characters, separating the IP address octets.
  • Commas separating the above.

'Monitored by' column

This column should be left blank.

'Description' column

This column can be used to specify a description of the host. Acceptable cell values are:

  • Any alpha-numeric characters and 'special' characters.

'Parents' column

This column specifies the host 'parents' field value, as detailed here. The list of parent names should be comma delimited. Acceptable cell values are:

  • Any alpha-numeric characters, forming string values that are existing Nagios Core hostnames
  • Commas separating the above
  • Empty cell - this means do not change any values
  • NONE - this means to remove all parents

'Host group' column

This column specifies the name of the host group that this host is a member of. Note that the host group must already exist in Opsview and that the host group must also be a 'leaf' host group - i.e. it is at the bottom level of the host groups tree. Acceptable cell values are:

  • Any alpha-numeric characters, forming a string that is an existing host group name.

'Host check command' column

This column specifies the command that will be run to check the status of the host - see here. Acceptable values are:

  • Any alpha-numeric characters, forming a string that is the name of an existing host check command
  • NULL, which means to set no check command (assumes the host is always UP)

'Icon' column

This column specifies the name of an icon that will be used to pictorially represent the host within Opsview. The icon can either be an icon file included with Opsview, or a custom icon file that has been added to Opsview.

Acceptable values are:

  • Any alpha-numeric characters and special characters, forming a string that is the name of an existing host check command - e.g. 'SYMBOL - Switch'.

'Keywords' column

This column is used to specify keywords that will be assigned to the Opsview host. Each keyword should be comma delimited and if the keyword does not already exist within Opsview, it will be created automatically.

Acceptable values are:

  • Any alpha-numeric characters, forming an individual keyword
  • Commas, which are used to delimit individual keywords
  • Empty cell - this means do not change any values
  • NONE - this means to remove all keywords

'Notification options' column

This column is used to specify which events that the host sends an alert notification for. Where it legal to provide more than one notification event type, the types should be comma delimited.

Acceptable values are:

  • 'n' - no notifications.
  • 'u' - unreachable.
  • 'd' - down.
  • 'r' - recovery.
  • 'f' - flapping.
  • 's' - scheduled downtime.
  • Commas, which are used to delimit notification events.

Note: If 'n' for 'no notifications' is specified, then no other values should be specified in the spreadsheet for the row concerned.

'Notification period' column

This column is used to specify the time period in which alert notifications will be sent to Opsview contacts. The value in this column should be the name of a time period that has already been configured within Opsview, such as '24x7'.

'Re-notification interval' column

This column is used to specify the frequency (in minutes) of how often alert notifications are resent if the host status is not handled.

Acceptable values are:

  • A positive integer.
  • A zero value to disable the re-notification feature.

'Check period' column

This column is used to specify time periods when the host status is checked. The value in this column should be the name of a time period that has already been configured within Opsview, such as '24x7'.

'Check interval' column

This column is used to specify the frequency (in minutes) of how often the host status is checked.

Acceptable values are:

  • A positive integer.
  • A zero value that means 'check only on demand'.

'Maximum check attempts' column

This column is used to specify how many times a check must fail before it changes to a hard state. Acceptable values are any non-zero, positive integer.

'Retry interval' column

This column is used to specify how often a check is performed when the host is in a soft failure state. Acceptable values are any non-zero, positive integer.

'Host templates' column

This column is used to specify the names of host templates that the current host will include, delimited by commas. The host templates must already be defined within Opsview.

Acceptable values are:

  • Any alpha-numeric characters, forming a string that is an existing host template name
  • Commas to delimit the host template names
  • Empty cell - this means do not change any values
  • NONE - this means to remove all host templates

'Enable SNMP' column

This column specifies whether or not to enable SNMP. Acceptable values are:

  • 1 - to enable SNMP
  • 0 or an empty cell - to disable SNMP

'SNMP version' column

This column is used to specify the SNMP version. Acceptable values are one of the following:

  • '1'
  • '2c'
  • '3'

'SNMP community' column

This column specifies the SNMP community string for the host when configuring an SNMP agent. A value in this column is only required if the host is using SNMP versions 1 or 2c.

Acceptable values are any alpha-numeric characters forming the string.

'SNMP username' column

This column specifies the SNMP username for the host when configuring an SNMP agent. A value in this column is only required if the host is using SNMP version 3.

Acceptable values are any alpha-numeric characters forming the string.

'SNMP auth protocol' column

This column is used to specify the SNMP authorisation protocol and is only required when using SNMP version 3. Acceptable values are one of the following:

  • 'md5'
  • 'sha'

'SNMP auth password' column

This column specifies the SNMP authorisation password and is only required if the host is using SNMP version 3.

Acceptable values are any alpha-numeric characters forming the string.

'SNMP priv protocol' column

This column is used to specify the SNMP privacy protocol and is only required when using SNMP version 3. Acceptable values are one of the following:

  • 'des'
  • 'aes'
  • 'aes128'

'SNMP priv password' column

This column optionally specifies the SNMP privacy password and is only required if the host is using SNMP version 3. Acceptable values are:

  • Any alpha-numeric or special characters forming the password string.
  • An empty cell for no password.

'Service checks' column

This column specifies the names of service checks that will be included (monitored by) this host. Acceptable values are:

  • Any alpha-numeric characters, forming a string that is the name of an existing service check
  • Commas delimiting each service check name
  • Empty cell - this means do not change any values
  • NONE - this means to remove all service checks

Warning: If you have any exceptions, timed exceptions or event handlers enabled for a specific service check, these will be removed when importing. This is because it is not possible to encode the additional information required for these attributes within the limitations of a spreadsheet. See the REST API for an alternative way of doing imports that can preserve the integrity of existing data.

'Import status' column

The contents of this column should not be modified by the user. After the import process is run, this column will contain the success or failure status for each row.

'Import comments' column

The contents of this column should not be modified by the user. If the import process has failed, this column will contain details of the failure for each row.

Migrating to New Hardware

Learn how to migrate your Opsview Monitor environment to new hardware