UM:Basic Concepts - Revision history

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

2022-09-13T16:13:53Z

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

← Older revision		Revision as of 16:13, 13 September 2022
Line 1:		Line 1:
	{{DISPLAYTITLE:Basic Concepts}}		{{deprecated}}{{DISPLAYTITLE:Basic Concepts}}
	= Overview of System Architecture =		= Overview of System Architecture =

Lukas Rypl: /* Objects */

2013-01-07T04:27:06Z

Objects

@@ Line 17: / Line 17: @@
 = Objects =
-All network infrastructure monitored by NetXMS inside monitoring system represented as a set of objects. Each object represents one physical or logical entity (like host or network interface), or group of them. Objects organized into hierarchical structure. There are 12 different object classes:
+{{Objects}}
 = DCI (Data Collection Items) =

Macro: /* Objects */

2012-06-19T21:13:27Z

Objects

← Older revision		Revision as of 21:13, 19 June 2012
Line 19:		Line 19:
	All network infrastructure monitored by NetXMS inside monitoring system represented as a set of objects. Each object represents one physical or logical entity (like host or network interface), or group of them. Objects organized into hierarchical structure. There are 12 different object classes:		All network infrastructure monitored by NetXMS inside monitoring system represented as a set of objects. Each object represents one physical or logical entity (like host or network interface), or group of them. Objects organized into hierarchical structure. There are 12 different object classes:

	{\| class="wikitable" style="width: 60%"		{\| class="wikitable" style="width: 70%"
	! width="20%"\|Object class\|\| Description		! width="20%"\|Object class\|\| Description
	\|-		\|-

Macro: /* Thresholds */

2012-05-14T22:22:42Z

Thresholds

← Older revision		Revision as of 22:22, 14 May 2012
Line 83:		Line 83:
	= Thresholds =		= Thresholds =

	Each threshold is a combination of condition and events pair ~~— if~~ condition becomes true, associated "activation" event generated, and when it's becomes false again, "deactivation" event generated. Thresholds let you take a proactive approach to network management. You can define thresholds for any data collection items that you are monitoring. When setting thresholds, first determine what would constitute reasonable thresholds. To decide on a threshold value, you need to know what is normal value and what is out of range. Only you can decide what is normal behavior for a device on your network. Generally, ~~we recommend~~ that you collect information about a device throughout one complete business cycle, before determining the normal high/low range. Consider collecting values such as error rates, retry limits, collisions, throughput, relation rates, and many more. You also have the possibility to define more than one threshold for a single DCI, which allows you to distinguish between different severity conditions.		Each threshold is a combination of a condition and an events pair. If a condition becomes true, associated "activation" event generated, and when it's becomes false again, "deactivation" event generated. Thresholds let you take a proactive approach to network management. You can define thresholds for any data collection items that you are monitoring. When setting thresholds, first determine what would constitute reasonable thresholds. To decide on a threshold value, you need to know what is normal value and what is out of range. Only you can decide what is normal behavior for a device on your network. Generally, it's recommended that you collect information about a device throughout one complete business cycle, before determining the normal high/low range. Consider collecting values such as error rates, retry limits, collisions, throughput, relation rates, and many more. You also have the possibility to define more than one threshold for a single DCI, which allows you to distinguish between different severity conditions.

	= Events and Alarms =		= Events and Alarms =

Macro: /* DCI (Data Collection Items) */

2012-05-14T22:18:20Z

DCI (Data Collection Items)

← Older revision		Revision as of 22:18, 14 May 2012
Line 54:		Line 54:


	Every node can have many parameters, like CPU utilization or amount of free memory~~, which can be collected by~~ management server, ~~checked~~ for threshold violations, and ~~stored~~ in the database. In NetXMS, parameters configured for collection are called Data Collection Items or DCI for short. One DCI represents one node's parameter, and unlimited number of DCIs can be configured for any node.		Every node can have many parameters, like CPU utilization, amount of free memory or disk space usage. The management server can collect these parameters, check them for threshold violations and store them in the database. In NetXMS, parameters configured for collection are called Data Collection Items or DCI for short. One DCI represents one node's parameter, and unlimited number of DCIs can be configured for any node.

	Each data collection item has various attributes controlling its handling:		Each data collection item has various attributes controlling its handling:
	{\| class="wikitable"		{\| class="wikitable" style="width: 70%"
			! Attribute \|\| Description
	\|-		\|-
	\| Description \|\| A free-form text string describing DCI. It is not used by the server and is intended for better information understanding by operators.		\| Description \|\| A free-form text string describing DCI. It is not used by the server and is intended for better information understanding by operators.
Line 67:		Line 68:
	\| Data Type \|\| Data type for a parameter. Can be one of the following: Integer, Unsigned Integer, 64-bit Integer, 64-bit Unsigned Integer, Float (floating point number), or String. Selected data type affects processing of collected data — for example, you cannot use operations like ”less than” or ”greater than” on strings.		\| Data Type \|\| Data type for a parameter. Can be one of the following: Integer, Unsigned Integer, 64-bit Integer, 64-bit Unsigned Integer, Float (floating point number), or String. Selected data type affects processing of collected data — for example, you cannot use operations like ”less than” or ”greater than” on strings.
	\|-		\|-
	\| Retention Time \|\| This attribute specifies how long collected data ~~should~~ be kept in database, in days. Minimum retention time is 1 day, and maximum is ~~not limited~~. However, keeping too many collected values for too long will lead to significant increase of your database size and possible performance degradation.		\| Retention Time \|\| This attribute specifies how long collected data must be kept in the database, in days. Minimum retention time is 1 day, and maximum is unlimited. However, keeping too many collected values for too long will lead to significant increase of your database size and possible performance degradation.
	\|-		\|-
	\| Schedule Type \|\| Type of the collection schedule used; can be either simple or advanced. In a simple mode, values are taken from target at fixed intervals. In an advanced mode, cron-like scheduling table can be used to specify the exact time for polling. This can be useful if, for example, you wish to check the file size every Monday and Friday at 7:00.		\| Schedule Type \|\| Type of the collection schedule used; can be either simple or advanced. In a simple mode, values are taken from target at fixed intervals. In an advanced mode, cron-like scheduling table can be used to specify the exact time for polling. This can be useful if, for example, you wish to check the file size every Monday and Friday at 7:00.

Macro: /* Overview of System Architecture */

2012-05-13T23:23:14Z

Overview of System Architecture

← Older revision		Revision as of 23:23, 13 May 2012
Line 2:		Line 2:
	= Overview of System Architecture =		= Overview of System Architecture =

	The system ~~has~~ three-tier architecture~~: the information is collected by~~ monitoring agents (either NetXMS native agents or SNMP agents) and ~~delivered~~ to monitoring server for processing and storage. Network ~~administrator~~ can configure system and access collected data using ~~portable~~ Java-based Management Console, Web Interface, or Mobile Management Console. You can see an overview of NetXMS architecture on the following diagram.		The system is built on the three-tier architecture. The monitoring agents (either NetXMS native agents or SNMP agents) collect the information and deliver it to the monitoring server for processing and storage. Network administrators can configure the system and access collected data using cross-platform Java-based Management Console, Web Interface or Mobile Management Console. You can see the overview of the NetXMS system architecture on the following diagram.
	::[[File:um_architecture.png\|thumb\|650px\|none\|alt=Architecture\|NetXMS Architecture]]		::[[File:um_architecture.png\|thumb\|650px\|none\|alt=Architecture\|NetXMS Architecture]]

	All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.		All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.
	NetXMS web-based ~~used~~ interface is built as a single war file and can be deployed to any compatible application server (like Tomcat or Jetty). It is a separate component and can be installed on the same physical machine as NetXMS server, or on a remote server.		NetXMS web-based user interface is built as a single war file and can be deployed to any compatible application server (like Tomcat or Jetty). It is a separate component and can be installed on the same physical machine as NetXMS server, or on a remote server.
	The system ~~was~~ designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The following figure shows main software layer of NetXMS system.		The system has been designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The following figure shows main software layer of NetXMS system.

	::[[File:Main_Software_Layer.png\|thumb\|650px\|none\|alt=Software layers\|NetXMS Software Layers]]		::[[File:Main_Software_Layer.png\|thumb\|650px\|none\|alt=Software layers\|NetXMS Software Layers]]

Macro: /* Overview of System Architecture */

2012-05-13T23:13:16Z

Overview of System Architecture

← Older revision		Revision as of 23:13, 13 May 2012
Line 7:		Line 7:
	All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.		All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.
	NetXMS web-based used interface is built as a single war file and can be deployed to any compatible application server (like Tomcat or Jetty). It is a separate component and can be installed on the same physical machine as NetXMS server, or on a remote server.		NetXMS web-based used interface is built as a single war file and can be deployed to any compatible application server (like Tomcat or Jetty). It is a separate component and can be installed on the same physical machine as NetXMS server, or on a remote server.
	The system was designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The ~~followoing~~ figure shows main software layer of NetXMS system.		The system was designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The following figure shows main software layer of NetXMS system.

	::[[File:Main_Software_Layer.png\|thumb\|650px\|none\|alt=Software layers\|NetXMS Software Layers]]		::[[File:Main_Software_Layer.png\|thumb\|650px\|none\|alt=Software layers\|NetXMS Software Layers]]

Macro: /* Objects */

2012-05-13T23:11:13Z

Objects

← Older revision		Revision as of 23:11, 13 May 2012
Line 19:		Line 19:
	All network infrastructure monitored by NetXMS inside monitoring system represented as a set of objects. Each object represents one physical or logical entity (like host or network interface), or group of them. Objects organized into hierarchical structure. There are 12 different object classes:		All network infrastructure monitored by NetXMS inside monitoring system represented as a set of objects. Each object represents one physical or logical entity (like host or network interface), or group of them. Objects organized into hierarchical structure. There are 12 different object classes:

	{\| class="wikitable"		{\| class="wikitable" style="width: 60%"
			! width="20%"\|Object class\|\| Description
			\|-
	\| Entire Network \|\| Abstract object representing root of IP topology tree. All subnet objects located under it. System can have only one object of this class.		\| Entire Network \|\| Abstract object representing root of IP topology tree. All subnet objects located under it. System can have only one object of this class.
	\|-		\|-

Macro: /* Overview of System Architecture */

2012-05-13T23:06:16Z

Overview of System Architecture

← Older revision		Revision as of 23:06, 13 May 2012
Line 3:		Line 3:

	The system has three-tier architecture: the information is collected by monitoring agents (either NetXMS native agents or SNMP agents) and delivered to monitoring server for processing and storage. Network administrator can configure system and access collected data using portable Java-based Management Console, Web Interface, or Mobile Management Console. You can see an overview of NetXMS architecture on the following diagram.		The system has three-tier architecture: the information is collected by monitoring agents (either NetXMS native agents or SNMP agents) and delivered to monitoring server for processing and storage. Network administrator can configure system and access collected data using portable Java-based Management Console, Web Interface, or Mobile Management Console. You can see an overview of NetXMS architecture on the following diagram.
	::[[File:um_architecture.png]]		::[[File:um_architecture.png\|thumb\|650px\|none\|alt=Architecture\|NetXMS Architecture]]

	All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.		All collected data and system configuration is stored in the SQL database. You can choose Oracle, Microsoft SQL Server, PostgreSQL, MySQL, or SQLite as your database engine. Database server can be installed on the same physical machine, or be a separate server.
Line 9:		Line 9:
	The system was designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The followoing figure shows main software layer of NetXMS system.		The system was designed to be easily extendable; so all three tiers — server, agent, and client — have modular structure. The followoing figure shows main software layer of NetXMS system.

	::[[File:~~um_software_layers~~.png]]		::[[File:Main_Software_Layer.png\|thumb\|650px\|none\|alt=Software layers\|NetXMS Software Layers]]

	All system components use two libraries: NetXMS Foundation Library and Communication Library. These libraries provide communication between all system components. The server also has an underlying DB Driver API layer, which provides uniform database engine interface by using database drivers. This approach allows developers to add support for new database engines in a matter of days without changing or even recompiling server code.		All system components use two libraries: NetXMS Foundation Library and Communication Library. These libraries provide communication between all system components. The server also has an underlying DB Driver API layer, which provides uniform database engine interface by using database drivers. This approach allows developers to add support for new database engines in a matter of days without changing or even recompiling server code.

AlexKirhenshtein: /* DCI (Data Collection Items) */

2012-04-07T23:39:03Z

DCI (Data Collection Items)

← Older revision		Revision as of 23:39, 7 April 2012
Line 53:		Line 53:

	Every node can have many parameters, like CPU utilization or amount of free memory, which can be collected by management server, checked for threshold violations, and stored in the database. In NetXMS, parameters configured for collection are called Data Collection Items or DCI for short. One DCI represents one node's parameter, and unlimited number of DCIs can be configured for any node.		Every node can have many parameters, like CPU utilization or amount of free memory, which can be collected by management server, checked for threshold violations, and stored in the database. In NetXMS, parameters configured for collection are called Data Collection Items or DCI for short. One DCI represents one node's parameter, and unlimited number of DCIs can be configured for any node.

	Each data collection item has various attributes controlling its handling:		Each data collection item has various attributes controlling its handling:
	{\| class="wikitable"		{\| class="wikitable"