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
