Nagios - how to use logical operators in args passed to NRPE server - arguments

Question

I need to use logical operators on the passed argument to NRPE as Strings. the operator is also used by NRPE as the FIELD separator. Which is the splat or ! token.
different ways of quoting the passed arg. no affect.
Nagios Command.cfg
define command{
command_name check_remote_container_broker_health
command_line $USER1$/check_jmx4perl $ARG1$ $ARG2$ $ARG3$
}
Nagios Remote Service
define service{
use generic-service
host_name alphprdfuse1i
service_description Container IPRCMT1 Broker Health
check_command check_nrpe!check_remote_container_broker_health!-a '--user iprcmtx --password G00gl3M3 --url http://localhost:9091/jolokia --mbean org.apache.activemq:type=Broker,brokerName=amq,service=Health --attribute CurrentStatus --string --critical '!Good''
}
NRPE server
NRPE.cfg
command[check_remote_container_non_heap_used]=/usr/local/nagios/libexec/check_jmx4perl $ARG1$ $ARG2$
When NRPE evaluates the statement, it should perform as
if return.string NOT EQUAL Good
but, NRPE is seeing this as a Field Delimiter
thank you

Answer 1

Based on this thread my guess would be that exclamation marks cannot be escaped in a check_command, you need to avoid them completely.
One way to do this is to move the exclamation mark somewhere else, like the command definition in the NRPE config.
Another could be to use resources.cfg and define a $USERX macro with a number that Nagios will resolve, which is probably the best thing to do in cases of passwords and such, but maybe not in this situation.

Answer 2

changing the NRPE Server command to:
command[check_remote_container_broker_health]=/usr/local/nagios/libexec/check_jmx4perl $ARG1$ '!$ARG2$'
on Nagios Server
define service{
use generic-service
host_name alphprdfuse1i
service_description Container Delta FADEC Broker Health
check_command check_nrpe!check_remote_container_broker_health!-a "--user deltafadec --password B#dM0nk3y --url http://localhost:9093/jolokia --mbean org.apache.activemq:type=Broker,brokerName=amq,service=Health --attribute CurrentStatus --string --critical" "Good"
}
so to remove the ! from the args being passed to NRPE, and let NRPE command issue the logical NOT or !

Answer 3

thank you !!!
I did try using resources.cfg and adding a $USERn$ definition. this did not work for me.
I did try forming the expression on the NRPE server, to accept special characters. This works. And this is all because we avoid the network security risks by allowing dirty characters and bash shell operators. So, this is the BEST solution. it just takes some time understanding what's going on. If you set the logging high, you can see how the macros break it all down. any hoot, here is my solution for a couple implementations.
I will share 2 examples and situations.
on NRPE server, NRPE.cfg
command[check_remote_container_broker_health]=/usr/local/nagios/libexec/check_jmx4perl $ARG1$ '!$ARG2$'
on Nagios server
define service{
use generic-service
host_name alphprdfuse1i
service_description Container PassThru Context State
check_command check_nrpe!check_remote_container_context_state!-a '--user passthru --password B#dC0mpany --url http://localhost:9090/jolokia --mbean org.apache.karaf:type=admin,name="PassThru MultiTenant" --attribute Instances --path "PassThru MultiTenant"/State --critical' 'Started'
}
on NRPE server, NRPE.cfg
command[check_remote_container_context]=/usr/local/nagios/libexec/check_jmx4perl $ARG1$ $ARG2$ $ARG3$ $ARG4$ '$ARG5$"$ARG6$"' $ARG7$
on Nagios server
define service{
use generic-service
host_name alphprdfuse1i
service_description Container PassThru Context ExchangesCompleted
check_command check_nrpe!check_remote_container_context!-a "--user passthru" "--password B#dC0mpany" "--url http://localhost:9090/jolokia" "--mbean" "org.apache.camel:context=passthrumt1.core-com.ge.digital.passthru.coreCamelContext,type=context,name=" "com.ge.digital.passthru.coreCamelContext" "--attribute ExchangesCompleted"
}
Summary
so, if you do not enable the use of special characters on the NRPE, and the sending of such characters from Nagios server to NRPE system, which is declared as a security risk and if you can to avoid using. so, it just becomes a string manipolation to determine what works. basically, if you have any special characters in the Nagios request to NRPE, you need to break this statement in to several strings without the special characters, and apply the special characters on the NRPE side. NRPE will strip out all these characters on evaluation of message.