Nagios Support Forum

We are using a script to help load large amount of data into Nagios XI via the database, but the status is not getting changed to "Not Applied". Is there a script / DB field / method which need to be called to change the status? I've found when the host exists and get updated the apply configure sometimes skips the object from getting written to the configuration files.

Nagios Version: 5.2.8

Reason: The API does not currently support the changes we want to do and the lead developer for the script does not want to deal with configuration files manipulations and the DB structure normally would not change when patches are done.

Background: The script runs nightly to add or update our company inventory into NagiosXI, so it can be monitored. The script will create the host and hostgroups if they don't exist and update the host and hostgroup when changes are made. The script also links the hosts with the hostgroups as well, while any new hostgroups created by the script are sent to the monitoring team as a report to review.

Direct manipulation of the various Nagios XI databases is not something we officially support. It is a fast-track to breaking your XI server.

What are your queries doing with the last_modified field for a given service/host insert? How XI generally determines "Applied" VS "Not Applied" is by assessing the last_modified field for a given database object.

Since the default is to use the timestamp, we are letting MySQL handle the insert or change has needed. Can you provide more information on what could be broken if direct manipulation to the database happens, in order to confirm if our NagiosXI system is broken?

He's just saying that direct manipulation of the database can very easily lead to a broken system because:

1. You may not be aware of all the relationships and processes that are handled in the backend code.
2. A misconstructed SQL query can wreak havoc on a DB.

And that we don't support it because it very often leads to weird errors that take a lot of support hours to figure out that it's because they were doing direct DB manipulation.

Thanks for the information. This post can be closed out.

Closing this up!