incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshul Gangwar <anshul.gang...@citrix.com>
Subject Re: [Discuss] SNMP Alerts support in CloudStack
Date Tue, 15 Jan 2013 10:27:00 GMT
On 14/01/13 23:10, David Nalley wrote:
> On Mon, Jan 14, 2013 at 11:57 AM, Chip Childers
> <chip.childers@sungard.com> wrote:
>> On Mon, Jan 7, 2013 at 11:50 PM, Anshul Gangwar
>> <anshul.gangwar@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
Mime
View raw message