UM:Event Processing - Revision history

AlexKirhenshtein: Text replacement - "^" to "{{deprecated}}"

2022-09-13T16:13:54Z

Text replacement - "^" to "{{deprecated}}"

← Older revision		Revision as of 16:13, 13 September 2022
Line 1:		Line 1:
	Information moved to documentation:		{{deprecated}}Information moved to documentation:

	https://www.netxms.org/documentation/adminguide/event-processing.html		https://www.netxms.org/documentation/adminguide/event-processing.html

TatjanaDubrovica at 14:09, 24 November 2017

2017-11-24T14:09:01Z

← Older revision		Revision as of 14:09, 24 November 2017
Line 1:		Line 1:
	Information moved to documentation:		Information moved to documentation:

	https://www.netxms.org/documentation/adminguide		https://www.netxms.org/documentation/adminguide/event-processing.html

TatjanaDubrovica: Replaced content with "Information moved to documentation: https://www.netxms.org/documentation/adminguide"

2017-11-24T14:05:37Z

Replaced content with "Information moved to documentation: https://www.netxms.org/documentation/adminguide"

Show changes

TatjanaDubrovica: /* Alarms Overview */

2014-01-24T14:56:04Z

Alarms Overview

← Older revision		Revision as of 14:56, 24 January 2014
Line 122:		Line 122:
	Not strict(by default):		Not strict(by default):

	[[File:~~424px-~~AlarmStatesTransitionsInvokedByUser-NOTstrict.png]]		[[File:AlarmStatesTransitionsInvokedByUser-NOTstrict.png\|424px]]


	Strict:		Strict:

	[[File:~~424px-~~AlarmStatesTransitionsInvokedByUser-strict.png]]		[[File:AlarmStatesTransitionsInvokedByUser-strict.png\|424px]]

	=== Generating Alarms ===		=== Generating Alarms ===

TatjanaDubrovica: /* Alarms Overview */

2014-01-24T14:54:14Z

Alarms Overview

← Older revision		Revision as of 14:54, 24 January 2014
Line 122:		Line 122:
	Not strict(by default):		Not strict(by default):

	[[File:AlarmStatesTransitionsInvokedByUser-NOTstrict.png]]		[[File:424px-AlarmStatesTransitionsInvokedByUser-NOTstrict.png]]


	Strict:		Strict:

	[[File:AlarmStatesTransitionsInvokedByUser-strict.png]]		[[File:424px-AlarmStatesTransitionsInvokedByUser-strict.png]]

	=== Generating Alarms ===		=== Generating Alarms ===

TatjanaDubrovica: /* Alarms Overview */

2014-01-24T14:53:13Z

Alarms Overview

← Older revision		Revision as of 14:53, 24 January 2014
Line 118:		Line 118:
	\|}		\|}

	~~User can change~~ alarm state ~~according to the following diagram~~:		There are 2 types of alarm state flows: strict and not strict. This option can be configured in Preference page of Alarms or on server configuration page, parameter "StrictAlarmStatusFlow". The difference between them is that in strict mode Terminate can be done only after Resolve state.

	[[File:AlarmStatesTransitionsInvokedByUser.png]]		Not strict(by default):

			[[File:AlarmStatesTransitionsInvokedByUser-NOTstrict.png]]


			Strict:

			[[File:AlarmStatesTransitionsInvokedByUser-strict.png]]

	=== Generating Alarms ===		=== Generating Alarms ===

178.236.195.24: /* Alarms Overview */

2014-01-24T13:38:32Z

Alarms Overview

← Older revision		Revision as of 13:38, 24 January 2014
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 ~~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.		\| 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.

	\|-		\|-

Victor: /* Alarms Overview */

2012-12-19T20:37:34Z

Alarms Overview

← Older revision		Revision as of 20:37, 19 December 2012
Line 70:		Line 70:
	\| Alarm can be in one of the following states:		\| Alarm can be in one of the following states:

	{\| ~~style~~="~~border: 0px~~"		{\| class="wikitable"
	\| [[File:Outstanding.png]]		\| [[File:Outstanding.png]]
	\| Outstanding		\| Outstanding
Line 78:		Line 78:
	\| [[File:Acknowledged.png]]		\| [[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. A new event with the same alarm ID will reset the alarm state back to ~~acknowledge~~;		\| 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;

	\|-		\|-

Lukas Rypl: /* Alarms Overview */ State change diagram.

2012-12-19T15:31:10Z

Alarms Overview: State change diagram.

← Older revision		Revision as of 15:31, 19 December 2012
Line 112:		Line 112:

	\|}		\|}

			User can change alarm state according to the following diagram:

			[[File:AlarmStatesTransitionsInvokedByUser.png]]

	=== Generating Alarms ===		=== Generating Alarms ===

Lukas Rypl: /* Alarms Overview */ Status icons & two states added

2012-12-19T14:44:46Z

Alarms Overview: Status icons & two states added

← Older revision		Revision as of 14:44, 19 December 2012
Line 68:		Line 68:
	\|-		\|-
	\| State		\| State
	\| Alarm can be in one of ~~three~~ states:		\| 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.