Xymon Mailing List Archive search

Xymongrep suggestion: pick up additional test parameters

4 messages in this thread

list Glauber Ribeiro · Tue, 24 Nov 2015 21:23:42 +0000 ·
There are xymon tests which include additional parameters. For example: the network tests can include a port number, and apache has a url.  Currently, xymongrep doesn't support these, because it only works with exact matches. It would be nice for it to be able to recognize colon (tag:parameter or tag:parameter1,parameter2) and equals (tag=parameter or tag=parameter1,parameter2) and supply these as additional words in the output.

Just an idea, in case it's considered useful for a future version.

glauber
list Japheth Cleaver · Tue, 24 Nov 2015 15:52:33 -0800 ·
quoted from Glauber Ribeiro

On Tue, November 24, 2015 1:23 pm, Ribeiro, Glauber wrote:
There are xymon tests which include additional parameters. For example:
the network tests can include a port number, and apache has a url.
Currently, xymongrep doesn't support these, because it only works with
exact matches. It would be nice for it to be able to recognize colon
(tag:parameter or tag:parameter1,parameter2) and equals (tag=parameter or
tag=parameter1,parameter2) and supply these as additional words in the
output.

Just an idea, in case it's considered useful for a future version.
Hi Glauber,

It needs to be documented better, but xymongrep does actually support
wildcards for matching (I believe of the posix variety). Thus ports, ':',
and '=' test variations should be retrievable. I.e.,:

[root at localhost ~]# xymoncmd xymongrep dns* | grep '='
216.239.32.10 ns1.google.com # dns=a:google.com

(From a script, you might need to escape the wildcard)

URL styles of tags can be retrieved that way too, but I agree that having
them easily reachable by test type /alone/ would be a nice feature.


HTH,
-jc
list Shawn Heisey · Tue, 24 Nov 2015 17:02:33 -0700 ·
quoted from Japheth Cleaver
On 11/24/2015 4:52 PM, J.C. Cleaver wrote:
It needs to be documented better, but xymongrep does actually support
wildcards for matching (I believe of the posix variety). Thus ports, ':',
and '=' test variations should be retrievable. I.e.,:

[root at localhost ~]# xymoncmd xymongrep dns* | grep '='
216.239.32.10 ns1.google.com # dns=a:google.com
You can have xymongrep itself handle a delimiter character and avoid the
additional grep.

[root at mcp ~]# xymoncmd xymongrep xxx:*
10.2.1.39 mcp.REDACTED.com # xxx:yyy

[root at mcp ~]# xymoncmd xymongrep mgmt=*
10.100.2.29 fiesta # mgmt=10.2.6.29[http,https,ssh] testip

Thanks,
Shawn
list Glauber Ribeiro · Wed, 25 Nov 2015 14:01:27 +0000 ·
Cool. I tried some variations of wildcards but couldn't get one to work, but the way you have does work

xymongrep "tls*"

will pick up tls alone and tls=url

Thanks,

g
quoted from Japheth Cleaver

-----Original Message-----
From: J.C. Cleaver [mailto:user-87556346d4af@xymon.invalid] 
Sent: Tuesday, November 24, 2015 17:53
To: Ribeiro, Glauber
Cc: Xymon Mailing List
Subject: Re: [Xymon] Xymongrep suggestion: pick up additional test parameters


On Tue, November 24, 2015 1:23 pm, Ribeiro, Glauber wrote:
There are xymon tests which include additional parameters. For example:
the network tests can include a port number, and apache has a url.
Currently, xymongrep doesn't support these, because it only works with
exact matches. It would be nice for it to be able to recognize colon
(tag:parameter or tag:parameter1,parameter2) and equals (tag=parameter or
tag=parameter1,parameter2) and supply these as additional words in the
output.

Just an idea, in case it's considered useful for a future version.
Hi Glauber,

It needs to be documented better, but xymongrep does actually support
wildcards for matching (I believe of the posix variety). Thus ports, ':',
and '=' test variations should be retrievable. I.e.,:

[root at localhost ~]# xymoncmd xymongrep dns* | grep '='
216.239.32.10 ns1.google.com # dns=a:google.com

(From a script, you might need to escape the wildcard)

URL styles of tags can be retrieved that way too, but I agree that having
them easily reachable by test type /alone/ would be a nice feature.


HTH,
-jc