I am in the process of standing up a XI server to replace a Core server, and think I found a bug.
Our config files are identical between XI and Core, however I am getting a different check command sent to Nsclient.
We have a check to see if the SQL server is available.
The instance is left blank if the SQL server instance is set with the default instance, otherwise it is set in the config file.
Service.cfg
define service {
use mssql_database
service_description SQLServer_Database Availability
servicegroups MSSQL Production Servers,MSSQL Services
host_name SQLserver1
_alias SQLserver1
_instance
notifications_enabled 1
register 1
}
The service has a number of settings, but here is the check command
define command {
command_name check_mssql_database
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$ $_SERVICEINSTANCE$
}
And the external script in nsc.ini
check_mssql_connection=cscript.exe //T:30 //NoLogo scripts\check_mssql.vbs $ARG1$ $ARG2$ $ARG3$ $ARG4$
When Core sends the check, nsclient calls the script with username password SQLserver1
and the script completes.
When XI sends the check, nsclient calls the script with username password SQLserver1 _instance
the script fails as it tries to connect to server\_instance
One fix would be to change the script, however I would like to know why this is happening as it may be causing other issues.
Core to XI: Change in check command arguments
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: Core to XI: Change in check command arguments
In XI, go to CCM
Go to the list of services and find the one that uses this check command
For that service click the floppy disk icon
This opens the text definition, please paste that service here in a code block
Go to the list of services and find the one that uses this check command
For that service click the floppy disk icon
This opens the text definition, please paste that service here in a code block
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Core to XI: Change in check command arguments
These are all static configs so they don't show up in services in CCM.
I did try and go through tools > static configurations and after choosing the config file, I got File is not readable.
I did try and go through tools > static configurations and after choosing the config file, I got File is not readable.
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: Core to XI: Change in check command arguments
Can I ask why you are choosing static configs in Nagios XI?
Can you post the static config files here. I know you already posted some configs but I would like to see the files themselves if possible. If you are using static files there might be an overlap with the built in XI commands.
Can you post the static config files here. I know you already posted some configs but I would like to see the files themselves if possible. If you are using static files there might be an overlap with the built in XI commands.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Core to XI: Change in check command arguments
We have a home built tool that builds our config files for a number of different nagios servers. Twice a day it auto builds out the config files and a cron job on the nagios servers gets the configs, loads them in, does a check and then a restart. Eventually we may rebuild our tool for directly configuring XI, but that will need to wait until I can fully get off our Core servers.
I can't post the config files, but here is excerpt from them.
BuisnessUnitServices.cfg
define service {
use mssql_database
service_description SQLServer_Database Availability
servicegroups MSSQL Production Servers,MSSQL Services
host_name SQLserver1
_alias SQLserver1
_instance
notifications_enabled 1
register 1
}
StaticDefinitions.cfg
define service {
name mssql_database
register 0
check_command check_mssql_database
check_interval 5
max_check_attempts 5
check_period 24x7
retry_interval 1
notification_interval 1440
notification_period 24x7
notification_options c,r
flap_detection_enabled 0
contact_groups SQLTeam
_parameter "MSSQL Database Connection"
_priority 3
}
define command {
command_name check_mssql_database
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$ $_SERVICEINSTANCE$
}
I did a grep for "check_mssql_database" and the only other hit I got was
/usr/local/nagios/etc/commands.cfg: command_line $USER1$/check_mssql_database.py -H $HOSTADDRESS$ $ARG1$
define command {
command_name check_xi_mssql_database
command_line $USER1$/check_mssql_database.py -H $HOSTADDRESS$ $ARG1$
}
That should not matter since we are not calling "check_xi_mssql_database" at all.
I can't post the config files, but here is excerpt from them.
BuisnessUnitServices.cfg
define service {
use mssql_database
service_description SQLServer_Database Availability
servicegroups MSSQL Production Servers,MSSQL Services
host_name SQLserver1
_alias SQLserver1
_instance
notifications_enabled 1
register 1
}
StaticDefinitions.cfg
define service {
name mssql_database
register 0
check_command check_mssql_database
check_interval 5
max_check_attempts 5
check_period 24x7
retry_interval 1
notification_interval 1440
notification_period 24x7
notification_options c,r
flap_detection_enabled 0
contact_groups SQLTeam
_parameter "MSSQL Database Connection"
_priority 3
}
define command {
command_name check_mssql_database
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$ $_SERVICEINSTANCE$
}
I did a grep for "check_mssql_database" and the only other hit I got was
/usr/local/nagios/etc/commands.cfg: command_line $USER1$/check_mssql_database.py -H $HOSTADDRESS$ $ARG1$
define command {
command_name check_xi_mssql_database
command_line $USER1$/check_mssql_database.py -H $HOSTADDRESS$ $ARG1$
}
That should not matter since we are not calling "check_xi_mssql_database" at all.
Re: Core to XI: Change in check command arguments
Does the "_instance" macro contain any special characters?
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Core to XI: Change in check command arguments
I'm not sure what you mean by macro?
If the instance name is specified, it would be"
_alias SQLserver1
_instance App1Instance
That works fine for any server that is configured with an instance. It is just when there is no instance specified, XI sends "_instance" instead of an empty string
If the instance name is specified, it would be"
_alias SQLserver1
_instance App1Instance
That works fine for any server that is configured with an instance. It is just when there is no instance specified, XI sends "_instance" instead of an empty string
Re: Core to XI: Change in check command arguments
What version of core are you running?
I am fairly sure that empty directives are illegal.
I am fairly sure that empty directives are illegal.
Former Nagios employee
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
"It is turtles. All. The. Way. Down. . . .and maybe an elephant or two."
VI VI VI - The editor of the Beast!
Come to the Dark Side.
Re: Core to XI: Change in check command arguments
our core servers are on 3.4.4
Re: Core to XI: Change in check command arguments
Nagios XI does not allow free variables (ie. _instance) to have empty values assigned.
A possible work around could be to have 2 service checks for the check_mssql_connection, one that has
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$ $_SERVICEINSTANCE$
and one that has
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$
A possible work around could be to have 2 service checks for the check_mssql_connection, one that has
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$ $_SERVICEINSTANCE$
and one that has
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -t 30 -c check_mssql_connection -a username password $_SERVICEALIAS$