Create nested vars dictionary with Director

Icinga Director
#1

Hi all!
I want to start off by saying I love using icinga2, and I really appreciate the work that goes into it!

I have a question regarding some current capabilities of Director (1.8)

So long story short, I work for an MSP and we pretty regularly inherit networks that have not been maintained by us or even some where we rely on a partner to maintain and we just do incident response. This leads us to a place where we need discovery, some type of automated IP network scan. Luckily I have found NetDisco which so far is working pretty well (scaling issues not included.) This thing finds everything about a device and it is pretty awesome. NetDisco stores all it’s data in a postgres backend which is fairly nice to work with.

Finally, my question is: is there a way to manipulate the vars dictionary such that I can insert nested dictionaries into it through Director? I would love to have something like ‘vars.interfaces.interface.attribute’. I get a lot of information about my interfaces and I would like to include as much of it as possible in a way that I can leverage later. Things like admin status for example in an service apply rule or any of the advanced DSL functions.

Thank you!

P.S. if anyone has questions about netdisco, netbox, discovery, or anything else please reach out!

#2

Hi,

look here; https://github.com/Icinga/icingaweb2-module-director/issues/337 :wink:
Something is comming …

#3

What you already can do is sending a dictionary via import and sync. I am using this in some environments like in one I have a custom cmdb which is badly designed but has values for all the services which should be added to a host. I use json functions of the database to import a json object, then a decode json modifier to get a dictionary and in sync I directly set this dictionary as custom vars. It is also possible to set this for a specific one.

If your config is completely done in the director then you are limited, but if you simply use the directory like I did it is enough or you can have file-based configuration or plugins that use structured data than it may not look nice but work.

The upcoming features are still very useful as we get handling of the last datatype which Icinga 2 supports now.

#4

Thank you Stevie, that thread was exactly what I needed. After taking a long look at all the options and especially what @tgelf had to say about it I realized that I didn’t need the dictionary after all. Really, all I wanted to do was surface the information I was discovering about interfaces, and the best place for that would really be on the service.
I actually agree that for my use case it is a much better idea to define all the services individually and leverage their relationship to the host. Specifically for interfaces the ability to over-ride the alerting threshold for any given one is a must have. This was also super easy to do once I put 2 and 2 together regarding the host variable (and the custom vars) on the service object sync rule.

Thank you!

1 Like