Hello!
Almost everything sounds good. I will summarize all the ideas to
something solild, and post resulting text here in a few days.
One question left about outages - is there any reasons to show alarms
flagged as "outage" for nodes on maintenance, while alarms from such
nodes can be just ignored and not shown at all?
Best regards,
Victor
-----Original Message-----
From: Christoffer Blindheim [mailto:netxms_at_christoffer.totalnett.no]
Sent: Thursday, 27 July, 2006 22:59
To: NetXMS Users
Subject: Re: [netxms-users] Better alarm handling
Thanks,
To give the history/real time view better readability you should
consider to use "Alarm Clearance Report"-flag. In stead of reseting the
severity to normal you mark the event/alarm with the clearance flag and
keep the latest severity. TeMIP supports the following severities:
Critical - Major - Minor - Warning - Clear and Indeterminate. The clear
severity is used when there is no alarm to correlate with, the previous
alarm is terminated or did never arrive on NetXMS. TeMIP lacks one
severity / flag in Alarm Clearance Report which can tell the operator
that this alarm will never clear, just information, and can be
terminated at any time.
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.
Another thing you could implement is Perceived/Current Severity. The
first alarm that arrives sets the Original Severity and Perceived
Severity, any updates on the alarm modifies just Perceived/Current
severity.
Also, the message text should be updated.
Should the history of changes in alarm states be kept?
On double-click or context menu a view should be implemented to see the
list of similiar/duplicate alarms.
1. Alarm should have three states - let's call them New, Acknowleged,
Closed.
6. We can also add a flag to indicate that alarm is forwarded to help
desk system.
TeMIP uses a flag Handled and Closed to show the state of the Incident.
Maybe consider use Terminated instead of Closed in the alarm state.
I'm not sure what outage flag means in the model you described. Can you
please explain this?
Outage management is a neat feature that could plan and set certain
manged object into unmanaged for a certain time. Example on 2nd of
August the node "myServer" is going down/unavailible due to
maintenance. Every alarm that the system is generated on the specified
date/time is given a outage flag to tell the system/operator that no
action needs to be done - the system is not managed for the moment :).
The different states of a node could be : Production, Test, Maintenance
etc. The alarm is simply marked with a flag Outage = True (or an icon).
-- Christoffer BlindheimReceived on Fri Jul 28 2006 - 17:43:23 EEST
This archive was generated by hypermail 2.2.0 : Fri Jul 28 2006 - 17:55:02 EEST