NRPE NSClient check_service syntax issue

[mhixson2]

I am fighting with the check_service command syntax and hope you can help me get over this hurdle. Long story short, I was previously using the command syntax below, but found that the crit value would not return a stopped service with an Automatic (delayed) startup as a Critical alarm, but rather as a Warning. This is no good.

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H NCHISIAPM002 -u -t 30 -c check_service -a "filter=name like 'DBTuna'" 'crit=not state_is_ok()'

Through trial and error, I found changing the crit value to "crit=state= 'stopped'" would throw a Critical alarm for any stopped service I defined and as a bonus added perfdata to the check. Awesome. Except... I can't get it working with this specific check. I think the filter is fighting with the new crit value, but I can't get the logs to tell me why. Maybe I'm not looking at the right logs. I've been mainly focusing on the NSClient logs.

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H NCHISIAPM002 -u -t 30 -c check_service -a "filter=name like 'DBTuna'" "crit=state= 'stopped'"

Reply from Nagios

Code: Select all

CHECK_NRPE: Invalid packet type received from server.

Here's an example of a check that is working properly with similar syntax

Code: Select all

/usr/local/nagios/libexec/check_nrpe -H VCHAPP004 -u -t 30 -c check_service -a "filter=start_type = 'auto' and (name like 'Availability' or name like 'RDT' or name in ('SendLeads', 'VaultWareReports'))" "crit=state= 'stopped'"

Any ideas?
Thanks!

[SteveBeauchemin]

When I run the exact command on a system at my site - other than the name of the host, I get this

Code: Select all

./check_nrpe -H HOST -u -t 30 -c check_service -a "filter=name like 'DBTuna'" "crit=state= 'stopped'"
OK: No services found|

The only time I see a reply like you show is when there is too much data to display - like this with no filter.

Code: Select all

./check_nrpe -H HOST -u -t 30 -c check_service -a "crit=state= 'stopped'"
CHECK_NRPE: Invalid packet type received from server.

That is basically telling me that it is sending back more than the buffer can handle. Using a filter to reduce the number of matches will reduce the amount of data returned.

Another example - using filter of 'a' then 'ab' too many items match 'a' only one matches 'ab'

Code: Select all

!> ./check_nrpe -H HOST -u -t 30 -c check_service -a "filter=name like 'a'" "crit=state= 'stopped'"
CHECK_NRPE: Invalid packet type received from server.

!> ./check_nrpe -H HOST -u -t 30 -c check_service -a "filter=name like 'ab'" "crit=state= 'stopped'"
CRITICAL: TabletInputService=stopped (demand), delayed ()|'TabletInputService'=1;0;1

In any case, that's what I believe is happening. I am in process of migrating from NSClient .3.9 to .4.4 and have recently fought through a lot of those.
just my 2 cents... I hope someone has a better answer.

Good Luck!

Steve B

[lmiltchev]

Thanks SteveBeauchemin! Too large of an output could be the issue indeed. @mhixson2 Try stopping the NSClient++ service, then start it in a test mode. Run your check, and examine the output.

Also, what is the NSClient++ version that you are currently using? Are you running NRPE in the old, "insecure" (legacy) mode?

[mhixson2]

Thanks guys! I think you nailed it with the output being too large as the filter is grabbing about 40 services. I've run into this before, but forgot about it. What a pain. It assume it was working previously because the check wasn't returning perfdata, and now it is, throwing it over the buffer limit. I'll play with spreading the services across two checks and see how that goes.

NSClient version: NSCP-0.4.3.143-x64.

I'll get on running the check with NSClient in test mode on Monday. How would I know if NRPE was running in the old mode?

[lmiltchev]

How would I know if NRPE was running in the old mode?

You will have the following line in the nsclient.ini file:

Code: Select all

insecure=1

or

Code: Select all

insecure=true

I am glad we were able to figure this out. Let us know if it is safe to lock this thread. Thank you!

[mhixson2]

We're good to lock this up. Thanks for your help guys.