Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CA+96GG5ac3sObN+tif-0yMRJ3idCadKaaOPfX+sA6XhGm_+DGw@mail.gmail.com>
References: <50D04BFB.6040309@citrix.com> <50D04FB9.7090301@citrix.com>
 <CAKprHVZOxyBeqmtSLTtXXN6vfwWwwEj0E4GBOZdqHMBHs05GZw@mail.gmail.com>
 <CAKprHVbQZBVrGcMfseucuAiRp+0TYq9Rt1cWvWrwwzaPyU-xmw@mail.gmail.com>
 <50EBA578.1090106@citrix.com>
 <CA+96GG5ac3sObN+tif-0yMRJ3idCadKaaOPfX+sA6XhGm_+DGw@mail.gmail.com>
From: David Nalley <david@gnsa.us>
Date: Mon, 14 Jan 2013 12:40:45 -0500
Message-ID: 
 <CAKprHVaPpYc46A7s4+Zv_sXbPJ=68Wk06xFQfi-dV7RAWmCOfw@mail.gmail.com>
Subject: Re: [Discuss] SNMP Alerts support in CloudStack
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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?

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