API or backend call to disable, not delete, a host

[WillH]

Use case:
Some of our business customers are, shall we say... sloppy with their server retirements.\
They ask for the a server to be retired, de-racked etc, but shortly after the hosts are powered down they realize all the things that host was needed for, and a day,week, month later it's back on line.

While I can easily put a server back into monitoring after it was deleted via API, restoring all of the service checks and group memberships is a bit harder.

DOes anyone know of an API method, or a call to the backend so that I can have build an automation that disables a host for quick re-activation rather than a delete?

It can be done in the GUI, but with a 15k server environment, we try to automate or script where we can.

[gsmith]

Hi

Post to config/host or config/service with check_period=none for each of the hosts and services. The host and service
definitions would continue to live on and could be reactivated whenever needed by changing the check_period.

Image001.jpg

Thanks

[WillH]

Thanks
This wouldn't disable inheritied service checks, would it?

[gsmith]

Hi

You probably just want to set the check_period to "none" for a host.

Any service definition for that host will remain, so I am pretty sure that if host B is
inheriting a service check from host A (check_period set to "none") that host B will
still show the service inherited from host A as being active/valid/in play.

The best way to find out is to test the scenario. I can do that for you if you like, I am
guessing that you can get to it quicker than I can.

If you want me to run that scenario just let me know.

Thanks!

[WillH]

Thanks Greg. This works for the host, but not for it's service checks, at least not how we apply them.
We have services assoc to host groups, then host groups to hosts.

We have all host groups, and all service cfgs on every nagios XI, weather they are needed or not.

If we need to move a host for load/perfromance purposes, or when our server teams vmotion a server from one regional datacenter to another, we just drop the host.cfg into the import folder of its new XI overlord.

This allows it to quickly wake up with evertying it needs.

The down side of this design is moments like this.

[gsmith]

Hi

So your setup is multiple XI servers, and all have the same configuration, with the dependencies as:

hosts inherit settings from hostgroups, with each host group having a set of services defined

and you want to change the monitoring by "enabling/disabling" the appropriate cfg files on all the the XI servers.

Is that accurate ?

Thanks

[WillH]

Greg, (sorry for delay)
Yes, I think so.
We have the same host groups, templates, time periods, services and admin users on all XIs.
The host.cfg (and corresponding CCM records) are different from XI to XI.
If we need to migrate a host and ensure its special service checks (application focused as opposed to the baseline checks every server of a given platform get in our environment) are replicated we simply import the <hostname>.cfg to the ../etc/import folder of the target XI.
Apply Changes.
Then run an API call to delete from the old host.

[gsmith]

Hi

You are correct, with the way you are currently set up the solution
I offered won't work. You'd have to change your configuration to allow
for changing the check_period to toggle on and off the host and services.

Thanks

[WillH]

Thanks for the confirmation