Checkmk
Deutsch
master2.3.0-betalatest (2.2.0)2.0.01.6.0
to checkmk.com

1. Migrating from Nagios to the CMC

The CEE Checkmk Enterprise Editions automatically create new sites with the Checkmk Micro Core (CMC) as the core. If your site originates from an older version, it can be retrospectively converted from Nagios to CMC. The procedure itself is very simple:

First, stop your Checkmk site:

OMD[mysite]:~$ omd stop

Then convert:

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

Afterwards, don’t forget to restart:

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 freshly-determined once each check has been executed with the new configuration. Any host or service that does not have an UP, or respectively OK state will trigger a new notification. If this is not wanted, deactivate the notifications before the conversion — with the Master control snapin of the sidebar. Scheduled downtimes and commentaries, and likewise historic performance data in the RRDs, will however be carried over.

The event history (Nagios-Log) will be maintained in a compatible format by the 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 using the command line:

OMD[mysite]:~$ cp var/nagios/nagios.log var/check_mk/core/history
OMD[mysite]:~$ mkdir -p var/check_mk/core/archive && [[ -e var/nagios/archive/ ]] && cp var/nagios/archive/ var/check_mk/core/archive

1.1. From the CMC back to Nagios

Should you discover that your configuration is not yet compatible with CMC (see below for tips), you can convert back to Nagios in a similar way to the description above:

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

A carryover of scheduled 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 the 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 files. If however, you have written parts of the Nagios data by hand, or use constructions such as extra_nagios_conf in the main.mk file, these cannot be processed. If you have always worked with the Setup of the web interface, no modification is necessary.

In the following chapters you will find 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 Enterprise Editions however have the so-called alert handlers for this function, which are markedly more flexible. They can be configured via Setup > Events > icon alert handlers Alert handlers.

2.2. Service dependencies

This is not currently supported by the CMC. Because service dependencies are laborious to configure in Nagios, and are not very transparent for the user, there are no plans to implement them in this form.

2.3. Event broker modules

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

2.4. Configuration option obsess_over_services

Distributed monitoring with the Nagios add-on 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 the CMC.

2.5. Escalations

The escalation of notifications is no longer done in the core, but rather via rule-based notifications.

2.6. Time periods

For the time periods some of the exception conditions supported by Nagios are not possible. Currently only the format YYY-MM-DD, e.g. 1970-12-18, is supported, but not a format like february -2. With Setup > General > icon timeperiods Time periods there is however the possibility of importing calendar files in iCal format.

2.7. Configuration variable legacy_checks

The legacy_checks configuration variable used for configuring active checks in older versions of Checkmk 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. You manage these with the Integrate Nagios plugins rule set, which you can find in Setup > Services > Other services — and by the way, you can also use these without the CMC.

The following example shows how to change an existing legacy check …​

main.mk (old 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 ),
]

… to the new format of custom_checks:

main.mk (new 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.8. Performance data from host checks

The CMC utilises the Smart Ping as its standard for host checks. This means that after a changeover from the 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 a single, or for all hosts, then we recommend that you add an active check by ping for the desired hosts with the Check hosts with PING (ICMP Echo Request) rule set.

If you wish to maintain existing Round Robin Databases (RRDs), you can simply — while the core is stopped — rename the files in the var/pnp4nagios/perfdata/<hostname> directories that start with _HOST_: from _HOST_* to PING*.

Alternatively, with the Host Check Command rule set 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 you must however forgo the advantages of Smart Ping.

On this page