Is it possible to import device modules with this code?

[dhooper6430]

Hi,

I've been attempting to get this running in my environment, I can't figure out how I can import into Icinga what modules are installed into various slots of networking equipment, within netbox I have devices configured with various module-bays, I then have specific checks within Icinga that target those module types.

Is it just not possible yet?
(I can't see anywhere in the code where /dcim/modules is looked at)

[davekempe]

Yeah modules aren't included. Last time we had to include more data, it didn't take too much effort.
I'm curious as to what you are monitoring exactly? What properties of the modulea are you using exactly?

We can probably take a look in a week or so depending on our work load.

[dhooper6430]

I'm mainly monitoring microwave radio systems, generally they're a chassis with N amount of line card slots that can have various types of modules installed into them, my current Icinga configuration I'm using a $host.vars.slot_type to specify what type of line card module is installed into each slot and then using apply rules to apply the correct checks.

Additionally monitoring various DC -48v power systems that again have various slots and different slot configurations depending on what module is installed.

[sol1-matt]

@dhooper6430 do you have an idea on how you want to use modules in your configuration?

I ask because there are 2 ways this can be handled off the top of my head

Object import to a host template that links back to the host

An example of this is sites and regions. They can be imported as templates, the regions inherit their parent regions, the sites inherit their region, the host imports the site. And because of inheritance the host knows which site and regions it is in.

Modify the import module to build a new var available to use as a hostvar.

The import module already does this for things like interfaces. The module does 2 looks ups, one for the hosts, the other for all interfaces. Then for each host it creates vars for interface names (list) and interface details (dict) which can be added to the host object as a var.

Knowing how you want to use the modules lets me know what changes are needed.
At a guess I'd say you need the second option

I haven't included Icinga Service object automation here because it isn't reliable in my experience.

[sol1-matt]

I'm mainly monitoring microwave radio systems, generally they're a chassis with N amount of line card slots that can have various types of modules installed into them, my current Icinga configuration I'm using a $host.vars.slot_type to specify what type of line card module is installed into each slot and then using apply rules to apply the correct checks.

Additionally monitoring various DC -48v power systems that again have various slots and different slot configurations depending on what module is installed.

is $host.vars.slot_type$ and array of slots in the system, something like

    vars.slot_type = [
        "card type 123",
        "card type 456",
    ]

What happens if there is more then once card of they same type?

It seems to me there could be a need for more uniqueness here. Have a read of the way I implemented interfaces, that seems like a pattern I could reproduce but importantly it only includes a unique interface name + information for specific custom fields, no other interface information is pulled in and I'm not sure if with modules it would be appropriate to import other module information in as well.