regular expressions in analysis.cfg
Hi David, Thanks, it does work on ignore statements with regular expressions but not with simple strings:
LOG eventlog_application %^warning COLOR=yellow "IGNORE=No externals have been specified" LOG eventlog_application %^warning COLOR=yellow IGNORE="No externals have been specified"
If I escape the spaces or if I add the %, it works. But still, this is not logical - quotes are normally after the equal sign and of course it shouldn't be necessary to make this into a regex when it isn't.
thanks for the tip.
cheers, Phil
David Baldwin <david.baldwin at ausport.gov.au> 03/04/13 4:43 PM >>> Phil,
You need to put "" around entire IGNORE item - e.g.:
... "IGNORE=%Client \([0-9]7"
This applies for any use of regex in analysis.cfg which uses spaces.
David.
I'm having a problem with spaces in regular expressions when trying to IGNORE log entries. So for the line:
warning - 2013/03/04 12:52:21 - BigBrotherXymonClient (17) - The agent externals generated this event message : No externals have been specified
works: LOG eventlog_application %^warning COLOR=red IGNORE=%Client.*17
works: LOG eventlog_application %^warning COLOR=red IGNORE=%Client.*[0-9]7
works: LOG eventlog_application %^warning COLOR=red IGNORE=Client\ \(17
works: LOG eventlog_application %^warning COLOR=red IGNORE=No\ externals\ have\ been\ specified
doesn't work: LOG eventlog_application %^warning COLOR=red IGNORE=%"Client \([0-9]7"
doesn't work: LOG eventlog_application %^warning COLOR=red IGNORE="Client \(17"
doesn't work: LOG eventlog_application %^warning COLOR=red IGNORE="Client (17"
doesn't work: LOG eventlog_application %^warning COLOR=red IGNORE="No externals have been specified"
Is this correct? If so, why no spaces??? It is very confusing as spaces are used elsewhere, eg I can have spaces in a DISK name in analysis.cfg: DISK "/yada yada" 90 95, and spaces can be used in various places in hosts.cfg.
thanks, Phil
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 david.baldwin at ausport.gov.au Leverrier Street Bruce ACT 2617
Keep up to date with what's happening in Australian sport visit www.ausport.gov.au
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
On 6 March 2013 11:04, Phil Crooker <Phil.Crooker at orix.com.au> wrote:
Thanks, it does work on ignore statements with regular expressions but not with simple strings:
LOG eventlog_application %^warning COLOR=yellow "IGNORE=No externals have been specified" LOG eventlog_application %^warning COLOR=yellow IGNORE="No externals have been specified"
I would have thought both of these would work. Might be a bug.
If I escape the spaces or if I add the %, it works.
Well that's something.
But still, this is not logical - quotes are normally after the equal sign
Well, no. This is not illogical, just not familiar to you, that's all. We're not dealing with a shell script, but a highly-specific configuration file. The quoting is consistent across Xymon configuration files.
But the fact that the quoted string with spaces doesn't match is probably a bug.
and of course it shouldn't be necessary to make this into a regex when it
isn't.
That's true.
Cheers Jeremy
Well, no. This is not illogical, just not familiar to you, that's all. We're not dealing with a shell script, but a highly-specific configuration file.
I agree, it is logical (in its own twisted way ;-). I assume the whole parameter is grabbed as a block and parsed afterwards. I remember some unusual parsing with big brother because of it operating out of the shell environment, perhaps this has grown out of that....
The quoting is consistent across Xymon configuration files.
Well not in this case, eg in analysis.cfg: DISK "/yada bing bong" 90 95 it isn't "DISK /yada bing bong". Same in hosts.cfg: 0.0.0.0 whatever.com.au # NAME:"What Ever" not: "NAME:What Ever".
thanks for your help and your work with xymon. It is a great system.
cheers, Phil
On 6 March 2013 11:04, Phil Crooker <Phil.Crooker at orix.com.au> wrote:
Thanks, it does work on ignore statements with regular expressions but not with simple strings:
LOG eventlog_application %^warning COLOR=yellow "IGNORE=No externals have been specified" LOG eventlog_application %^warning COLOR=yellow IGNORE="No externals have been specified"
I would have thought both of these would work. Might be a bug.
If I escape the spaces or if I add the %, it works.
Well that's something.
But still, this is not logical - quotes are normally after the equal sign
Well, no. This is not illogical, just not familiar to you, that's all. We're not dealing with a shell script, but a highly-specific configuration file. The quoting is consistent across Xymon configuration files.
But the fact that the quoted string with spaces doesn't match is probably a bug.
and of course it shouldn't be necessary to make this into a regex when it isn't.
That's true.
Cheers Jeremy
On 7 March 2013 09:49, Phil Crooker <Phil.Crooker at orix.com.au> wrote:
The quoting is consistent across Xymon configuration files.
Well not in this case, eg in analysis.cfg: DISK "/yada bing bong" 90 95 it isn't "DISK /yada bing bong".
It's not "DISK=/yada bing bong" - there's no equals sign, so it's not the same. But in the same file, parameters that are in A=B format are quoted as "A=some string with spaces".
Same in hosts.cfg: 0.0.0.0 whatever.com.au # NAME:"What Ever" not: "NAME:What Ever".
Again, no equals sign there.
I guess we're getting into some subtleties though. And it would be nice to have the same parser/format for all the different bits of Xymon. But my point is, quoting is (in my experience) the same for all "A=B" format assignments, even if not for "A B" and "A:B" definitions.
J
participants (2)
-
jlaidman＠rebel-it.com.au
-
Phil.Crooker＠orix.com.au