Migration to the CMC

Last updated: July 14. 2016


1. Migrating from Nagios to CMC

The  Check_MK Enterprise Edition automatically creates new instances with CMC as the core. If your instance originates from an older version, it can be retrospectively converted from Nagios to CMC. The procedure itself is very simple:

First, stop your Check_MK instance:

OMD[mysite]:~$ omd stop

Then convert:

OMD[mysite]:~$ omd config set CORE cmc

Afterwards, don't forget to start:

OMD[mysite]:~$ omd start

Attention: The core's current status (the current states of hosts and services, etc.) will NOT be carried over. The system's status will in any case be determined once each check has been executed. Any host or service that does not have an UP, or respectively OK state will trigger a new alarm. If this is not wanted, deactivate the alarms via the Master Control element before the conversion. Commentaries and downtimes, and likewise historic performance data (RRD-Data), will however be carried over.

The event history (Nagios-Log) will be maintained in a compatible format by CMC - but in a different location (var/check_mk/core/history). The log archive is located in var/check_mk/core/archive. If you wish to carry over the event history (e.g., for Availability), copy the necessary files on the command line:

OMD[mysite]:~$ cp var/nagios/nagios.log var/check_mk/core/archive
OMD[mysite]:~$ cp var/nagios/archive/* var/check_mk/core/archive

1.1. From CMC back to Nagios

Should you discover that your configuration is not yet compatible with CMC (see below for tips), you can similarly convert back to Nagios:

OMD[mysite]:~$ omd config set CORE nagios

A carry over of downtimes, etc. from CMC to Nagios is not possible. Nagios will however import its old state from before the migration to CMC.

2. Tips for migrating to CMC

In order to keep the CMC as slim and efficient as possible, and to modernise some important components, not all functions of Nagios have been 1:1 rewritten. This means that it may be necessary to modify some elements of your configuration.

The CMC can fundamentally not import Nagios configuration data. If however, you have written parts of the Nagios data by hand, or use constructions such as extra_nagios_conf in the main.mk data, these cannot be processed. If you have always worked with WATO no modification is necessary.

Below is a summary of all items that could have been manually configured in Nagios, but which cannot be realised (or for which a different procedure is needed) in the CMC:

2.1. Event-Handler

The CMC supports no conventional Nagios-Event-Handler. The  Check_MK Enterprise Edition however has the so-called Alert Handler for this function. This is markedly more flexible and can be configured via the Alert Handlers WATO module.

2.2. Service dependencies

This is not currently supported by the CMC. It is possible that it may be implemented in the future. Because service dependencies are laborious to configure in Nagios, and are not transparent for the user, there are no plans to implement them in this form.

2.3. Event-Brokermodule

Livestatus and the processing of performance data is integral to the CMC. Other modules cannot be loaded.

2.4. obsess_over_services

Distributed monitoring with NSCA is only supported in the function as server. This means that a system with the CMC as its core can receive - but not send - passive checks per NSCA. This obsolete type of distributed monitoring has so many disadvantages that it is not supported by CMC.

2.5. Escalations

The escalation of alarms is no longer done in the core, but rather via Rule Based Notifications.

2.6. status.dat

Add-ons which produce these readouts are not available. A script can be found in ~/share/doc/check_mk/treasures/webapps which uses an HTTP query to generate a compatible status.dat.

2.7. Timeperiods

Here some of the exception conditions supported by Nagios are not possible. Currently only the 1970-12-18 format is supported. Items such as february -2 don't yet function. In the Timeperiods WATO module there is however the possibility of importing from iCal.

2.8. legacy_checks

The legacy_checks configuration variable used for configuring active checks in older versions of Check_MK no longer exists. You can naturally execute active checks with the CMC, but in a somewhat different form.

The reason for this is that the legacy_checks refer to commands that are manually defined in the Nagios configuration and which are consequently not available to the CMC. In lieu of these you can use the more modern custom_checks. These can be conveniently managed in WATO with the Active Checks ➳ Classical Active and Passive Monitoring Checks rule (also without the CMC by the way).

The following example shows how to convert an existing Legacy check to the new format:

main.mk (altes Format)
# Definition of the Nagios command
extra_nagios_conf += r"""

define command {
    command_name    check-my-foo
    command_line    $USER1$/check_foo -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
"""

# Create service definition
legacy_checks += [
  (( "check-my-foo!20!40", "FOO", True), [ "foohost", "othertag" ], ALL_HOSTS ),
]

Convert that to the more modern custom_checks for the CMC, as below:

main.mk (neues Format)
custom_checks += [
  ({
      'command_name':        'check-my-foo',
      'service_description': 'FOO',
      'command_line':        'check_foo -H $HOSTADDRESS$ -w 20 -c 40',
      'has_perfdata':        True,
  },
  [ "foohost", "othertag" ],
  ALL_HOSTS )]

The new method also functions with a Nagios core, so that following the conversion you can switch backwards and forwards between both cores without problem.

2.9. Performance data from Host-Checks

The CMC utilises the Smart-Ping as the standard for host checks - this will be explained in detail in another section.

This means that:

  • after a conversion from a Nagios core the host checks at first provide no performance data, and
  • manually created PING checks on hosts without other checks generate performance data by default.

If you require the PING performance data for single or all hosts, then we recommend that you add explicit PING checks for the desired hosts via the WATO Check hosts with PING (ICMP Echo Request) rule set, to be found under Active Checks}.

If you wish to maintain existing RRD databases, (with the core stopped) you can simply rename the files in var/pnp4nagios/perfdata/HOSTNAME from _HOST_* to PING*.

Alternatively, with the Host Check Command rule you can deactivate Smart-Ping and substitute it with a conventional ping (that works internally as usual with check_icmp). In this case you don't need to rename the RRDs, but must however forgo the advantages of Smart-Ping.