Check_mssql_health: failed for Named Instance

(Roland) #1

check_mssql_health without definitions in freetds.conf works like a charm for default database. Trying the same with a named instance means using a different port than 1433 is not working and I’m not sure if this is a bug of check_mssql_health or a subsequent error due to a bug of freetds. Based on Ubuntu 16.04 LTS the provided freetds package version is 0.91-6.1build1 and I can’t identify whether this bug fix is included in this version.

This freetds bug causes check_mssql_health to fail with --hostname (see also #10 and #22). Therefore, I’m always using --server instead and this works for default instance resp. default port, but not for a named instance with a different port (means check_mssql_health still trys to connect to 1433).

@lausser: Does this belong to check_mssql_health and can be fixed? Or do I have to update freetds?

(Roland) #2

Just created a new installation with Ubuntu 18.04 and freetds 1.00.82-2, --server still ignores --port and tries to connect to 1433.

(Claudio Kuenzler) #3

Not sure if we have a comparable MSSQL installation but I’m also monitoring several named instances on the same host with check_mssql_health - and it works.

Using Ubuntu 16.04 (Xenial), check_mssql_health, freetds 0.91-5.


/usr/lib/nagios/plugins/check_mssql_health --server="SERVER\sqlprod001" --port=7021 --username="DOMAIN\sa_sql_monitoring" --password=xxx --mode=connected-users --commit
OK - 1 connected users | 'connected_users'=1;50;80;;`

So it should work…

(Roland) #4

Unfortunately, it does not. I’d assume that your server have port 1434/udp open which means SQL Browser Service is running. Therefore, removing --port from your example should work as well. Our software development decided to disable this service (for security reason I’d assume - couldn’t get an answer yet), but check_mssql_health is trying to connect 1434/udp first (seen with tcpdump).

I’m able to connect with tsql:

user@host:~$ tsql -H <> -p <49711> -U <user> -P <pw>
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> select @@version;
2> go

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)
        Oct 28 2016 18:17:30
        Copyright (c) Microsoft Corporation
        Standard Edition (64-bit) on Windows Server 2016 Standard 6.3 <X64> (Build 14393: ) (Hypervisor)

(1 row affected)

(Claudio Kuenzler) #5

Yes, you’re right, there’s a successful connection to UDP/1434 when I run the plugin.
The udp response’s data contains servername, instance name, cluster info and version:


That would explain the different behavior between our environments.