Host.vars.os missing or not enabled?

I’m having my first go at service templates following the how to guide here, but I’ve hit a problem. Unlike the screenshot here here I’m unable to locate host.vars.os in the “Assign where” field?

Is there something I’ve not enabled perhaps?

Hi and welcome,

your sceenshot ist very blurred. Please import the screenshot in the thread or post your config.

1 Like

To have host.vars.os appear in the assign rule fields you first have to define a datafield named “os”.
After this you have add that datafield to a host template, so that hosts importing the template get the field.
Then you can fill the datafield with a string and can use it in the assign rule.

Extra: You can define a datalist and save some default os types (Linux, Windows,…) in there. Then you edit the datafield “os” to the type “Datalist” instead of “String” and choose the newly created datalist.
Then you will also get a drop down list to choose your OS from.


Thanks @log1c , is there some documentation or a top to bottom tutorial you can suggest I review to get my head around this. Trying hard to make this work as the platform has huge potential for me but the learning curve is feels crazy!

Do you know the documentation part?

I can give you an example in command line:

template Host "windows-24x7" {
	import "generic-host" 
  	retry_interval = 2m
	check_interval = 10m

	vars.os = 	"windows"
	vars.sla = 	"24x7"

	vars.notification["mail"] = {
		groups = [ "operating", "windows" ]

object Host		"YourHost" {
    import		"windows-24x7"
    address =		""
    notes =		"Windows Domain Controller" =      [ "c" ]

apply Service "service-windows-" for (service_name in host.vars.service) {
        import "generic-service"
        check_command = "nrpe"

        vars.nrpe_command = 	"CheckServiceState"
        vars.nrpe_arguments = 	service_name
		vars.nrpe_no_ssl = 		true
		vars.sla = host.vars.sla

		assign where host.address && host.vars.os == "windows"

Thanks, so I’m trying to get around the hierarchy I need to adopt for monitoring windows hosts.

Based on the above, you’re monitoring a single host called YourHost, that imports the template windows-24x7 which then imports generic-host?

Within generic-host I assume you have standard checks such as a ping check etc?

So for me starting from the beginning, all I’m really after in my generic-host, which i’m assuming is a host template and could be linux or windows based is:

  • ping4 / ping4-windows
  • An agent communication check (not sure what check command would be best)
  • A way of pulling in the operating system?

That would then be inherited to a Windows-Host host template which consists of:

  • Importing generic-host
  • Windows CPU
  • Windows Disks (All disks as numbers per host vary)
  • Windows Memory / Swap etc.

Given the above, would you create service templates for:

  • ping4
  • ping4-windows
  • Windows CPU
  • Windows Disks
  • Windows Memory

Then make a service group called Generic-Windows-Hosts consisting of each of these?

Think the gap for me is I’m wanting to dive right into Icinga2 using Icinga Director, but structure wise it’s just hard to figure out where to begin.

The director documentation has a part on datafields and datalists:

To give you some idea how you could layout your hosts and service templates, I’ll share a screenshot of (a part of) my trees. Don’t consider them the go to way, they are possibly far from perfect and just what I am used to.

The generic templates are mostly for importing fields, variables or information.
The more specific templates fill the fields (e.g os=linux), define variables or are used for assigning checks.

The structure is still the same like in icinga1 or nagios.
Define a host template to collect generic information for that type of host. Define a host that imports the template and fill this object with detailed information (os, snmp community,…).
Then define a service template, the defines the check command and the needed variable fields.
After this you have multiple option with the director how to get a service assigne to a host.

The old fashioned “nagios ways”

  1. putting one service to one host directly (in Director: choose the host object, go to services tab and add a service.)
  2. the known way of adding the service checks to a host template (in Director: same as above, just switch “host object” with “host template”)

The icinga2 approach (better imo)

  1. Creating apply rules to assign the service checks based on filters to multiple hosts or a host group, or this, or that :wink:
  2. creating service sets that combine default checks for a type of host (e.g Windows with cpu, mem, disk, swap) and assign this set like an apply rule.

And the Director can’t even handle all the options of icinga2 atm


So it appears that I’ve already got a generic-host definition in my templates.conf but that’s not visible within director.

I take it you are best to remove these and start from scratch within Icinga Director?

Yes. The one you see is from the default configuration shipped with Icinga 2. You should only use it as an example.


Simple way is to just remove / comment out all of the config and build it from director then?

Thanks for your assistance with all of this, really struggling to get to grips with this against the wire :frowning:

Is there any way of getting rid of the default monitor that’s setup against the icinga server itself? Can’t actually see any configuration for that within hosts.conf?

When it is not imported into the Director, just edit icinga2.conf and remove the include_recursive "conf.d" line. If you’d need the commands.conf I’d suggest moving it into the global-templates zone as directory in zones.d.


1 Like


YES! But there is a customized value for retry_interval and check_interval in the template

In general: You can set all your information, checks, variables in the host template. A host template can inherit another host template.
I do not know the director, but it’s the same structure. Try your best, test by yourself, use the docs/ community and do not despair :wink:

1 Like

Having done that it, does indeed remove the internal monitor and effectively start a blank config but breaks the api settings?

Correct. Because the api.conf file also lies in the conf.d directory. Either put the information somewhere else in another conf file or, what I am doing is:
edit the icinga2.conf to include some of the config files:

// include_recursive "conf.d"
include "conf.d/api-users.conf"
include "conf.d/commands.conf"
include "conf.d/app.conf"

Not sure if the app.conf is even needed :smiley:

Ah, we’re talking about ApiUsers here, thanks. I would move away from conf.d, since package managers have proven to be weird and updating/changing this directory in a way you would not expect.

As said, figure out your local zone name, and put the files in there. icinga2 object list --type Zone and I’d assume it is just master as configured by the node wizard.

app.conf isn’t needed at all, Icinga just provides this for convenience reasons for easier user editing. Typically you don’t need it, unless you want to globally disable notifications on a config level for instance.


1 Like