[Xymon] Combo status question

[Colin Coe]

Hi JC

First up, thanks for the terabithia RPMs  :)

Yep, the devices are polled via devmon.  However, these are switched
ports not routed ports so I can't go by IP.

Also, is it combo.cfg or combostatus.cfg?  I have a combo.cfg but no
combostatus.cfg...

There are only a few combo tests that I want to put in.  One is a test
to see if a particular process is running on either serverA or
serverB.  I can see how to do this for the 'procs' test in general but
not a specific process.  The servers that I want to test are running a
system made up of a couple of hundred processes and with the exception
of one process, they both should be running the same processes.

Thanks

CC



On Mon, Nov 2, 2015 at 11:32 AM, J.C. Cleaver <cleaver at terabithia.org> wrote:
>
>
> On Fri, October 30, 2015 4:15 pm, Colin Coe wrote:
>> Hi all
>>
>> Is it possible to have a combo status for switch ports on non-stacked
>> switches?  For example, gi1/0/24 on either switch sw01 or sw02 must be
>> up.
>>
>> Thanks
>>
>> CC
>
>
> Well, I think anything is possible :) It depends on how you're modeling
> it. Is this something being probed by devmon, or some other type of snmp
> utility? If so, then if they're reporting as distinct tests into xymon, it
> should just be a matter of aligning your combostatus.cfg tests to boolean
> logic around those individual ports / tests: If device1.porta +
> device1.porta > 1, then <unified switch hostname>.porta = green.
>
>
> If by "port" you're more or less meaning "IP address", one way to do it
> would be to use the extended "conn={best,|worst,}IP1[,IP2...]"
> functionality on your hosts.cfg(5) specification. The problem there is
> that you're forfeiting whatever other ping awareness you wanted to have
> WRT the device in question.
>
> Honestly, if you're going to be doing a lot of this across lots of
> devices, I'd look into writing a channel parser (or intermittent status
> query mechanism) that can look at raw data from all the devices at once
> (as reported by... whatever's reporting it now), do some unified
> evaluations, and report it back as a new column against the device.
>
> This is basically duplicating the intent of the combostatus function, but
> with logic specific to what you're looking for out of it.
>
>
> Again, it depends on how xymon is seeing the port information now...
>
> HTH,
> -jc
>