Once you install OMD and create a site, you'll have an install homedir, $OMD_ROOT, which will look like /omd/sites/sitename (whatever you set your 'sitename' to be). Relative to that base, all of the configuration files used by Check_MK are found in ~/etc/check_mk. You don't need to worry about configuring Nagios itself, because that's the point of running Check_MK. It dynamically rebuilds your Nagios object configuration for you.

Use the tarball attached to this page to get an idea of a basic Check_MK configuration suitable for monitoring a Eucalyptus cluster. (Note that you'll need to change hostnames found in hosts.mk to suit your environment).

All of the files described here are completely arbitrary, and were just the logical layout preferred by this author. If you pleased, you could group all Check_MK declarations into one big main.mk file (just as you can write all Nagios object configuration into one big nagios.cfg -- but who does that?).

As you read through the configurations below, it will help to refer to the Check_MK configuration reference page.

Also, never forget the always-enlightening Nagios object definitions reference.


I try to define global things here, like:

define_hostgroups = True
define_servicegroups = True
define_contactgroups = True
nagios_illegal_chars = '`~!$%^&*|\'"<>?,()='
generate_hostconf = True
perfdata_format = "pnp"
tcp_connect_timeout = 25.0
inventory_max_cachefile_age = 120 # seconds (Default: 120 seconds)
inventory_check_interval = 3 # minutes
inventory_check_severity = 1
always_cleanup_autochecks = True

Note that setting the 'inventory_check_interval' means that Check_MK will use the check_mk_agent to run a regularly scheduled inventory of the host that it's monitoring. So it can tell you when it's not monitoring everything that it could be monitoring. Setting 'inventory_check_severity' to 1 means that when the service 'Check_MK inventory' discovers a check it knows about, but which it isn't monitoring, it goes into WARNING status (recall that in Nagios lingo, OK is an exit status 0, WARNING is 1, CRITICAL is 2, and UNKNOWN is 3).


Used for writing traditional active checks into your Nagios configuration. Check_MK calls these "legacy checks", as if they're antiquated and less useful. But sometimes you just need to bang on a port, you know? To define an active check in Check_MK, you basically are writing raw Nagios config inside of special 'extra_nagios_conf' tags. Use of legacy checks with Check_MK is documented here.

For our purposes, with respect to Eucalyptus, active checks are ideal to test the running status of our Cloud Controller and our Node Controllers. For example:

extra_nagios_conf += r"""
define command {
    command_name    check-http
    command_line    $USER1$/check_http -I $HOSTADDRESS$ -p $ARG1$ -u $ARG2$ -r $ARG3$
legacy_checks += [
  ( ( "check-http!8774!/axis2/services!'<h3><u>EucalyptusCC</u></h3>'", "Cloud Controller", True), [ "cloud" ], ALL_HOSTS ),
  ( ( "check-http!8775!/axis2/services!'<h2>Deployed Services</h2><h3><u>EucalyptusNC</u></h3>'", "Node Controller", True), [ "nodes" ], ALL_HOSTS ),

For this to make any sense, you need to have an understanding of what check_http is, and how it works. It's part of any basic Nagios install. In particular, it's part of the nagios-plugins package. On a RHEL system, by default, it would get installed in /usr/lib/nagios/plugins, but since it's part of OMD in our case, it lives at $OMD_ROOT/lib/nagios/plugins/check_http. It's helpful to locate the plugin itself, and run it once from the command line without any parameters. Then you can see what is going on in those 'legacy_checks' declarations.


  • Allows you to inform Check_MK of checks you want it to inventory and build Nagios configuration for (e.g., if they are custom or non-standard checks)
  • We know we ought to have certain processes running on our Cloud Controller and our Node Controllers. This informs Check_MK of what we expect to see, and in turn Check_MK constructs a service to test it with Nagios.
# Checks manually defined here will be discovered during the inventory process

inventory_processes_perf += [
  ( [ 'nodes' ], ALL_HOSTS, "Node Controller", "~.*/httpd -f //etc/eucalyptus/httpd-nc.conf",ANY_USER,1,1,2,10 ),
  ( [ 'cc' ], ALL_HOSTS, "Cluster Controller", "~.*/httpd -f //etc/eucalyptus/httpd-cc.conf",ANY_USER,1,1,12,25 ),
  ( [ 'cloud' ], ALL_HOSTS, "eucalyptus-cloud", "eucalyptus-cloud",ANY_USER,1,1,2,4 ),


Check_MK will define contactgroups for you, provided you're enabled that feature. Contactgroups are defined automatically when Check_MK finds host or service objects that declare a specific contactgroup. However, you cannot declare Contacts themselves using a Check_MK declaration. Nagios fails to compile its objects if contactgroups exist with no contact objects. The result is that you must manually create contact objects using Nagios syntax inside of 'extra_nagios_conf' tags.

# All hosts have alerts sent to the 'admins' contactgroup
host_contactgroups += [
( "admins", ALL_HOSTS ),

# All services have alerts sent to the 'admins' contactgroup
service_contactgroups += [
( "admins", ALL_HOSTS, [""] ),

# Give the 'admins' contactgroup has a pretty Nagios Alias
define_contactgroups = {
    "admins" : "Nagios Administrators",

extra_nagios_conf += r"""

# This is a Nagios template to be inherited by all contact objects;
# Note the "register = 0" at the bottom.
define contact{
        name                            generic-contact
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r,f,s
        host_notification_options       d,u,r,f,s
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        host_notifications_enabled      1
        service_notifications_enabled   1
        can_submit_commands             1
        register                        0

# This is our site admin user.
define contact{
        contact_name                    omdadmin
        use                             generic-contact
        alias                           OMD Admin
        email                           omdadmin@localhost
        host_notifications_enabled      0
        service_notifications_enabled   0
        contactgroups                   admins



This is fairly self-explanatory. The only innovation here is that, unlike with Nagios, hosts are not directly mapped to hostgroups; but instead, hostgroups are derived from the tags you place on hosts in your hosts.mk file.

host_groups = [
( 'cc', [ 'cc' ], ALL_HOSTS ),
( 'nodes', [ 'nodes' ], ALL_HOSTS ),
( 'vm', [ 'vm' ], ALL_HOSTS ),

define_hostgroups = {
	"cc" : "Cloud Controllers",
	"nodes" : "Worker Nodes",
	"vm" : "Virtual Machines",

The second construct, 'define_hostgroups', isn't strictly necessary. It is only there to allow us to define pretty names (nagios aliases) for the hostgroups above.


Take a moment to read about how Check_MK uses host tags.


all_hosts = [



  • Allows you to ignore an entire type of check for all hosts across the board. It's as if Check_MK no longer knows what that checktype is.
    • For example, this tells Check_MK to never check for NFS mounts:
      ignored_checktypes += [


  • Allows you to ignore a checktype on specific hosts (one, or all of them).
    • For example, this tells Check_MK to ignore all NFS mounts on one specific host.
      ignored_checks += [
      ( [ 'nfsmounts' ], [ "euca-m.unc.ben" ] ),


  • Allows you to ignore a specific instance of a type of check on one or more hosts.
    • For example, this tells Check_MK to ignore only the NFS mount /home/*, only on hosts with the host tag "linux". (This would be good if, for example, you automount your home directories)
      ignored_services += [
      ( [ 'linux' ], ALL_HOSTS, [ 'NFS mount /home/*' ] ),


  • This allows you to get around faulty DNS, or routing issues, dual-homed issues, by using a "fakedns" built into Check_MK
ipaddresses = {
"www.renci.org" : "",

For our purposes, we can use this to map the hostnames of KVM VMs to their IP addresses, in the event that we don't have DNS working in conjunction with Eucalyptus...


As you may have guessed, this works a lot like hostgroups:

# This creates a service group around the results of all the KVM service checks.
service_groups = [
 ( "euca-vm", [ 'nodes' ], ALL_HOSTS, [ "KVM*" ] ),

# Give a pretty Nagios Alias to our service group for KVM VMs
define_servicegroups = {
   "euca-vm" : "Eucalyptus Virtual Machines",