Xymon Mailing List Archive search

Can anyone confirm unexpected behavior of DISPLAYGROUP in alerts.cfg ?

3 messages in this thread

list John Thurston · Thu, 10 Oct 2013 17:08:31 -0800 ·
I see inconsistency between the documentation for the DISPLAYGROUP rule in alerts.cfg and the behavior of the rule.

In the alerts.cfg.5.html on my server (Updated: Version 4.3.12: 24 Jul 2013) says:
DISPLAYGROUP=groupstring Rule matching an alert by the text of the display-group (text following the group, group-only, group-except heading) in the hosts.cfg file. "groupstring" is the text for the group, stripped of any HTML tags.
. . . . the database servers can be matched with DISPLAYGROUP="Production databases"

The first inconsistency is there is no mention of this rule in the xymon-alerts.html file. That's understandable as the xymon-alerts.html is probably an older file. But since this rule offers me significant business advantage, I went ahead and gave it a shot.

The real problem is that DISPLAYGROUP does not appear to handle spaces and double quotes as advertised. When I try to use the rule in my alert.cfg, my alert.log contains lines telling me of unknown tokens.

 From my hosts.cfg
page ETS        ETS Enterprise
title   Solaris Hosts
subparent ETS   SolHostsAll     All
group           Solaris T3 Servers
0.0.0.0         argon.example.com       # client:argon !ftp
 From my alerts.cfg
DISPLAYGROUP="Solaris  T3 Servers"
        MAIL user-20f341e8120e@xymon.invalid   REPEAT=1m SERVICE=ssh
Results in alert.log
2013-10-10 16:52:12 Ignored unknown/unexpected token 'T3' at line 130
2013-10-10 16:52:12 Ignored unknown/unexpected token 'Servers"' at line 130
If, however, I change the group name to be the single word "Solaris" (withoug quotes) and change the line in alerts.cfg to be:
   DISPLAYGROUP=Solaris
then it works without complaint.

It also works if I leave the original group name and change the line in alerts.cfg to use regex:
   DISPLAYGROUP=%Solaris[[:space:]]T3[[:space:]]Servers

Can anyone confirm this behavior?

It appears I can work around it with the regex, but it is going to make my alerts.cfg a lot more difficult to maintain and read.

fwiw, I am running my xymon server on Solaris 10 SPARC.

-- 
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Jeremy Laidman · Fri, 11 Oct 2013 13:26:47 +1100 ·
quoted from John Thurston
On 11 October 2013 12:08, John Thurston <user-ce4d79d99bab@xymon.invalid> wrote:
If, however, I change the group name to be the single word "Solaris"
(withoug quotes) and change the line in alerts.cfg to be:
  DISPLAYGROUP=Solaris
then it works without complaint.
Some config files require quotes to be around the keyword also.  Can you
see if this works:

  "DISPLAYGROUP=Solaris T3 Servers"

The man page example contradicts this, but the man page might be wrong.

J
list John Thurston · Fri, 11 Oct 2013 08:46:51 -0800 ·
quoted from Jeremy Laidman
On 10/10/2013 6:26 PM, Jeremy Laidman wrote:
On 11 October 2013 12:08, John Thurston <user-ce4d79d99bab@xymon.invalid> wrote:
If, however, I change the group name to be the single word "Solaris"
(withoug quotes) and change the line in alerts.cfg to be:
   DISPLAYGROUP=Solaris
then it works without complaint.
Some config files require quotes to be around the keyword also.  Can you
see if this works:

   "DISPLAYGROUP=Solaris T3 Servers"
This has been tested and determined that it doesn't work. But
  DISPLAYGROUP=%Solaris\sT3\sServers
does work. Which is a little less error-prone than the [[:space:]] syntax.

This appears to be consistent with the documented (and observed) 
behavior of the "cont" test as outlined in hosts.cfg.5.html
cont[=COLUMN];URL;[expected_data_regexp|#digesttype:digest]
    This tag is used to specify a http/https check, where it is also checked that specific content is present in the server response.. .
- snip -
The data that must be returned can be specified either as a regular expression (except that <space> is not allowed) . . .
- snip -
If you must have whitespace in the regex, use the [[:space:]] syntax . . .
I'm going to put this down to a defect in documentation.
quoted from John Thurston

-- 
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska