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 <andreaco...@yahoo.it>
A: da...@opennms.com
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 <da...@opennms.com>
A: La mailing list di OpenNMS Italia <opennms-ita...@lists.sourceforge.net
>; DeveloperList <opennms-devel@lists.sourceforge.net>
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
opennms-ita...@lists.sourceforge.net
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
opennms-ita...@lists.sourceforge.net
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
