57
edits
Difference between revisions of "UM:Event Processing"
→Alarms Overview: Status icons & two states added
Lukas Rypl (talk | contribs) (→Alarms Overview: Status icons & two states added) |
|||
| Line 68: | Line 68: | ||
|- | |- | ||
| State | | State | ||
| Alarm can be in one of | | Alarm can be in one of the following states: | ||
{| style="border: 0px" | {| style="border: 0px" | ||
| [[File:Outstanding.png]] | |||
| Outstanding | | Outstanding | ||
| New alarm; | | New alarm; | ||
|- | |- | ||
| [[File:Acknowledged.png]] | |||
| Acknowledged | | Acknowledged | ||
| When network administrator sees an alarm, he may ''acknowledge'' it to indicate that somebody already aware of that problem and working on it; | | When network administrator sees an alarm, he may ''acknowledge'' it to indicate that somebody already aware of that problem and working on it. A new event with the same alarm ID will reset the alarm state back to acknowledge; | ||
|- | |- | ||
| [[File:Acknowledged_sticky.png]] | |||
| Sticky Acknowledged | |||
| Alarm will remain acknowledged event after new matching events. This can be useful when you know that there will be new matching events, but it will not change the situation. For example, if you have network device which will send new SNMP trap every minute until problem solved, sticky acknowledge will help to eliminate unnecessary outstanding alarms. | |||
|- | |||
| [[File:Resolved.png]] | |||
| Resolved | |||
| Network administrator sets this state when the problem is solved. | |||
|- | |||
| [[File:Terminated.png]] | |||
| Terminated | | Terminated | ||
| Inactive alarm. When problem is solved, network administrator can terminate alarm. This will remove alarm from active alarms list and it will not be seen in console, but alarm record will remain in database. | | Inactive alarm. When problem is solved, network administrator can terminate alarm. This will remove alarm from active alarms list and it will not be seen in console, but alarm record will remain in database. | ||