How does one escape characters in check_http regex's?

[wsanders]

I have never gotten the hang of getting regex's with special characters to work with check_http. For example, I want to alert if the string "Component(s) Down" is present (with the parentheses) in a page. From the command line, when the string is present in the page, it's:

Code: Select all

./check_http -I 1.2.3.4 -r 'Component\(s\) Down'  --invert-regex  -> yields:
HTTP CRITICAL - pattern found|time=0.193665s;;;0.000000 size=455974B;;;0

I could not figure out the magic syntax to escape the ()'s in the service description:

Code: Select all

check_http!-r!Component(s) Down!--invert-regex  -> yields (null)
check_http!-r!Component\(s\) Down!--invert-regex  -> yields (null)
check_http!-r!'Component(s) Down'!--invert-regex  -> yields "HTTP OK"
check_http!-r!'Component\(s\) Down'!--invert-regex  -> yields "HTTP OK"
check_http!-r!"Component(s) Down"!--invert-regex  -> yields "HTTP OK"
check_http!-r!"Component\(s\) Down"!--invert-regex  -> yields "HTTP OK"

So I finally gave up and used

Code: Select all

check_http!-u!/server/status!-p!7009!-r!Component.s. Down!--invert-regex -> yields:
HTTP CRITICAL - pattern found|time=0.218032s;;;0.000000 size=455935B;;;0

the correct result.

Anybody else figured how to pass check_http parentheses (and brackets, etc) in a regexp? This is tedious! Thanks in advance ...

[slansing]

It can be quite confusing.. looks like you almost had it here, and just needed to escape the other ()'s:

Code: Select all

check_http!-r!Component\(s\) Down!--invert-regex  -> yields (null)

[wsanders]

Well, this get even weirder:

Code: Select all

check_http!-r!Application Down!--invert-regex

returns "HTTP CRITICAL - pattern found" even though the string is nowhere to be found.

Code: Select all

check_http!-r!Application.Down!--invert-regex

fixes it. (Or at least avoids a false positive.) Yet

Code: Select all

check_http!-r!Component.s. Down!--invert-regex

seems to work OK. (my service is now recovered and neither regex is present in the HTML.)

I'm going to have to test this, this is "check_http v1861 (nagios-plugins 1.4.11)", an old one, but it's impossible to test from the command line, which always works as expected. It is some kind of interaction with how the plugin is passed its command line arguments from nagios.

[sreinhardt]

While you are testing, as a slight side note, this seems to be in the fusion forum. Can we move this to the appropriate core or XI forum, and which do you happen to be using? thanks!

[wsanders]

I don't seem to be able to move a trhread to another forum - maybe the admins can do that?

Well, I've tried putting all kinds of escapes in the command line, and the core issue that as I have it configured Nagios seems to strip out any backslashes. My command is configured in commands.cfg as:

Code: Select all

command_line  $USER1$/exp-check-apppage3 -H $HOSTADDRESS$ $ARG1$  $ARG2$  $ARG3$  $ARG4$  $ARG5$  $ARG6$  $ARG7$  $ARG8$

I wrote a test plugin to just print exactly what was being received in $ARGXX$. No matter what I put in the service description, I always get the same result. I tried:

Code: Select all

'\(version=3.51.0'
"\(version=3.51.0"
'\\(version=3.51.0'	
"\\(version=3.51.0"		
\\(version=3.51.0
\'\(version=3.51.0\'	
\"\(version=3.51.0\"
\'(version=3.51.0\'	
\"(version=3.51.0\"

In all cases the string received by the plugin was

Code: Select all

(version=3.51.0

This expression yields (null), probbaly because the plugin can't run at all in a shell with an unescaped, unmatched open paren:

Code: Select all

\(version=3.51.0		(null)

which of course in bash will give you a "syntax error near unexpected token `('" error.

The workaround still seems to be to use a dot for the unescapable characters. Perhaps this can be fixed by putting the quotes in the command_line of the command definition, but I don't like to hardwire my commands for specific parameters in specific positions. Moving on!

[sreinhardt]

Interesting testing, by chance have you tried the same aspects with the $USER##$ variables opposed to $ARG##$ variables? These are defined system wide and not an ideal solution for more than a few items, but it might be worth a shot other than .'s.