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? 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? 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. --David
