Host.vars.os missing or not enabled?

funk0id · March 20, 2019, 3:57pm

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?

hamester_citti · March 21, 2019, 8:11am

Hi and welcome,

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

log1c · March 21, 2019, 8:31am

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.

funk0id · March 21, 2019, 11:03am

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!

hamester_citti · March 21, 2019, 11:14am

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 =		"172.00.00.000"
    notes =		"Windows Domain Controller"
    vars.storage =      [ "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"
}

funk0id · March 21, 2019, 12:06pm

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.

log1c · March 21, 2019, 12:27pm

The director documentation has a part on datafields and datalists: https://icinga.com/docs/director/latest/doc/16-Fields-example-SNMP/

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”

putting one service to one host directly (in Director: choose the host object, go to services tab and add a service.)
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)

Creating apply rules to assign the service checks based on filters to multiple hosts or a host group, or this, or that
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

funk0id · March 21, 2019, 12:57pm

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?

twidhalm · March 21, 2019, 1:30pm

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

funk0id · March 21, 2019, 2:56pm

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

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?

dnsmichi · March 21, 2019, 3:33pm

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.

Cheers,
Michael

hamester_citti · March 22, 2019, 5:19am

YES!

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

funk0id · March 22, 2019, 10:15am

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

log1c · March 22, 2019, 10:20am

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

dnsmichi · March 22, 2019, 10:30am

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.

Cheers,
Michael