Re: [opennms-devel] [opennms-italia] ipotesi cambi amenti nella modalità di individuazione allarme nel flus so di ricezione evento

Andrea,

I have almost completed the move of alarm persistence to a daemon.   
Should be completed by the end of the year.  We need this performance  
improvement to deal with the high volume of traps received by some  
users of OpenNMS.... communications companies, typically.

I want to work with you on the pluggable strategy.  We can make the  
current automations strategy be the first implementation as a proof of  
concept for your contribution.

ciao,

David


On Dec 18, 2008, at 9:59 AM, Andrea Colpo wrote:

> ciao a tutti,
> provo a reinviare quest'emial tramite la mailing list... forse a  
> David è sfuggita
> grazie
>
> Hi all,
> i'll try to send this email to the mailing list ... maybe David was  
> busy when he had received it.
> thanks.
>
> Da: Andrea Colpo <[email protected]>
> A: [email protected]
> Inviato: Venerdì 5 dicembre 2008, 17:09:48
> Oggetto: Re: [opennms-italia] ipotesi cambiamenti nella modalità di  
> individuazione allarme nel flusso di ricezione evento
>
> Hi David,
> thanks for your reply, and sorry if i didn't write you back after  
> this.
> I have downloaded OpenNMS 1.6.1-1, but i see that actually there is  
> no Strategy implementation for Alarm Management.
> Do you really plan to introduce it or is actually a low level  
> priority task?
> What about if we do such kind of enhancement in the next month and  
> send it to you or commit in a separate branch?
> Regards.
> Andrea C.
>
> Da: David Hustace <[email protected]>
> A: La mailing list di OpenNMS Italia <[email protected] 
> >; DeveloperList <[email protected]>
> Inviato: Mercoledì 8 ottobre 2008, 13:59:50
> Oggetto: Re: [opennms-italia] ipotesi cambiamenti nella modalità di  
> individuazione allarme nel flusso di ricezione evento
>
> Please do not apologize for verbosity, but please accept my  
> apologies for the translation to English... perhaps Antonio can help  
> with translation.  I understand your requirement, however, your  
> solution I would encourage a different approach.
>
> Our current alarm system behaves very closely in the same way as  
> Netcool/Omnibus.  If you are looking for a standards based approach  
> to integration with openNMS' alarm system, then I would use the Qosd  
> interface that exposes Alarms via an OSS/J implementation of the  
> NGOSS QoS (fault management) specification.
>
> In the near future (after 1.6.0 release) I plan to move the Alarm  
> management to a separate service daemon.  We can then allow for a  
> pluggable alarm management strategy were the current Impl can be  
> replaced with say a TS32Impl.
>
> Ciao,
>
> David
>
>
> On Oct 7, 2008, at 12:14 PM, Andrea Colpo wrote:
>
>> Hello everyone,
>> We have an ongoing POC based on OpenNMS and were considering a  
>> possible change
>> In case of duplication of alarms, or rather in the way of an  
>> association to an alarm already created.
>> Following the 3GPP TS32.111 specific behavior should be this:
>>
>> An alarm or rather an instance of alarm is created by the system  
>> when it is received by a NE occurrence of an event of a fault alarm  
>> and this is not already present nell'AlarmLog.
>> The cycle will close when the alarm created by the system at the  
>> event, you will find in Cleared and acknowledged.
>> For instance every alarm is assigned a unique identifier system  
>> "AlarmId."
>> Any change in the severity of the alarm within its life cycle  
>> results in an update.
>> At the end of its life the record is no longer visible on Alarm View.
>> So any reinsorgenza the same alarm on the same resort will feature  
>> a new record with a new Alarm Id.
>> NB: a 'resort Cleared but unacknowledged can reinsorgere,  
>> maintaining the same AlarmId.
>>
>> The class EventdConstants contains this query used by  
>> JdbAlarmWriter of whether to update the count of an existing alarm  
>> or create a new one.
>> He is currently defined as:
>>
>>      public static final String SQL_DB_ALARM_REDUCTION_QUERY =
>>              "SELECT alarmid"
>>              "FROM alarms"
>>              "WHERE reductionKey =?";
>>
>> Amendments on condition where with this addition:
>> "AND NOT (severity = 2 AND alarmackuser IS NOT NULL)" is that the  
>> alarm would be upgraded to the count of events and the last event  
>> is connected
>> identified by excluding alarms that have been CLEARED and have a  
>> ACKNOWLEDGE.
>>
>> At this point should be clarified is treated as an alarm or being  
>> CLEARED and UNACKNOWLEDGE, the occurrence of an event
>> reinsorgenza of the problem. I believe that the alarm should be  
>> restored to the severity collection by OpenNMS configuration for  
>> the type of event
>> and then you should speak on this method (below) to add the  
>> severity of the fields that are updated:
>>
>> private void updateAlarm (Header eventHeader, Event event, int  
>> alarmId, Connection connection) throws SqlException (... )
>>
>>
>>
>> It's also a case to speculate if the alarm is NOT CLEARED (assume  
>> MINOR) and ACKNOWLEDGE, we should probably
>>
>> make configurable (with a concept of policy control) if another  
>> signal must be lifted its ACKNOWLEDGE, for example, only
>>
>> if the severity that would function in the event of serious  
>> reinsorgenza is the current state.
>>
>>
>>
>> I apologize for the verbosity of quest'email. I did not want to  
>> make a treaty, actually I wanted to understand if this kind
>> changes are of interest to all and submit them for approval to pay  
>> the repository of public sources. In a branch?
>
>
>
>
>> Ciao a tutti,
>> abbiamo in corso una POC basata su OpenNMS e stavamo valutando un  
>> possibile cambiamento
>> nella modalità di deduplicazione degli allarmi, o meglio nella  
>> modalità di associazione di un evento ad un allarme già creato.
>> Seguendo la specifica 3GPP TS32.111 il comportamento dovrebbe  
>> essere questo :
>>
>> Un allarme o meglio una istanza di allarme viene creata dal sistema  
>> quando viene ricevuto da un NE un evento di insorgenza di un guasto  
>> e questo allarme non è già presente nell’AlarmLog.
>> Il ciclo dell’allarme si chiude quando l’allarme, creato dal  
>> sistema in corrispondenza dell’evento, si troverà in stato Cleared  
>> e Acknowledged.
>> Ad ogni istanza di allarme viene assegnato un identificatore  
>> univoco dal sistema: “AlarmId”.
>> Ogni variazione di severità dell’allarme all’interno del suo ciclo  
>> di vita dà luogo ad un update.
>> Al termine del ciclo di vita il record non è più visibile sulle  
>> Alarm View.
>> Quindi l’eventuale reinsorgenza dello stesso allarme sulla stessa  
>> risorsa sarà caratterizzato da un nuovo record con un nuovo  Alarm  
>> Id.
>> NB: un’ istanza Cleared ma unacknowledged può reinsorgere,  
>> mantenendo il medesimo AlarmId.
>>
>> La classe EventdConstants contiene questa query utilizzata da  
>> JdbAlarmWriter per capire se aggiornare il count di un allarme  
>> esistente o crearne uno nuovo.
>> Attualmente è definita così:
>>
>>     public final static String SQL_DB_ALARM_REDUCTION_QUERY =
>>             "SELECT alarmid " +
>>             "  FROM alarms " +
>>             " WHERE reductionKey = ?";
>>
>> Modificandola sulla where condition con questa aggiunta :
>> “AND NOT(severity=2 AND alarmackuser IS NOT NULL)” si avrebbe che  
>> l'allarme da aggiornare per il count degli eventi e per l'ultimo  
>> evento collegato sia
>> individuato escludendo gli allarmi che sono in stato CLEARED e che  
>> hanno un ACKNOWLEDGE.
>>
>> A questo punto, occorrerebbe chiarire come viene trattato un  
>> allarme in stato CLEARED e UNACKNOWLEDGE, al sopraggiungere di un  
>> evento
>> di reinsorgenza del problema. Credo che l'allarme dovrebbe essere  
>> ripristinato alla severity raccolta dalla configurazione di OpenNMS  
>> per il tipo di evento
>> e quindi si dovrebbe intervenire su questo metodo (che segue) per  
>> aggiungere anche la severity tra i campi che vengono aggiornati :
>>
>> private void updateAlarm(Header eventHeader, Event event, int  
>> alarmId, Connection connection) throws SQLException { ... }
>>
>>
>> E anche il caso speculare, se l'allarme NON è CLEARED (ipotizziamo  
>> MINOR) ed è ACKNOWLEDGE, dovremmo probabilmente
>>
>> rendere configurabile (con un concetto di policy di controllo) se  
>> all'allarme deve essere tolto l'ACKNOWLEDGE, ad esempio solo
>>
>> se la severity che assumerebbe in funzione dell'evento di  
>> reinsorgenza è + grave dello stato attuale.
>>
>>
>> Mi scuso per la prolissità di quest'email. Non volevo fare un  
>> trattato, in realtà volevo capire se questo tipo
>> di modifiche siano di interesse a tutti e come sottoporle ad  
>> approvazione per versarle sul repository dei sorgenti pubblico. In  
>> una branch ?
>>
>> Saluti.
>> Andrea C.
>>
>> Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e  
>> scrivi la tua  
>> opinione 
>> !-------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
>> Opennms-Italia mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opennms-italia
>
> David Hustace
> The OpenNMS Group, Inc.
>
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
> Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to  
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/_______________________________________________
> Opennms-Italia mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opennms-italia

David Hustace
The OpenNMS Group, Inc.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/

_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-devel mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel