Version 6 (modified by jonmills, 8 years ago)



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 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 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.

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


all_hosts = [