Xymon Mailing List Archive search

alert config feature request

list Henrik Størner
Mon, 20 Jan 2014 22:10:50 +0100
Message-Id: <user-c5e46caf25c3@xymon.invalid>

Den 20-01-2014 21:57, Galen Johnson skrev:
For some reason, it ignores the entry if I do the following:

hosts.cfg entry:
149.173.106.52 oda01au.example.com <http://oda01au.example.com>;  # conn
ssh pulldata NAME:odaws01-us CLIENT:oda01au CLASS:workspace

CLASS=workspace
         PROC "ObjectSpawner"
         PROC "/pbr/sfw/sas/930/SASFoundation/9.3/sasexe/sas" 0 225
yellow TRACK=sas "TEXT=SAS Sessions"
         PORT "LOCAL=%[\.:]8591$" state=LISTEN "TEXT=Workspace Server"
         PORT "REMOTE=%[\.:]8561$" state=ESTABLISHED MIN=0 TRACK=omr
"TEXT=Active Connections to Metadata Server"
         PORT "LOCAL=%[\.:]8591$" state=ESTABLISHED MIN=0 TRACK=ws
"TEXT=Active Connections to SASMain Workspace Server"

Admittedly, I don't have --class=Classname on the client but was hoping
that having it in the hosts.cfg would be enough.  I'm going to test it
but was curious if that was required...even if it matches.
Hmmm ... I am not sure what happens when you have the CLASS: setting in 
hosts.cfg, but the client also sends a class-name in the client data. 
Which one takes precedence?

Looking at the code it seems that the one from hosts.cfg should overrule 
the client data, but right now I cannot test it.

The only way you can really see what the class setting is, is by 
watching the status-channel data:
    xymoncmd xymond_channel --channel=status \
	egrep "^..status.*<hostname>"
(you need to be the xymon user for that to work). The classname is field 
#16 (just before the page-path where the host is found).


Regards,
Henrik