Monitoring vhosts , defined as Services in NetBox

[jadsy2107]

Hi there, great module !

In NetBox, I've defined a list of services assigned to their relevant device/vm

From NetBox, I'm trying to import the virtual machines "services" object into icinga as an array to iterate through,

This generates the following host vars, as an object, which my Service Apply Rule is unable to iterate through

I'd like to iterate through the devices services, using a Service Apply Rule and also be able to access the "port" from the host.var

I've currently got it working by importing the ${service_names} object instead, which contains an array of just the names, which I am iterating through assigning just the http_address part, without being able to access port information.

I've tried a couple of modifiers, including Decode a JSON string but this does not work.

Do you have a better solution for this ? Am I barking up the wrong tree :O ?

[sol1-matt]

This is getting into the quirks of how director functions rather than the import module and I don't think you'll get things working looking at how you are naming the services in Netbox.

The problem you are facing is you want to create and apply rule from an array of dictionaries.

You can almost do this but I ran into problems setting this up. If your dict ends up in the object name things break, a trip to the db to fix. You can get config.name in the object name but I couldn't access the dict objects cleanly.

There is a way to import json into a icinga var then pass it to the check as a json string but that relies on the check knowing how to read that json var and the command arguments using a json macro.

One solution built into the import module is another field called service_names which is an array of service names rather than the dict.

This is useful in service apply rules Assign Where statements if you are consistent with how you name services. Netbox service templates help here. You can then assume port and other values.

I've also done things like <prefix> <target name>, eg: HTTP example.com, and then used Import Modifiers to create a new array of values.

In general I find director and this module most useful for

• creating hosts
• adding vars to hosts that services can use if
  • you have an array of values where the service only has a single parameter that varies
  • you have one complex dict per service per host: eg 1 HTTP check per host

Not so useful for array's of dictionaries with arbitrary labels.

One last out of the box solution would be to import the services into Icinga as hosts then you can use a simple apply rule as you will have a single check per host now. The reason I give this is your example is http based and while there is benefit of having the service on the parent host I've found it is more useful to put it on it's own host so I can run checks from outside the environment easier as the zone it runs it doesn't matter, I find this is closer to end user experience and produces better monitoring. You can use groups to tie things back to the webhost.

[jadsy2107]

Great explanation, thanks !