Nagios Support Forum

Hello Yancy,

I just did the test and apparently the passive service does receive checks while in downtime. It does not send notifications htough, but as we have servicedesk people cleaning up the open service problems, after the downtime has ended, the passive service appears in the open service problems, which results in servicedesk incidents for issues created during maintenance or downtime.
Is there any way to prevent passive checks from being sent to the Nagios server, apart from editing the nsclient.ini file and restarting the nsclietn service?

Grtz

You can disable passive checks system wide (Admin -> Monitoring Engine Status) or on a per service basis, from the Advanced tab on the Status detail page.

Hello Scott,

Thanks again for your fast answer! Is it possible to disable the passive check with the external command interface? We are putting hosts in downtime with a Powershell script that generates an url, based on http://blog.nwcoder.com/2012/09/schedul ... shell.html, but with a gui, so users can activate downtime form the desktop of their server.

I'll have to add this to our Powershell script... using the webbased external command interface...

By the way, last update (to 2.2) the user our Powershell script uses was removed from cgi.cfg from "authorized_for_all_hosts". Will this cgi.cfg always be overwritten after an update?
Does Nagios XI officially support the external command interface?

I'm also wondering if it's not better to change the nsclient.ini file at the moment we start the downtime. As we use the realtime eventlog monitoring of the nsclient, for example

[/settings/eventlog/real-time]
; DEBUG - Log missed records (usefull to detect issues with filters) not usefull in production as it is a bit of a resource hog.
debug = false
; REAL TIME CHECKING - Spawns a backgrounnd thread which detects issues and reports them back instantly.
enabled = true
; LOGS TO CHECK - Comma separated list of logs to check
; STARTUP AGE - The initial age to scan when starting NSClient++
startup age = 30m

[/settings/eventlog/real-time/filters]

[/settings/eventlog/real-time/filters/default]
destination=NSCA
syntax=%type% %id% %source%: %message%

[/settings/eventlog/real-time/filters/EVT_System]
log= system
filter= level IN (error) AND id NOT IN (1,4,10,19,37,39,56,137,1006,1009,1041,1066,1111,4192,4224,4250,5719,5722,5723,5774,5783,5805,6161,7000,7009,7011,7022,7024,7026,7031,7032,7034,8003,9022,10005,10006,10009,10010,36887)
severity= WARNING
maximum age= off

We could maybe set enabled = false and restart the nsclient service at the moment the downtime is launched. This seems better then disabling it at the Nagios server side, which will not stop the events being sent? Although setting it back to true would be harder, as the time the host and services are in downtime varies.

It seems still strange to me that passive services are not disabled by default from the moment they get in downtime. Who wants to get alerts from a service when you choose to put the service in downtime...?

Greetz

WillemDH wrote:Thanks again for your fast answer! Is it possible to disable the passive check with the external command interface?

Yes, all commands are documented here
http://old.nagios.org/developerinfo/ext ... ndlist.php

WillemDH wrote:Will this cgi.cfg always be overwritten after an update?

This is odd, I didn't believe that should have been updated at all, I do know that file is automatically changed to include users when you add them via the GUI, but I am pretty sure the upgrade doesn't touch it.

WillemDH wrote:Does Nagios XI officially support the external command interface?

Yes

WillemDH wrote: It seems still strange to me that passive services are not disabled by default from the moment they get in downtime. Who wants to get alerts from a service when you choose to put the service in downtime...?

You wouldn't get an alert, it would just update the status. Nagios performs active checks during downtime too, it just doesn't send alerts.

In fact I'm not sure if I'm really using the external command interface. As we are 99 % WIndows environment, we use web url's to execute commands. But apparently the cmd_typ in http://old.nagios.org/developerinfo/ext ... ndlist.php are not the same as the cmd_typ we find in the url's. It seems hard to find documentation for using url's for executing commands. The only way to find the cmd_typ is by using the command through the Nagios XI gui, and then converting it to http://<nagiosserver>/nagios/cgi-bin/cmd.cgi?host=<host>&service=EVT_System&cmd_typ=30&cmd_mod=2&com_author=httpAuthUsername&plugin_output=Test

In the above example, I was able to submit a passive OK check result from the host server to the service EVT_System. So I think I'm gonna send this through Powershell at the end of the downtime. I can't seem to find the submit passive check result in the
http://old.nagios.org/developerinfo/ext ... ndlist.php

We also set downtime in a similar way, but the cmd_typ is 55 for downtime (host + services). looking up this command in the external command list, http://old.nagios.org/developerinfo/ext ... and_id=122 nowhere shows me the cmd_typ used.

So normally I can find the cmd_typ in the url after I open in new tab for the action in Nagios XI, but for some checks this is not possible, as for example for disabling passive checks completely, as right click open in new tab gives me the same page..
Is there somewhere documentation about the cmd_typ we can use in external command interface url's?

I see... This isn't the actual external commands sent through the command pipe, and I don't have a reference list without digging into Core source to find them.

But...

If you are using XI, you can submit proper commands through the NRPD interface. Go to Admin -> Inbound Transfer and setup a token for NRDP

Then navigate to http://<your_server>/nrdp/

Here you can add the proper command line and token to build a request. You can look at the source to determine what the request would look like, it would be something like
This takes proper commands from
ttp://old.nagios.org/developerinfo/externalcommands/commandlist.php

Hi Scott,

Thanks for the information. I'm surely gonna look into it after my vacation.

Willem

Couldn't resist testing already and indeed this seems to work nice!