Monitoring Windows performance counters with check_nrpe

[neworderfac33]

Good afternoon,

Following on from my request for suggestions for plugins to monitor disk performance, I stumbled upon the following article:

Code: Select all

http://sites.box293.com/nagios/guides/common-checks/disk-performance

Using NSClient++ 0.4.3.143 with nrpe support enabled on my Windows hosts, I was able to define services including the following syntax:

Code: Select all

check_command        check_nrpe!checkcounter! -a 'Counter:C % Read Time=\LogicalDisk(C:)\% Disk Read Time' ShowAll MaxWarn=50 MaxCrit=75
check_command        check_nrpe!checkcounter! -a 'Counter:C % Write Time=\LogicalDisk(C:)\% Disk Write Time' ShowAll MaxWarn=50 MaxCrit=75
check_command        check_nrpe!checkcounter! -a 'Counter:C: Queue Length=\LogicalDisk(C:)\Current Disk Queue Length' ShowAll MaxWarn=10 MaxCrit=20
check_command        check_nrpe!checkcounter! -a 'Counter:C: % Read Bytes/sec=\LogicalDisk(C:)\Disk Read Bytes/sec' ShowAll MaxWarn=100 MaxCrit=500
check_command        check_nrpe!checkcounter! -a 'Counter:C: % Write Bytes/sec=\LogicalDisk(C:)\Disk Write Bytes/sec' ShowAll MaxWarn=100 MaxCrit=500
check_command        check_nrpe!checkcounter! -a 'Counter:C: Split IO/sec=\LogicalDisk(C:)\Split IO/Sec' ShowAll MaxWarn=10 MaxCrit=20

Whilst I can get all of these to successfully run without generating errors in Nagios Core 4.3.4, I have to confess that I don't I don't fully understand the syntax. For instance, on the Read Bytes/Sec and Write Bytes/Sec commands, the warning alerts are generated at a lower value than the critical alerts. Surely higher bytes per second are "better" than lower ones, yet the parameters seem to be the wrong way round.

Of course, I HAVE been looking at this all afternoon and I MAY just be missing something completely obvious, but any assistance or observations would be more than welcome, also with any suggestions as to other useful counters that I could use.

Thanks in advance for your interest
Pete

[mcapra]

This documentation should shed some light on the syntax:
https://docs.nsclient.org/reference/win ... eckcounter

Slightly more comprehensive documentation:
https://support.nagios.com/kb/article.php?id=126
https://support.nagios.com/kb/article.php?id=127

If you were to divide one of those command's arguments into discrete chunks:

Code: Select all

'Counter:C % Write Time=\LogicalDisk(C:)\% Disk Write Time' ShowAll MaxWarn=50 MaxCrit=75
|       |              |                                  |                             |
|       |    Label     |           Counter Path           |     Misc NSClient++ Args    |

For instance, on the Read Bytes/Sec and Write Bytes/Sec commands, the warning alerts are generated at a lower value than the critical alerts. Surely higher bytes per second are "better" than lower ones, yet the parameters seem to be the wrong way round.

Higher bytes-per-second isn't necessarily better than lower. For example, a disk that is used only as a fail-over. I might expect my disk to have relatively low bytes-per-second unless there is a failure in my system.

Certainly you would want high-usage disks to have high bytes-per-second, though. In which case, a drop in that value would be of concern.

By the sounds of your environment, you want to alert if the bytes-per-second drops below certain thresholds? In this case, you should use the MinWarn and MinCrit parameters I believe. In which case your state logic should look like:

OK > MinWarn > MinCrit

[neworderfac33]

This is a stunningly good answer - thank you VERY much for the time you took to put it together, and the speed in which you did it - right before hometime too (it's 17:38 ), so I don't have to spend all evening worrying about it!
As soon as I started reading your answer, I realised my error - the idea behind monitoring bytes per second is to identify times of high activity where the disk is being thrashed, so, lower values definitely ARE "better" than lower ones.
I shall read through all the articles carefully and see what else I can come up with.
Thanks once again.

[npolovenko]

Great. Thanks for your help, @mcapra!
@neworderfac33, Let us know if we can close this thread.