Nagios XI with Chef

[tiborracz]

Hello,

We used Chef and the classic Nagios cookbook to manage Nagios core.

Now we have XI and we want to use it with the Nagios cookbook just because it's already there and works fine.

So we generate the core config in the XI's import folder and call reconfigure_nagios.sh. I can confirm the core config is valid, has no errors or warnings in Nagios core.

This worked pretty well but for some reason the Services kept growing and now we have like 4800 services. We discovered the import duplicates some services. They are obviously not duplicated in the service.cfg. Apparently the import generates services with the same name and same config but different IDs so there are more and more services by each Chef run.



Is this a bug or X? Or XI handles services differently?

[mcapra]

Take a look through this documentation and let us know if it doesn't cover your specific questions:
https://assets.nagios.com/downloads/nag ... ios-XI.pdf

Essentially, there's a special way to handle "manual" config file management in Nagios XI and it's not the import folder. That folder gets cleared out after every import (I think), which if Chef is re-generating those config files every time chef-client runs would explain the dupes.

Depending on the specific use-case, you might need to alter how the reconfigure script works to cover your bases. If you want to do manual config file management via the cookbook but also want to occasionally manage objects via the Core Config Manager, a more robust solution is probably required than what I proposed above.

[tiborracz]

Thank you mcapra. I'll take a look at the doc.

Meanwhile we opened a support ticket (773087) too with even more information that we discovered, I add them here as well:

So essentially if the service uses comma separated list for host_names it gets duplicated in CCM during import.

define service {
...
host_name host1,host2
}

Not just duplicated but the import creates a new service in CCM at each chef run. As otherwise this is a valid nagios config, so it shouldn't cause issue.

[tmcdonald]

If there is a ticket open for this we would prefer to close this thread and work just in the ticket so we aren't duplicating our efforts.

[tiborracz]

Hi tmcdonald,

You are right but I will add the solution here for others with the same problem.

I tried mcapra's suggestion and it works however in that case we lose XI functionality - XI won't know about the config in the static folder so it can't control hosts/services/notifications there.

Please verify what other functionalities we lose by using the static folder. We are assessing what XI gives us if we use it like the Core.

[mcapra]

XI won't know about the config in the static folder so it can't control hosts/services/notifications there.

That sounds like a chicken-egg problem to me unless I'm misunderstanding the situation. The CCM wasn't designed around interacting with third parties; That's what the REST API was built for.

The biggest obstacle is in the fact that the cookbook is organizing config files in a fundamentally different way from Nagios XI. Unless automation were in-place to run a proper import and all the prep that comes with it every time a Chef config change occurred, it's going to be a bit messy trying to marry the two together and there's still no guarantee of atomicity in the transactions if the CCM isn't used in a very delicate fashion.

If you want to do Chef and CCM things, I'm reasonably confident it would be less work to add functionality to the cookbook that leverages the Nagios XI REST API for config management than to try and wrangle all the above.

And +1 again for official Chef/Ansible/Salt/Puppet/etc stuff

[tiborracz]

Thank you again.

So I can confirm if I follow the "proper import and all the prep that comes with it" those specific services still get duplicated, and exactly that is the issue here

There's something wrong with the import process for those services - the import checks whether that CCM object exists in nagiosql but apparently services with multiple hosts at host_name are somehow different. So the logic in import_class.php from line 428 has a bug somewhere.

I agree that it'd be nice to use REST API but there is no cookbook for that, only the Nagios cookbook with this file generating stuff so we must use that.

[scottwilkerson]

To help our dev staff look into the bug can you confirm you are on 5.4.13 of Nagios XI?

[tiborracz]

Hi Scott,

Yes it's Nagios XI 5.4.13

[scottwilkerson]

Lastly, would you happen to have a sample config that you imported that causes duplicate definitions?