Hello!
Your suggestions sounds very interesting. The alarm handling model you
described can be easily implemented. I see it as follows:
1. Alarm should have three states - let's call them New, Acknowleged,
Closed.
2. Alarm should have two timestamps - creation and last change.
3. Alarm key in event processing policy can be used to odentify
duplicate alarms - if alarm with given key already exist in new or
acknowleged state, we just increase repeat count for this alaram and
update last change time.
4. Alarm key in event procesing policy can be used to acknowlege or
close alarm automatically (same way like now you can acknowlege alarms
automatically).
5. There should be possibility to add comments to the alarm.
6. We can also add a flag to indicate that alarm is forwarded to help
desk system.
Users who not interested in a complicated alarm handling will still be
able to use current simple model - they just will need to use "Close"
instead of "Acknowlege".
Any comments are welcome. Also, some my additional questions:
I'm not sure what outage flag means in the model you described. Can you
please explain this?
Should the history of changes in alarm states be kept?
Best regards,
Victor
Received on Thu Jul 27 2006 - 10:10:53 EEST
This archive was generated by hypermail 2.2.0 : Thu Jul 27 2006 - 10:22:31 EEST