Opsview Knowledge Center

Migrating from Nagios® Core

Learn how to migrate from Nagios® Core

There are two methods for migration from Nagios Core to Opsview Monitor:

  • A full migration where all monitoring is moved into an Opsview Monitor system and the Nagios Core server can be decommissioned.
  • A partial migration where the existing Nagios Core server is configured to send all of its results back to an Opsview Monitor server. The Nagios Core server remains in use.

Planning Your Full Migration

Overview

We recommend that you provision an Opsview Monitor system for the purpose of testing your migration.
Migration checklist:

  1. Check that Opsview Monitor is supported on your target platform.
  2. Test existing Nagios plugins and copy to Opsview Monitor system.
  3. Configure required Service Checks in Opsview Monitor.
  4. Create Host Templates corresponding to required hardware, operating system and application checks.
  5. Create required contacts for Opsview Monitor system access and Notifications.
  6. Confirm that the Opsview Monitor migration tool imports your Host information correctly.
  7. Test whether your Nagios add-ons work as expected.
  8. Confirm that your existing Nagios agents work correctly.
  9. Confirm that SNMP monitoring continues to work correctly.

Plugins

Any Nagios plugins used by your existing system should continue to work with Opsview Monitor. If you have developed any plugins yourself, we recommend that you review the Nagios Plugins developer guidelines.

Plugin Guidelines:

  • Use the plugins supplied with Opsview Monitor if there are any duplicates
  • Confirm that your plugins accept the '-h' argument to display help information
  • Confirm that your plugins return performance data if you require performance graphs
  • If you are using third-party supplied plugins we recommend that you upgrade to the latest version

Copy any custom plugins into /usr/local/nagios/libexec on the Opsview Monitor server.

Nagios add-ons

We cannot guarantee that Nagios addons will work with Opsview Monitor. Our recommendation is that you set up a test Opsview Monitor system to confirm correct operation.
Opsview Monitor includes some common add-ons. We strongly recommend that you use the versions supplied with Opsview Monitor rather than your own.

Nagios Agents

You can use your existing Nagios agents with Opsview Monitor so there is no need to update software on your existing monitored hosts. We recommend you follow these guidelines:

  • Opsview Monitor has been tested with NRPE, NRPE_NT and NSClient++; you should ask on our forums if you're using another technology
  • Configuration of the Service Checks supplied with Opsview Monitor may require changing for use with your own agents
  • Review the Nagios Plugin guidelines above for the Nagios plugins that you are using with your agent.

SNMP

Plugins that use the SNMP protocol should continue to work with Opsview Monitor.
Guidelines:

  • Confirm access control for your SNMP agent allows queries from your Opsview Monitor server's network address
  • Configure SNMP parameters against each Opsview Monitor Host and then use macros with your Service Checks

Notification

Your existing Email, Pager and SMS notification facilities should work with Opsview Monitor. If you are using another notification method it may be necessary to modify your configuration and Notification scripts.

Using the Migration Tool

Compatibility

This tool is compatible with Nagios Core 3

Capabilities

This tool is capable of migrating the following configuration items:

  • Time periods

    • Only weekly definitions
  • Users

  • Hosts

    • Parents will be associated. Contact groups will not be imported. Every Host will be given the Network - Base host template
  • Host groups

  • Services

    • Only active checks will be imported. Service Checks will be put into a service group called 'Imported'

Preparation

Copy your Nagios Core configuration to the Opsview Monitor server The migration tool reads the Nagios Core object file which is used by the Nagios Core CGIs. This file is called object.cache, or objects.dat in older versions of Nagios Core. The file is usually located in /usr/local/nagios/var.
Transfer this file to your Opsview Monitor server.

Running the Migration Tool

The migration tool is located within the /usr/local/nagios/installer directory on the Opsview Monitor master server. We recommend you take a backup of your existing Opsview Monitor configuration database before running the migration tool.

su - nagios /usr/local/nagios/bin/db_opsview db_backup > /tmp/opsview.db /usr/local/nagios/installer/migrate_nagios {path to objects.cache file} This will output information about what changes it has made. Check the output for any warnings.

The tool can be run multiple times without making multiple entries of the same information within Opsview Monitor.

Post-migration

  • Review warnings raised in the output
  • Review the Hosts that have been imported - check Host Groups as Opsview Monitor only allows a Host in a single Host Group
  • Review the Service Checks that have been imported. You can move the Service Checks into appropriate Service Groups
  • Review the contacts imported - set permissions based on Host Group and Service Group and the appropriate Notification options
  • Review contact groups - set permissions based on Host Groups and Service Groups
  • Do a reload and start monitoring!

Support

We are always looking to enhance our migration tools, but the migration tools heavily depend on the initial Nagios Core configuration. If it has not imported data as you expect, please contact us on the forums or via the Customer Success team with the version of Opsview Monitor, your objects.cache file and what the issue is.

Troubleshooting

Error Messages During Migration

These error messages will stop the migration process.

Unrecognised method=notify-by-carrier-pigeon

A notification method has been defined that Opsview Monitor doesn't recognise. You can should remove these from the object.cache file for the particular contact to continue.

Inconsistent check_interval, retry_check_interval or max_check_attempts

Opsview uses common check interval, retry_check_interval and max_check_attempts for services with the same name. The migration tool will fail if these attributes for a service does not match the Service Check's definition.

You can either:

  • change the objects.cache file to match the database information
  • update the service check definition in Opsview Monitor
  • rename the service description to a different name, thus creating a different service check definition

Warning Messages During Migration

These warning messages could appear in the migration output.

Changed Service Description ..

Opsview Monitor has reserved some characters from being used in a service description. This warning just tells you that the name has been changed.

Inconsistent check_period

Opsview uses common check periods for services with the same name. The migration tool will fail if the check_interval specified for a service does not match the Service Check interval definition.
Opsview has a feature where if the service has no check_period set, it will inherit from the Host's check_period - this could account for the discrepancy.

Inconsistent Notification Options

Opsview Monitor uses common Notification options for services with the same name. The migration tool will flag any services that have the same name but the Notification options do not match.

Opsview Monitor has a feature where if the Host has no notifications set, then the service will also not have any notification options - this could account for the discrepancy.

Planning Your Partial Migration

This functionality is available from Opsview Monitor 3.11.0.

Overview

For those instances where Nagios Core monitoring cannot be moved to Opsview Monitor easily and quickly, the Nagios Core server can configured as a passive slave in Opsview Monitor. The Nagios Core server then uses NSCA functionality to send all the results back into Opsview Monitor over a secure channel so Opsview Monitor can then perform all the necessary alerting and reporting until such time that the Nagios Core server can be fully migrated. This form of passive slave must be carefully considered to ensure there are no Host name clashes with Hosts that have already been configured in Opsview Monitor.

Opsview Monitor Configuration

  • The Opsview Monitor server needs to have SSH access to the Nagios Core server as user nagios
  • Create the Nagios Core server as a normal Host in Opsview Monitor
  • Create a new monitoring server (Menu \x{00E2} \x{0087} \x{0092} Advanced \x{00E2} \x{0087} \x{0092} Actions \x{00E2} \x{0087} \x{0092} Create new Monitoring Server), set the Nagios Core server as the 'Cluster Node' and check the 'Passive' checkbox, then 'Submit'
  • Run send2slaves -t to test the configuration
  • Do a reload.

At this point the slave will be generating errors such as 'SLAVE CRITICAL - Error retrieving slave information - slave is likely to be down' in Opsview Monitor.

Nagios Core Server Configuration

  • As the nagios user ensure the following directories exist under /usr/local/nagios

    • bin
    • etc
    • var
  • Install send_nsca (might be part of the 'nsca' package on your platform)
  • Copy the send_nsca binary (can be in /usr/sbin/) to /usr/local/nagios/bin
  • Copy /usr/local/nagios/etc/send_nsca.cfg from the Opsview Monitor server to the Nagios Core server into the same place
  • Copy /usr/local/nagios/bin/process-cache-data and retrieve_opsview_info from the Opsview Monitor server to the Nagios Core server into the same place
  • Symlinks the nagios status'dat file to /usr/local/nagios/var
  • Create and make executable /usr/local/nagios/bin/process-cache-data.sh containing
    #!/bin/bash /usr/local/nagios/bin/process-cache-data $@
    A this point the following changes need to be made to the nagios configuration and nagios restarted.
  • Add the following configuration to commands.cfg or other suitable configuration file
    define command { command_name process-host-perfdata-file command_line /usr/local/nagios/bin/process-cache-data.sh cache_host } define command { command_name process-service-perfdata-file command_line /usr/local/nagios/bin/process-cache-data.sh cache_service e }
    
  • Amend the nagios.cfg file to add or replace the following configuration
    process_performance_data=1 host_perfdata_file=/usr/local/nagios/var/cache_host.log service_perfdata_file=/usr/local/nagios/var/cache_service.log host_perfdata_file_template=$HOSTNAME$\t$HOSTSTATE$\t$HOSTOUTPUT$|$HOSTPERFDATA$ service_perfdata_file_template=$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEOUTPUT$|$SERVICEPERFDATA$ host_perfdata_file_mode=a service_perfdata_file_mode=a host_perfdata_file_processing_interval=5 service_perfdata_file_processing_interval=5 host_perfdata_file_processing_command=process-host-perfdata-file service_perfdata_file_processing_command=process-service-perfdata-file
    
  • Reload Nagios Core

At this point results should be passed up to Opsview Monitor from the Nagios Core server. Look at the Opsview Monitor server log file /usr/local/nagios/var/nagios.log for entries such as the following:

[TIMESTAMP] Warning:  Passive check result was received for host 'HOSTNAME', but the host could not be found!
[TIMESTAMP] Warning:  Passive check result was received for service 'SERVICE' on host 'HOSTNAME', but the host could not be found!

Using the Partial Migration Tool

A tool has been provided on the master server as:

/usr/local/nagios/utils/list_unknown_devices

which would output a report similar to the following:

Host 'gateway' missing
Host 'localhost' missing service 'Current Load'
Host 'localhost' missing service 'Current Users'
Host 'localhost' missing service 'Disk Space'
Host 'localhost' missing service 'HTTP'
Host 'localhost' missing service 'SSH'
Host 'localhost' missing service 'Total Processes'

These Hosts and services should be created by hand with appropriate Host templates assigned. It works by parsing the current 'nagios.log file' searching for 'host could not be found' and 'service could not be found' errors.
Care should be taken to ensure Hosts are assigned to the correct passive slave and that there isn't already a Host with the same name in the Opsview Monitor configuration.

Migrating from Nagios® Core

Learn how to migrate from Nagios® Core