Allows to install configure and tune an OMD distribution and OMD multipal sites




7,984 latest version

0.4 quality score

Version information

  • 1.0.2 (latest)
  • 1.0.1
  • 1.0.0
released Jun 1st 2015

Start using this module


tanny1910/omd — version 1.0.2 Jun 1st 2015


An open monitoring distribution (OMD) puppet configuration module

This module is intended to configure, install and manage an OMD distribution.

If required, this will use the omd repository. This is the the default behaviour, so if you're managing your repos, make sure to disable this. Last note concerning directories and packages : Othe omd packages do contain the OMD version in the package name : this makes it difficult to have a module that works out of the box and does not hardcode a specific version. We'll try to maintain this hardcoded version, but in case you need something else, please just use the omd_version class param in the omd class. Or give us a recipe to improve that ;)

This module borrows files from check_mk for the agent setup : those file license is under manifests/check_mk/agent

How to use the server side

Install and start OMD :

include omd

If you don't want the offical repositories to be setup (your have your own) :

class {omd: with_repo => false}

create an OMD site which will be available on http:///:

omd::site {'test': }

create another OMD site on the same machine

omd::site {'tanmay': }

This will install the 'test' site and change the default http (htaccess) password for the user

Add a multisite remote ... site/nagios/livestatus

omd::check_mk::multisite::site { '': site => 'tanmay', alias=>'remote1' }

Remove the default OMD user :

The % char actually tells the defined resource to strip everything after it, so that the omdadmin user, which is the real username can be used for both OMD sites. This unfortunately is required because of puppet not allowing duplicate defined resources titles

omd::site::user {'omdadmin': site=>'test', ensure=>absent}
omd::site::user {'omdadmin%2': site=>'tanmay', ensure=>absent} 

Add a custom user

This use will be added with a custom password to the htaccess and given admin rights in multisite (password : "changeme")

omd::site::user {'tanmay': site=>'tanmay', privileges=>'admin', pass_md5=>'HVSJ.h631LfUw'} 

Enable access over SSL/https for the omd users :

Please note this requires you manage the apache module with -say- puppetlabs-apache

class { omd::ssl::vhost: sites=>[test], port => 443}

import all exported resources

This will import everything for the OMD site tanmay + all globally explorted resources


####Create custom check_mk variables

they are added before any inventory action, but beware that some variables only influence further inventories

omd::check_mk::var::set    {ignored_checktypes: site=>'test', content=>'[ "ipmi_sensors", "if", "if64" ,"nfsmounts"]'}
omd::check_mk::var::append {ignored_checktypes: site=>'test', content=>'["ipmi"]'}
omd::check_mk::var::set {inventory_df_exclude_fs: site=>'test', content=>'["nfs", "fuse"]'}
omd::check_mk::var::set {'filesystem_default_levels#levels': site=>'test', content=>'(80, 90)'}
omd::check_mk::var::set {'filesystem_default_levels#levels_low': site=>'test', content=>'(60,75)'}
omd::check_mk::var::set {'filesystem_default_levels#magic': site=>'test', content=>'0.5' }
omd::check_mk::var::set {'ntp_default_levels': site=>'test', content=>'(10, 200.0, 1000.0)'}

check parameters...

#FS check
omd::check_mk::var::set    {check_parameters:     site=>'test', content=>'[( (85,90,0.5),   ALL_HOSTS, [ "fs_/var","fs_/tmp","fs_/home",])]'}
omd::check_mk::var::append {'check_parameters|1': site=>'test', content=>'[( (90,95,1)  ,   ALL_HOSTS, [ "fs_/$",])]'}

#specific setup for wn /var
omd::check_mk::var::append {'check_parameters|2': site=>'test', content=>'[( (90,95,0.5), [ "wn", ], ALL_HOSTS, [ "fs_/var"])]'}

#MEMORY usage over 110/150% of RAM
omd::check_mk::var::append {'check_parameters|3': site=>'test', content=>'[( (110.0, 150.0),ALL_HOSTS, [ "mem.used",] )]'}

#don't use the deprecated network check
omd::check_mk::var::set {linux_nic_check: site=>'test', content=>'"lnx_if"'}

Performance data...

#these are related, so make sure the first one is created before the second one
omd::check_mk::var::set {'_disabled_graphs': site=>'test', content=>'["fs_","Kernel","NTP","Number of threads","Uptime"]' , concat_order=> '009'}
omd::check_mk::var::set {"extra_service_conf#process_perf_data": site=>'test', content=>'[ ( "0", ALL_HOSTS, _disabled_graphs ), ]'}

host groups

omd::check_mk::var::set    {define_hostgroups:     site=>'test', content=>"'true'"} 
omd::check_mk::var::set    {host_groups:     site=>'test', content=>"[( 'wn', [ 'wn' ], ALL_HOSTS )]"} #association des tags à des hostgroups
omd::check_mk::var::append {'host_groups|1': site=>'test', content=>"[( 'se', [ 'dpm_disk' ], ALL_HOSTS )]"}
omd::check_mk::var::append {'host_groups|2': site=>'test', content=>"[( 'se', [ 'dpm_head' ], ALL_HOSTS )]"}
omd::check_mk::var::append {'host_groups|3': site=>'test', content=>"[( 'other', [ '!wn', '!dpm_disk' ], ALL_HOSTS )]"}

Manually add hosts to the config :

omd::check_mk::addhost{'': site=> test, tags=>'snmp|Xtreme|BD-8810'}

append to arbitrary var

omd::check_mk::var::set {'_toto': site=>'test', content=>'{"a" : 1}' }
omd::check_mk::var::append {'_toto#a|1': site=>'test', content=>'1' }

create a nagios service adding it to host tags

omd::check_mk::legacy::service {'ldap': site=>     'tanmay', command =>'check_tcp!2170', mk_tags=>['ce','cream','dpm_head','bdii'], perfdata=>true}

create a nagios service adding it to a specific host

omd::check_mk::legacy::service {'backbone': site=> 'tanmay', command =>'check_snmp!-P 2c -C public -o ifHCInOctets.3003,ifHCOutOctets.3003 -u InBytes,OutBytes -l bandwidth', mk_hosts=>[''],}

create a nagios command, and use it

omd::nagios::command {check_nrpe_long: site=>'tanmay', command => '/usr/lib/nagios/plugins/check_nrpe -u -H $HOSTADDRESS$ -c $ARG1$ -t $ARG2$'}
omd::check_mk::legacy::service {'dummy_cvmfs': site=> 'tanmay', command =>'check_nrpe_long!check_hung_ncm!300', mk_tags=>['wn']}

monitoring puppet (server side)

omd::check_mk::server::plugins::puppet { 'tanmay': }

puppetdb cleanup

If you have nodes that should not be monitored anymore using the puppetdb (removed nodes), you can remove them from the monitoring using this command :

puppet node clean --unexport <nodename>
puppet node deactivate <nodename>

foreman integration

If you happen to be using foreman for managing your nodes, take a look at the puppetdb_foreman plugin (for foreman), which is aslo shiped as an RPM (ruby193-rubygem-puppetdb_foreman) by the foreman team :

How to use the client side

Install the check_mk agent. This will start/enable the xinetd check_mk service :

#using hiera for specifying the IP whitelist
include omd::check_mk::agent

Add a check_mk tag "nagios" on a host.

ensure_resource( 'omd::check_mk::addtag' ,'nagios',{})

Add an MRPE test that will be automatically inventoried ( and exporting a check_mk tag) :

omd::check_mk::mrpe::check{'hung_nrpe': command=>'/usr/lib/nagios/plugins/check_procs -w :5 -C nrpe'}

monitoring puppet (client side)

include omd::check_mk::plugins::puppet


  • refactor/rework
  • lower puppet inter-dependencies on client hosts
  • well, check the doc is correct :)
  • add support for notification definition/setup
  • see if we can remove the binary "waitmax" from the module


This implements exported resources and collectors for check_mk tags as explained in this blog, but adapted to OMD :

If you limit cron usage, please make sure to allow the OMD users, for instance, add : cron::allow {tanmay: } -> omd::site {'tanmay': }

Tested on : Scientific Linux 6.5


2015-02-18 :

the omd::check_mk::addhost resource did not allow for purging manually added hosts. Those definitions have been moved into the puppet/ subdirectory.

This WILL require that you manually cleanup your check_mk host definitions in etc/check_mk/conf.d as it will create duplicate host resources. But now the puppet directory beeing managed, hosts removed from the puppet config will really be automagically removed from check_mk.

The puppet subdirectory was owned by root : owner is now the omd user.

Use text version of the "mode" param in puppet file resources (puppet warning). 2015-06-01 :

Dependancy Issue has been resolved till 1-June-2015