Import devices and virtual machines from nautobot into icinga2 to monitor them.
$ cd /usr/share/icingaweb2/modules
$ git clone https://github.com/inexio/icingaweb2-module-nautobotimport.git nautobotimport
$ icingacli module enable nautobotimport
All configuration is done in the web interface under the "Automation" tab of icinga2 director. Please read to the official documentation before configuring a netbox import.
- add an "Import Source"
- Key column name:
name
(the hostname) - fill out all other required files according to the tooltips shown
- test the Import source via the "Check for changes" button, "Preview" tab and finally "Trigger Import Run"
- add a "Sync Rule"
- Object Type: "Host"
- by default will import all objects present in netbox. You can tailor this by setting "Filter".
For example, only import objects, which have a certain field set:
custom_fields__icinga2_host_template__label>0
.
- add the desired Properties to the rule
- setting
object_name
,address
andaddress6
toname
is generally desireable
- test the Sync Rule via the "Check for changes" and finally "Trigger this Sync" buttons.
- add an import job to run the import regularly
- add an sync job to run the sync regularly
This plugin pulls all available objects with all their fields into icinga. Since the data in netbox mostly consists of nested objects, you will either have to autoflatten (default for custom_fields and interfaces) the elements or you have to apply the "Get specific Array Element" modifier to deconstruct the objects. and access the object elements:
primary_ip4:
{
address: "192.168.0.1/24",
family: 4,
id: 1,
url: "<NETBOX URL>"
}
Apply modifier to export address field:
Because Icinga2 does not like the format Netbox uses (/subnet appended to address), we need to strip this away with another modifier:
Now you can access the primary_ipv4 directly as a property :arrow_right:
ipv4_address: "192.168.0.1"
A list of all possible fields can be seen in the "Preview" of your Import Source, in your Sync Rule while adding a new property or in your API itself: https://nautobot.example.com/api/dcim/devices/, https://nautobot.example.com/api/virtualization/virtual-machines/.
In some cases additional fields are provided:
cluster
is replaced by the actual cluster object as returned by the API, instead of just the id/name.interfaces
is added, so configured IP addresses can be reused in icingaservices
is added, so configured services can be reused in icinga
The general structure and a few tips were lifted from icingaweb2-module-fileshipper. Thanks!