[Xymon] CLASS not working as expected

[Tom Schmidt (tschmidt)]

I have also seen that the CLASS keyword in hosts.cfg does not seem to 
work.  I wanted to use it with BBWin clients so that I could distinguish 
32-bit and 64-bit versions of Windows for analysis by using a 
CLASS:bbwin_64bit designation.  I worked around this by having the BBWin 
client set the CLASS instead to bbwin_32bit or bbwin_64bit.

Tom

On 02/10/2016 09:21 AM, Galen Johnson wrote:
> I've run into this same issue and am curious about the answer.  My understanding from reading the docs is that the CLASS definition in hosts.cfg is supposed to override the class setting being sent back from the client.
>
> 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(5), analysis.cfg(5) and alerts.cfg(5) to group log file checks or alerts). 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. If not set, then the host belongs to a class named by the operating system the Xymon client is running on
>
> I read that as if I didn't add the --class argument to the xymon client command then what is in hosts.cfg should be the class used.  However, this seems to not be the case (although I would argue that it should work this way).
>
> =G=
>
> ________________________________________
> From: Xymon <xymon-bounces at xymon.com> on behalf of Steve Hill <steve at opendium.com>
> Sent: Wednesday, February 10, 2016 10:31 AM
> To: xymon at xymon.com
> Subject: [Xymon] CLASS not working as expected
>
> Under Xymon 4.3.25, I'm trying to use the class attribute to group hosts
> together by what monitoring and alerting they need.
>
> So for each host I have a hosts.cfg line like:
> 192.0.2.1       somehost.example.com    # CLASS:Foo trace ssh
>
> Then in analysis.cfg I have:
> CLASS=Foo
>          PROC    this
>          PROC    that
>
> And alerts.cfg has:
> CLASS=Foo
>          SCRIPT=blah
>
>
> However, the tests in analysis.cfg are not being applied.  If I replace
> CLASS=Foo with HOST=somehost.example.com they work as expected.  Also,
> CLASS=linux seems to work, which implies that the CLASS: directive in
> the hosts.cfg is being ignored.
>
> As far as I can tell, the messages on xymon's "client" channel don't
> contain the class name that was specified in hosts.cfg, so xymond_client
> is using the class that the client sent instead.  Other channels, such
> as "status" do include the class name that was specified in hosts.cfg.
>
> Am I misunderstanding how the class is supposed to be used, or is this a
> bug?
>
> --
>    - Steve Hill
>      Technical Director
>      Opendium Limited     http://www.opendium.com
>
> Direct contacts:
>      Instant messager: xmpp:steve at opendium.com
>      Email:            steve at opendium.com
>      Phone:            sip:steve at opendium.com
>
> Sales / enquiries contacts:
>      Email:            sales at opendium.com
>      Phone:            +44-1792-824568 / sip:sales at opendium.com
>
> Support contacts:
>      Email:            support at opendium.com
>      Phone:            +44-1792-825748 / sip:support at opendium.com
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>

-- 
Micron Technology, Inc., Confidential and Proprietary

Tom L. Schmidt
Central Engineering System Administrator Lead
Micron Technology, Inc.  http://www.micron.com/
8000 S. Federal Way  P.O. Box 6  Mail Stop 01-351  Boise, Idaho USA 
83707-0006
mailto:tschmidt at micron.com  http://cesa.micron.com/