Xymon Mailing List Archive search

Combo status question

4 messages in this thread

list Colin Coe · Sat, 31 Oct 2015 08:15:55 +0800 ·
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
list Japheth Cleaver · Sun, 1 Nov 2015 19:32:59 -0800 ·
quoted from Colin Coe

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
list Colin Coe · Tue, 10 Nov 2015 11:12:17 +0800 ·
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
quoted from Japheth Cleaver


On Mon, Nov 2, 2015 at 11:32 AM, J.C. Cleaver <user-87556346d4af@xymon.invalid> 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
list Japheth Cleaver · Tue, 10 Nov 2015 06:45:41 -0800 ·
On Mon, November 9, 2015 7:12 pm, Colin Coe wrote:
Hi JC

First up, thanks for the terabithia RPMs  :)
No problem :)
quoted from Colin Coe
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...
Ack, my mistake. Yes, it's combo.cfg.
quoted from Colin Coe

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.
Unfortunately, there's no great way to do this at this time. combostatus
only functions by evaluating overall test status and not individual
groupings. My suggestion would be to write an interval-based parser that
downloads current process status state (and content) en masse via
xymondboard, performs the correlation (I'd suggest perl, which is fine at
simple hash structures like this), and then re-submits new test results.


A blue sky feature I'd considered going forward came out of the epiphany
that the GROUP= concept (as used in status message generation and
alerting), the modify "sourcename" (for overriding an existing color and
test result), and the '&color + reason' lines from analysis.cfg or other
generators (which get nicely parsed out in xymongen availability reports)
are all conceptually the same thing: a manner for a sub-status, referred
to by tag or identifier, to automatically affect a larger status while
still being tracked and acted upon distinctly.

It would be nice to expand this to a fully-supported concept in a future
release. Being able to query and channelize changes in "sub-status" (for
lack of a better term) would make a lot of processes like this a lot
easier.


Regards,
-jc