How deep do you granulate your hosttemplates?

Hi Everyone,

As fresh owner of the Icinga2 v2.0 Book, i was ecxited read the part of the Director, and I´m still at the first chapters. A point was how to setup the hosttemplates and their inheredity.

My attempt in the moment is shown in the picture. Im still thinking of doing hosttemplates for vendors like Cisco, LANCOM etc… or if i solve this through datafields.

So my question is how deep do you go?

Let the discussion begin.

1 Like


I’d say this depends on the audience. If you’re building a setup only for you and your small team, you can expect a certain workflow, e.g. that they set a specific vendor type, or version a custom property when adding the host. You can make this mandatory, so they and you know about this fact.

When you’re the admin for the Director, and your user base splits up into dedicated teams from different environments in your company (also with fine granular permissions), I would define as much as possible up front. This is to keep the workflow on how to add a new object very tight and clean. Typically, users make errors with free form or listed fields, and then the wrong camera version is deployed.

Instead, when such a thing is documented as pre-defined template (even where they don’t have access to modify), they’ll know that the “imports” is very important for the good behaviour.

One thing you need to keep in mind though - the longer and deeper the template tree goes, the harder it is to maintain over time. Likewise, when you decide to remove a template because that version is EOL, you’ll need to clear up all dependent objects too. This needs a strategy for removing stale entries and dependencies.

At this stage, a specific data field with a more generic template can probably solve the hassle for not having to modify the templates later, or even deleting them.

Plan ahead for the next five years too:

  • Are there more different types expected or will they stay the same?
  • When working with different teams, will there be more new teams and templates added over time?
  • Are you going to automate things later on with e.g. using a CMDB or AD or a different storage?
    • If yes, a custom property is easier to set than to match a possible template for this object type

This isn’t just Director specific, I have seen this with other old config tools too (LConf, etc.).


1 Like

Hi Mario,

as Michael pointed out, this is everyone’s personal choice. To me, this looks way too granular. I’d suggest to drop most of those templates and throw in some Custom Fields, like this:

  • Device Type: Physical Server, Virtual Server, Container, Network Device, Environmental Sensor, … (predefined data list)
  • Operating System: Linux, Windows, IOS, IOS XE, … (list)
  • Operating System Family: RedHat, Debian, … (list)
  • Operating System Version:

While I like the idea of having “IP Based Device” distinct from non-IP-based ones, I would introduce this only once the first non-IP-based devices pop up. Changing the root of such a “tree” isn’t a big thing and can be done at any time later on.

Templates for Agents are useful, and when using the Self-Service-API it could make sense to use different ones for different purposes.



Hi Thomas, hi Michi,

sorry for being bit late with a response, 'cause i had something different to do.

Thx for your advices, i will have a looking into the custom fields and lists (which i had already in mind :slight_smile: ).

If i run into a problem, well I´ll be back! :wink:

Cheers from Berlin,

1 Like

Will you be at Icinga Camp Berlin btw?


I was at the Camp 2017. This year i won´t be able to be there.

But since my supervisor decided to switch from Icinga2 to Check_MK and now back to Icinga2, I think he will spend money into a workshop for us at Netways. (Thats what I hope :))

But proudly, I still have my mug and lanyard from 2017.

1 Like

First: Thanks for buying the book. I hope it lives up to the expectations. :slight_smile:

What I build in most customer setups: 3 Subtrees. One for OS, one for Application, one for responsible team. Every host inherits at least one out of each subtree.

In the base of the os tree I set all the defaults like check_command, check_interval and so on. In bigger setups I normally use quite a lot of levels in the trees even when I don’t change anything. This helps with organizing and changing things later. So I tend to have os->Linux->RHEL->RHEL 7 even when they don’t change a lot just in case the need changing later.

Of course a host can inherit several templates from a subtree. e.g. Hosts with a full LAMP stack inherit Apache and MySQL.

But as the others said: That’s very much up to your needs. I just often happen to set up environments for people rather new to monitoring. So I take this as a starting point. I changes later more often than not.


Hello Thomas,

Yes the Book is great and really worth to buy, ok… thats what I also said for the 1st Edition, which I also own :slight_smile:

Is there any chance to see a screenshot from the tree you would suggest?



I’ll try and build one in a testing environment. Right now I don’t have one accessible.


Here you are.

Please keep in mind that this might be a starting point, not the one and only source of truth. Adapt to your needs.

The os template is the only one with details like check_command and check_interval. Every host needs to inherit at least one out of each tree.

By far not all templates contain any setting or service. Some are just there for organizational reasons.

I try to always attach services or service sets to templates and avoid apply rules in director as much as I can. Adding services to hosts is then done by inheriting the according templates.


Bad Red Giant and Toy Database :grin:

Thank you all so much. Now i got enough to think about with your and the information from Michi and Thomas.