Re: [opennms-devel] [opennms-italia] ipotesi cambi amenti nella modalità di individuazione allarme nel flus so 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.

-------------------------------------------------------------------------
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=/

_______________________________________________
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