Legacy Checks

Check_MK can do many things for you and ships lots of checks based on its special agents and on SNMP. It also allows normal Nagios plugins to be called via MRPE. However, there are some cases, where it is preferrable to use classical active Nagios checks configured in Nagios with define service.... Examples are:

• Plugins that must be run on the Nagios server but should not be assinged to localhost.
• Plugins that can be run on the Nagios server and might have a large execution time.
• Checks which neither need an agent nor SNMP - e.g. check_http.

While it is - of course - possible to define those checks completely outside the scope of Check_MK in your Nagios configuration, you can let Check_MK do that for you. It does not perform those checks but it can create the Nagios configuration needed for that and handles those services much like its own checks.

Defining checks to be executed in Nagios requires two steps:

1. Defining commands: i.e. command lines or check plugins
2. Defining services: on which host which command shall be executed with which parameters.

The first step can be done in main.mk by making use of extra_nagios_conf, e.g.:

extra_nagios_conf += r"""

# ARG1: URL to get
define command {
    command_name    check-http
    command_line    $USER1$/check_http -I $HOSTADDRESS$ -u $ARG1$
}

define command {
    command_name    check-smtp
    command_line    $USER1$/check_smtp -H $HOSTADDRESS$
}

"""

As of version 1.1.7i5 - the second step, the creation of service definitions - can be done with the new configuration variable legacy_checks:

legacy_checks = [
  # On all hosts with the tag 'web' check fetching index.html via HTTP,
  # service description "Homepage", process performance data
  ( ( "check-http!/index.html", "Homepage", True), [ "web" ], ALL_HOSTS ),

  # Check two specific hosts via SMTP, service description "SMTP",
  # do not process performance data
  ( ( "check-smtp", "SMTP", False ), [ "mailsrv01", "mailsrv02"] ),
]

The variable legacy_checks is a list of entries similar to datasource_programs. But the first element of each entry is not a string but a triple of the following three elements:

1. The check_command to execute, maybe including arguments separated by !
2. The service_description as it should appear in Nagios
3. True if the check outputs performance data, otherwise False

This is an example for a service definition created by legacy_checks:

# Legacy checks

define service {
  use                           check_mk_default
  host_name                     mailsrv01
  service_description           SMTP
  check_command                 check-smtp
  active_checks_enabled         1
  contact_groups                +supper
  notification_period           10x5
}

Why should you not define those services manually for Nagios? Well, there are a couple of advantages of letting Check_MK do it for you, amongst of which are:

• You can make use of host tags and thus write intelligent rules about which checks to execute on which hosts.
• Check_MK's rules for Nagios configuration also apply to legacy checks, such as service_groups, service_contactgroups and extra_service_conf.
• Disabling hosts by removing them from all_hosts or using only_hosts will not break your configuration but automatically removes all legacy checks for the vanished hosts.
• Check_MK's --backup and --restore will nicely cover those checks es well.