Nagios Support Forum

Hello,

We've previously looked into migrating into Nagios XI (over a year ago) but time wasn't on our side, but we're back again. The general structure of how we want to create services, templates, groups & hosts has been decided so that we can essentially "tag" a host with the relevant pieces and it'll inherit the services for those tags (e.g. "web" or "mysql" for relevant checks).

This is quite different to our current core set up that was created many years ago and has been added to by various people over the years, meaning it's not 100% consistent and a lot of it could be reduced down so there's little repetition.

We're looking into ways that we can make our migration a tad easier (by refining the process locally before applying to the new XI server once that's in place). Initially I thought we'd enter all the templates, groups etc. into the system via CCM however overall it's quite slow when there's lot of its that are the same that you have to re-enter on various pieces (even if you copy previous definitions it usually means several overrides / enabling it etc.). One thing especially was the default "inheritance" of groups / parents / hosts etc. where it's set to "Standard" by default whereas we mostly want to use +, so each level extends the previous template/level.

We're wondering if there's any downsides (or if it's a bad idea) in manipulating the nagiosql database? We were thinking of creating a script that read the structure of what we want from a definition file that we create which is interpreted into the correct structure for the database? This would handle creating the relevant contact groups, contact templates, host groups, host templates, hosts, service groups, service templates, services, time definitions / periods, variable definitions and all the relations between it.

Or have we missed something that's available in Nagios XI (I don't think the "Import Config Files" functionality would be useful in our case).

Thanks for your time

We're wondering if there's any downsides (or if it's a bad idea) in manipulating the nagiosql database?

We do NOT recommend manipulating the database directly! There are a couple of other (safer) options:

1. Add objects via the REST API. You can view the REST API documentation and examples under the Help menu in Nagios XI.
2. Drop your configs in the /usr/local/nagios/etc/import directory, and run /usr/local/nagiosxi/scripts/reconfigure_nagios.sh script.

Tips:
- You will still need to prepare your configs before importing them via the Config Import Prep Tool: https://assets.nagios.com/downloads/nag ... p-Tool.pdf
- Import files in batches and check for config errors
- Follow the EXACT order as described below:

Thanks - any particular reason it's not recommended? Adding in some new services that were variants of existing ones was extremely quick via the database & didn't have any issues when reloading config, however I understand if it's not recommended as it is subject to change.

Our main concerns with either using the REST API (which I had actually forgotten about until after posting this thread) & the config import are we need to essentially build all the config in the correct format... as mentioned, we're wanting to change & improve how we currently define our services/hosts etc. which is nearly planned out, having to then create all the necessary define host/service/groups etc. would take time (and formats etc. would need to be verified, whereas inserting data into a database with pre-defined potential values is simpler I think?).

If we were to use the REST API, do we need to import items in a specific order? I note we'll have to pass force=1 in order for it to work due to inheritance etc. There also doesn't seem to be an ability to create contacts, contact groups or time periods. I think it would be quite a bit of trial and error to ensure we get the parameters correct (which we won't know if using force=1).

Is there a way to specify options via the API / import about the group inheritance? e.g. in the XI GUI, when managing associated host groups for a template/host, it'll have the option for "+", or "null", or "standard". By default everything is specified as standard however we want all of ours to have a default of "+" to ensure the inheritance isn't lost at some point in future if someone forgets to change that option.

dv2kJLUPv wrote:Thanks - any particular reason it's not recommended?

Quite frankly the DB structure for the configuration database is complex with the dependencies on different fields, and we do not have documented how one would accomplish what is already written in the codebase to take care of for you.

May I suggest an alternative to importing the configurations if you already have a mechanism written that creates the configurations the way that you like them.

We have a folder in Nagios XI that can be used to place the configurations made from external systems, /usr/local/nagios/etc/static

If you place your generated configuration files in this directory, they will be monitored as any other host/service, they just will not be handled by the Core Configuration Manager