[Xymon] admin and oper status, for xymon icons

[Bryan Levin]

hi Adam,

You covered the cases where admin and oper are equal or not equal and those make sense.

Suppose that a service is shut down (admin=down).  In that case, I won't even poll for any other variables in that mib-group and I won't poll for the oper-status of that object, either.  This is not an error, its what the manager wanted (that thing being administratively shut down).  Given that it was shut down on purpose, green is not right for this icon, red is not right, yellow is not right.  I have choices of blue (not quite right) or clear/white color.

Maybe that's the best we can do.

So, its not just if admin!=oper; but you check admin first and if admin is up, you continue testing for oper.  If admin is down, it would not make sense to check further (I guess its possible that you shut something down and yet its still running, but given that our devices are snmp-based, when we send an admin=down request, we can be pretty sure that oper will also follow.  At least in the case of our devices.

I'm curious if others have done anything to show the dual status, in some way?  Not sure I'd want to do this - but it could be possible to patch xymon and show half circles, with admin color on the left side and oper color on the right ;)  Maybe that's too strange?


From: Adam Goryachev [mailinglists at websitemanagers.com.au]
Sent: Wednesday, October 02, 2013 3:56 PM
To: Bryan Levin
Subject: Re: [Xymon] admin and oper status, for xymon icons

On 03/10/13 04:17, Bryan Levin wrote:
In snmp (I realize xymon is not native snmp-based) there is a common concept of admin status and oper status.  Briefly, admin status is what the manager set for an object and oper status is its current status.  The classic example is Ethernet where the manager can ifconfig an interface down or up (that would be the admin status) while the current link status would be oper.

I’m having trouble mapping this set of status values to the single color that xymon allows.  At first, I was marking some objects (manually, via my own snmp-based poller) as blue if the object was a ‘controlled down’ and red if it was supposed to be up but its current status was down.  However, I’m not sure this is the best way to do this.  I’m considering using ‘clear’ as the color for unknown or unpolled or not-yet-polled values but also for controlled-down objects.  Using red for ‘admin==up, oper==down’ seems to be a good use of red in xymon.  And blue is an ‘on-hold’ status where you have turned off polling or you want to ignore a certain object and not have its value change (also not have it appear in the ‘non-greens’ display).  But if an object is blue, I will never change it to non-blue until the mgmt interface (in xymon or via messages sent to xymon server) specifically take that object off the on-hold list.

Has there been any thought to evolving the xymon color and status concepts to include the duality of admin and oper?  It seems that trying to compress the 2 states into one is problematic and not very clean in architecture.

I’m curious what people have done in this regard.


I can't say I've done anything with those SNMP values in xymon, but I think you are trying to do something like this:

Admin   Oper     Xymon
Up         Up        Green
Up         Down    Red
Down     Up        Red
Down     Down   Green

At least, that's the way I'd map it, if Admin == Oper, then everything is good (green), if Admin != Oper, then it's very bad (red). It's very similar to the service monitoring in xymon, if you specify a service should be up, and it is down, you get a red. Equally, if you specify a service should not be running (eg telnet), and it is running, then you get a red.

Hope that helps.

Regards,
Adam

--
Adam Goryachev Website Managers www.websitemanagers.com.au<http://www.websitemanagers.com.au>