I'm working on a Zenpack that provides some Device Components (Virtual Servers on a BigIP Load Balancer). I'm able to get the components to show up and all that but I'm trying to understand how to control the status column for the component.
I know the OID's to poll to get at the data so I know I can set values at model time, but I'm curious how do I control status during normal (non modeling) polls. I only model once a day, but I'd like the status to be bit more accurate than that.
Currently I have a component template for trending some of the status, so I'm curios do I leverage this same component template for that (It doesnt feel like it), or do I need some other entity to check the status on a more frequent interval.
My second question is around what are acceptable values for the status column. The results I'm pulling back don't line up verbatim with other status I've seen in the UI, so I'm curious if I need map return values to constant Zenoss values, or can I pass the result back as is. Additionally is it possible to define new status values?
Sorry if this is covered in any of the development docs, I wasnt able to find it, but if it is feel free to point me at it.
I see two possibilitys but is is clearly idea without research to that problem. Status is propeties of object. OID read by zenperfsnmp daemon and store value in rrd database, also it compare obtained value with threshhold if its provaded. Now only Min/Max threshold availabel. First idea is write threshold which analyse snmp data and change apropriate properties of object. Or you can write new snmp daemon.
But second problem how change properties, directly take object or use event.
Using snmp get actualy very expensive. How frecuently status is changes? One or two times per day? Maybe right way is use trap.
Problem with trap or syslog is that you get to know when there is a transition between up and down but this doesn't answer the question what is the current status of that component. Besides that, how do you preserve that status between reboots without parsing your entire event database for traps, hoping they were not being dropped by your configured event log aging ?
IMO, OID is the right way of doing it but without the need to keep it in a rrd file. All I need is, based on the value of the OID to display a green/red light between polling intervals.
Few words about traps. You not need track you data base for restore information about status after reboot, insted you should run modeling. Information details depend of soft on you device. For example Cisco router can send all condition of BGP which it can accept (6 passible condition - 6 traps).
Anyway if you deside polling metod, i think right metod will be use treshold which will parsing recived snmp date and will generate event for change status of object.
Can i ask you for which component you wish to now status (which goal you try to solve)?
The scenario I'm thinking of is from the Network Operation Center point of view. Looking at the interfaces of a Cisco switch I want to be able to answer the question on which ports are up and which are down. We're facing this question pretty often for troubleshooting and/or provisioning reasons. I tried the polling method you suggested but we found it generates a lot of events, most of all of no importance for us. Taking as an example an access switch having 2 uplinks and maybe a hundred ports were hosts are being connected, the number of up and down messages generated by PCs at boot/shutdown will flood the event log needlessly. I am interested in receving an event when the uplink goes down and up but I don't want to see such events for PC ports, however I want to know the current status of any port on that switch. I don't need a continuous stream of events even when the status doesn't change. On our network we rely on syslog messages for notification of interfaces going up and down because in Cisco switches you can enable this on a per port basis.
The status for a component uses the status method defined on the IComponentInfo object for the component. Many of our zenpacks override that method to return a status that is appropriate for the component. Some zenpacks introduce transforms to change specific properties on a component that are then in turn used by the IComponentInfo implementation. Hope that helps.
The base/default ComponentInfo can be found here http://dev.zenoss.com/trac/browser/trunk/Products/Zuul/infos/component/__init__.py
Hope that helps
IComponentInfo concerned to UI (display status) but this status on modeling moment (by default 24 hours). General guestion of this topic is how track port status changes in real time. Right?
From nilie last post i see second problem, how to split User Port (which status can frequently changes) and UP-Link (which very important). First what come in mind
use Description filed with predetermined word (for example UP-Link-myisp, UP-Link-backbone), parse this field...
to dpetzel yes event not right way. I review minmaxthreshold and see it passible get object and directly change status.
I start my own zenpack with familiar goal. It can take one week, it will depend on my free time. I can share my experience.
The original post is actually a few questions rolled up into a single post. I'll attempt to break down each to the smallest atomic unit.
components status control in Zenoss is a little bit tricky.
The getStatus method of the DeviceComponent class returned number of events with highest severity. Ths value will be converted to string
by getStatusString method of the same class. By default, this method returned 'Up' string if no events exist, or number of events will be returned.
So, as we can see Zenoss components status is not the same thing as components status value returned by most management software.
The main problem with Zenoss components status concept is that Zenoss doesn't provide simple way to get current (last known) status (raw value) of component.
The detailed components status is only available within events in Event Manager and can not be used in components grid view or in components Details view.
So, if we want to implement components status control, the following questions must be answered.
Q1. Where current status value must be stored?
1. additional components attribute (zodb)
2. events database (MySQL)
Q2. How to update status value?
1. RRDDataPoint->Thershold->Transform->components attribute
2. Event->Transform->components attribute
3. AttrDataPoint(new datapoint type)->components attribute
4. modify Event Manager to store last components status value in events database.
Q3. How to get status value?
1. from components attribute
2. from Event Manager (components status from last event record)
Q4. How to manage severity (dot color)?
1. by displaying components status, calculate dots color based on status-severity map without event generation.
2. generate event with severity based on status-severity map.
PS: In my case i've answered all questions with '1' (1,1,1,1).
Thanks Egor, You've confirmed much of the supsicions I had. Its unfortunate that the status is so difficult to work with. Your idea of an AttrDataPoint sounds the most appealing to me. I'm assuming this data source would not be RRD based in any way, but simply store this data as an attribute of the object in zodb. That would work well for my use case. As it is that is where I am storing it during model time, so updating the same attribute on a more frequent poller would be perfect.
What is the 'proper' place to store this? Attribute named 'status' or a custom attribute, and override the component grid JS?
Follow Us On Twitter »
||Latest from the Zenoss Blog »||Community||Products||Services||Customers||About Us|
Copyright © 2005-2011 Zenoss, Inc.