Difference between revisions of "UM:Event Processing"
→Alarms Overview
| Line 79: | Line 79: | ||
| 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. A new event with the same alarm ID will reset the alarm state back to outstanding; | | 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 outstanding; | ||
|- | |||
| [[File:Acknowledged_sticky.png]] | |||
| Sticky Acknowledged for time | |||
| Alarm will remain acknowledged for given time interval even after new matching events, after time will pass alarm will be moved to outstanding state. This option can be used like snooze. When you know that there will be new matching events, but it will not change the situation. But after some time someone should check this problem. For example, if you have problem that cannot be solved until next week, so this alarm can be sticky acknowledged for 7 days. After 7 days this problem again will be in outstanding state. | |||
|- | |- | ||
| [[File:Acknowledged_sticky.png]] | | [[File:Acknowledged_sticky.png]] | ||
| Sticky Acknowledged | | Sticky Acknowledged | ||
| Alarm will remain acknowledged | | Alarm will remain acknowledged even 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. | ||
|- | |- | ||