[Xymon] admin and oper status, for xymon icons

[Adam Goryachev]

On 03/10/13 09:26, Bryan Levin wrote:
> 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.
Actually, again, I don't see why there is a problem. If it is 
Admin=down, and the device will ensure Oper=down, then you are right, 
you don't need to check the Oper status. So Admin==down is an automatic 
green. Consider green means good, not Up. So green means that it is 
working as designed/specified, in this case, designed/specified as down.
> 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?
If Admin = down, then you *know* Oper = down, then what is the purpose 
of two half circles when you know both halves will be red. The only case 
where the two halves will be different colours is Admin = Up and Oper = 
down, which IMHO is much better communicated as a single, complete "red" 
just like current.

As suggested:

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

Will cover all 4 possible cases, although you now say that the third 
entry is not possible. So you really only have 3 possible states, which 
I'm suggesting is summarised into two states, 1 - Working as configured, 
2 - Not working as configured/needs attention. I'd suggest you provide 
the detailed information for individual Admin/Oper status (and probably 
a bunch of counters) on the status page after you click on the dot.

BTW, have you considered to separate the configuration of the device to 
the monitoring system? ie, an administrator might accidentally configure 
an interface as down, do you want the monitoring system to presume the 
interface should be down, or presume that there is an error and raise an 
alarm (which is resolved by either updating the device config, or 
updating the monitoring config). There is no right/wrong answer, it 
depends on the specific needs of each network/admin.

PS, not relevant to this entire discussion, but one thing I've been 
battling with is trying to define a "normal" status. eg, I can set the 
CPU load to 5, which normally means the status is always green, but one 
day the cpu load might be 4 at 2pm, and that is abnormal, even though a 
load of 4 at 2am is normal. Does anyone use/do anything to automatically 
watch the current values, and learn what range is "normal" on this 
day/time? For me, this especially applies to counters related to network 
performance, disk performance, etc.

Regards,
Adam
> 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>


-- 
Adam Goryachev Website Managers www.websitemanagers.com.au