On 14/01/13 23:10, David Nalley wrote: > On Mon, Jan 14, 2013 at 11:57 AM, Chip Childers > <chip.child...@sungard.com> wrote: >> On Mon, Jan 7, 2013 at 11:50 PM, Anshul Gangwar >> <anshul.gang...@citrix.com> wrote: >>> On 08/01/13 07:27, David Nalley wrote: >>> >>> >>> I'll be happy to figure out how this gets done. - Actually some quick >>> googling shows that the ASF already has an enterprise OID - and one of >>> our mentors has documented that here: >>> https://cwiki.apache.org/DIRxPMGT/oid-assignment-scheme.html >>> I will follow up with Alex and see if we can get an assignment. >>> >>> >>> >>> >>> Anshul: >>> >>> Sorry for the lag. I was able to ping Alex Karasulu and he quickly >>> assigned Apache CloudStack: >>> 1.3.6.1.4.1.18060.15 >>> >>> You can see this documented at: >>> https://cwiki.apache.org/confluence/display/DIRxPMGT/OID+Assignment+Scheme >>> >>> Have you any thoughts regarding the layout of the MIB yet? I'd like to >>> make sure we plan for the future and things that go beyond simple >>> traps. >>> >>> Thanks David >>> >>> I have mentioned the initial layout of MIB on FS >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Integrating+CS+alerts+via+SNMP+to+external+management+system. >>> It will contain 27 different traps and each trap will contain >>> >>> 1. message >>> 2. podId >>> 3. dataCenterId >>> 4. clusterId >>> >>> --Anshul >>> >>> >>> >>> --David >>> >>> >> Anshul, >> >> Taking a look at your OID layout, I'd suggest making sure that we AT >> LEAST have room in the scheme for being able to add polling. Also, >> the names should be more specific. "memory" isn't a good name for >> what is really availableMemory. >> >> Example to improve the structure a little bit (but not spending a ton >> of time thinking about this): >> >> 1.3.6.1.4.1.18060.15 = [cs_root] >> [cs_root].1 = traps >> [cs_root].1.1 = availableMemory >> >> This leaves room within the cs_root for future expansion. >> >> -chip > > What are you planning on doing when clusterid and podid are not relevant?
I will send them as Null Value > > You have alerts when an SSVM unexpectedly powers off - is that for > every shutdown or only when the last one occurs? Same thing for domR, > if you are running virtual redundant router, do you alert when one or > all go down? In an advanced network, I am not sure that telling me the > 'message, zone, pod, cluster is useful information. Why not account? I am using the existing Alert framework in CloudStack. In there alerts are generated with data center id, pod id , cluster id and message. I am using the same information to send the SNMP traps. There is no information provided about the account in those alerts. > > Also - have you considered making a subset of this available to > end-users - while it may be out of scope for your current work please > design with that in mind. E.g. traps being sent when folks hit > resource limits, VMs fail, etc. I have kept that in mind and hopefully, there will not be need of many changes to support subset. > > --David Thanks, Anshul
