check_mssql graph/chart problem

[quartix]

Hi,

I've just noticed that check_mssql won't store any data in the graphs anymore. It was working fine before the 5th Jan and showing trends etc in the graphs since we updated from 2014r2.0 to 2014r2.3 on that date. I've checked the version of the check_mssql script which is 0.7.2, and can be seen from the monitoring plugins page that it was updated on that date: check_mssql 0 0 rwxr-xr-x 05/01/2015 09:35:37 (note these are UK dates so dd/mm/yyyy). Is there a fix or work around for this?

Thanks,
Jodey

[bdgoecke]

Could we see your check ?

Did you setup your checks with the wizard ?

Thanks.

==>brian.

[quartix]

Hi,

The check is here:

/usr/local/nagios/libexec/check_mssql_server.py -H 10.241.20.15 -U 'Nagios' -P 'blankedout' -p 1433 --deadlocks --warning 20 --critical 30

It was created using the wizard, in an older version of nagios, it was then updated to 2014R2 on jan 5th and since then it's now on 2.4 and still not working.

Cheers,
Jodey

[scottwilkerson]

It is possible that the number of datasources changed somewhere along the way..

Run the following procedure
http://support.nagios.com/wiki/index.ph ... 14_Upgrade

[quartix]

Ok I've done that, unfortunately it hasn't helped. I've tried deleting all the old RRD files for those checks and it won't recreate the files either... I've reconfigured the check too to see if that would help but no luck there either. I don't really want to have to delete these services and try to start again with them if I can help it because they all have custom warning and critical values.

[lmiltchev]

Can you show us the output of the following command ran in the CLI?

Code: Select all

/usr/local/nagios/libexec/check_mssql_server.py -H 10.241.20.15 -U 'Nagios' -P 'blankedout' -p 1433 --deadlocks --warning 20 --critical 30

Also, run:

Code: Select all

grep -i version /usr/local/nagios/libexec/check_mssql_server.py

and show us the output.

[quartix]

Ok the output from the first command is:

Code: Select all

[root@nagiosxi ~]# /usr/local/nagios/libexec/check_mssql_server.py -H 10.241.20.15 -U 'Nagios' -P 'blankedout' -p 1433 --deadlocks --warning 20 --critical 30
OK: Deadlocks / Sec is 0.0/sec|deadlocks=0.0;20;30;;;

Also here is the output of another command which isn't giving 0.0 as the answer, again ALL check_mssql_server commands we're using don't graph (i've adjusted the warning and critical values to force it to report as critical in this example):

Code: Select all

[root@nagiosxi ~]# /usr/local/nagios/libexec/check_mssql_server.py -H 10.241.20.15 -U 'Nagios' -P 'blankedout' -p 1433 --lockwait --warning 20 --critical 30
CRITICAL: Lock Wait Average Time (ms) is 8799273.0ms|lockwait=8799273.0ms;20;30;;;

and the other one:

Code: Select all

[root@nagiosxi ~]# grep -i version /usr/local/nagios/libexec/check_mssql_server.py
# Version 2.0.2

[lmiltchev]

This is really strange - I see identical output on my test box and I don't have any issues with perf graphs... Are the RRD and XML files updating in the "/usr/local/nagios/share/perfdata/<hostname>" directory? Have you tried rerunning the wizard and setting up a new host? Do the RRDs and XMLs appear for the "new" hosts and its services?

[Box293]

There is one too many ; at the end of the performance data string.

Now this script wasn't updated, it appears that an update in the component that processes the performance data has picked this up.

Here's the fix:
Edit the file:
check_mssql_server.py
goto line 246:
stdout = '%s%s|%s=%s%s;%s;%s;;;' % (prefix, stdout, label, strresult, unit, options.warning or '', options.critical or '')

Remove the last ; so the line is as follows:

Code: Select all

stdout = '%s%s|%s=%s%s;%s;%s;;' % (prefix, stdout, label, strresult, unit, options.warning or '', options.critical or '')

Save the file and from Nagios XI force an immediate check a couple of times. After about 5 minutes graph data should start to appear.

This has already been reported on GitHub and on tracker.nagios.com.

[tmcdonald]

I believe this has been fixed since I got a bug testing task for it. It might have missed the cutoff for 2014R2.5 though since I don't see it in the changelog.