Re: Better alarm handling

Just as an option. If you implement alarm domains/operational context
the operator could, by use of filters, direct outage-alarms to one
operational context dedicated for outage. But I think that usually users
wants to have such alarms dropped.
 

Victor Kirhenshtein wrote:
> 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 Blindheim
>
Received on Mon Jul 31 2006 - 19:18:22 EEST