alert config feature request
list Galen Johnson
Hey, I think this may have gotten lost in a separate thread. Reading the man page for alerts.cfg, there are a few keywords that you can use to configure alerts...in the hosts.cfg man page you can add a tag for CLASS that is only for logs... CLASS:Classname Force the host to belong to a specific class. Class-names are used when configuring log-file monitoring (they can be used as references in *client-local.cfg <http://xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html>;(5)* and *analysis.cfg <http://xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html>;(5)* to group log file checks). Normally, class-names are controlled on the client by starting the Xymon client with the "--class=Classname" option. If you specify it in the hosts.cfg file on the Xymon server, it overrides any class name that the client reports. It would be handy to allow alerts.cfg to trigger on this as well. Not sure what this would entail but would be very useful. thx =G=
list Henrik Størner
▸
Den 20.01.2014 02:17, Galen Johnson skrev:
I think this may have gotten lost in a separate thread. Reading the man page for alerts.cfg, there are a few keywords that you can use to configure alerts...in the hosts.cfg man page you can add a tag for CLASS that is only for logs...
CLASS:ClassnameForce the host to belong to a specific
class. Class-names are used when configuring log-file monitoring (they
can be used as references in _client-local.cfg [1](5)_ and _analysis.cfg[2](5)_ to group log file checks). Normally, class-names are controlled
▸
on the client by starting the Xymon client with the "--class=Classname"
option. If you specify it in the hosts.cfg file on the Xymon server, it
overrides any class name that the client reports. It would be handy to allow alerts.cfg to trigger on this as well. Not sure what this would entail but would be very useful.
You already can. I see it is not documented in the alerts.cfg man-page, but you can use CLASS=... and EXCLASS=... in alerts.cfg just as you would use HOST=... or EXHOST=... Regards, Henrik Links: [1] http://xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html [2] http://xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html
list Galen Johnson
For some reason, it ignores the entry if I do the following:
hosts.cfg entry:
149.173.106.52 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.
▸
On Mon, Jan 20, 2014 at 3:08 AM, <user-ce4a2c883f75@xymon.invalid> wrote:
Den 20.01.2014 02:17, Galen Johnson skrev: I think this may have gotten lost in a separate thread. Reading the man page for alerts.cfg, there are a few keywords that you can use to configure alerts...in the hosts.cfg man page you can add a tag for CLASS that is only for logs... CLASS:ClassnameForce the host to belong to a specific class. Class-names are used when configuring log-file monitoring (they can be used as references in *client-local.cfg
<http://xymon.com/xymon/help/manpages/man5/client-local.cfg.5.html>;(5)*and *analysis.cfg
▸
<http://xymon.com/xymon/help/manpages/man5/analysis.cfg.5.html>;(5)* to group log file checks). Normally, class-names are controlled on the client by starting the Xymon client with the "--class=Classname" option. If you specify it in the hosts.cfg file on the Xymon server, it overrides any class name that the client reports. It would be handy to allow alerts.cfg to trigger on this as well. Not sure what this would entail but would be very useful. You already can. I see it is not documented in the alerts.cfg man-page, but you can use CLASS=... and EXCLASS=... in alerts.cfg just as you would use HOST=... or EXHOST=... Regards, Henrik
list Henrik Størner
▸
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