UM:Objects - Revision history

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

2022-09-13T16:13:59Z

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/object-management.html		https://www.netxms.org/documentation/adminguide/object-management.html

TatjanaDubrovica at 14:08, 24 November 2017

2017-11-24T14:08:22Z

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

	https://www.netxms.org/documentation/~~userguide~~		https://www.netxms.org/documentation/adminguide/object-management.html

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

2017-11-24T14:04:05Z

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

Show changes

Lukas Rypl: /* Object Status */ typo

2013-01-17T07:12:49Z

Object Status: typo

← Older revision		Revision as of 07:12, 17 January 2013
Line 107:		Line 107:
	\| [[File:status_critical.png]] \|\| Critical \|\| Critical problem(s) exist for the object.		\| [[File:status_critical.png]] \|\| Critical \|\| Critical problem(s) exist for the object.
	\|-		\|-
	\| [[File:status_unknown.png]] \|\| Unknown \|\| Object's status is unknown to the ~~mamngement~~ server.		\| [[File:status_unknown.png]] \|\| Unknown \|\| Object's status is unknown to the management server.
	\|-		\|-
	\| [[File:status_unmanaged.png]] \|\| Unmanaged \|\| Object is set to "unmanaged" state.		\| [[File:status_unmanaged.png]] \|\| Unmanaged \|\| Object is set to "unmanaged" state.

Lukas Rypl: Report

2013-01-17T07:11:56Z

Report

← Older revision		Revision as of 07:11, 17 January 2013
Line 82:		Line 82:

	Grouping object, which can contain templates or other template groups, in a form of template tree.		Grouping object, which can contain templates or other template groups, in a form of template tree.

			== Report ==

			Creates a PDF document from data stored in database and a jasper report file controlling structure and formatting of the output. Example of jasper file can be downloaded from https://svn.netxms.org/public/netxms/trunk/reports/IP%20Inventory.jrxml. Jasper report file can be generated for example by [http://community.jaspersoft.com/project/ireport-designer iReport Designer].

			Report functionality is not enabled by default due to licensing restrictions. See [[How to compile report-generator]] for detailed instructions.

	= Object Status =		= Object Status =

Victor: /* Object Status */

2013-01-10T19:48:24Z

Object Status

← Older revision		Revision as of 19:48, 10 January 2013
Line 110:		Line 110:
	\|}		\|}

	For some object classes, like Report or Template, status is irrelevant. Status of such objects is always "Normal".		Status of the object calculated based on polling results, status of underlying objects, and associated alarms. For some object classes, like Report or Template, status is irrelevant. Status of such objects is always "Normal".

	= Access Control =		= Access Control =

Victor: /* Object Status */

2013-01-10T19:45:23Z

Object Status

← Older revision		Revision as of 19:45, 10 January 2013
Line 97:		Line 97:
	\| [[File:status_minor.png]] \|\| Minor \|\| Minor problem(s) exist for the object.		\| [[File:status_minor.png]] \|\| Minor \|\| Minor problem(s) exist for the object.
	\|-		\|-
	\| [[File:status_major.~~png~~]] \|\| Major \|\| Major problem(s) exist for the object.		\| [[File:status_major.gif]] \|\| Major \|\| Major problem(s) exist for the object.
	\|-		\|-
	\| [[File:status_critical.png]] \|\| Critical \|\| Critical problem(s) exist for the object.		\| [[File:status_critical.png]] \|\| Critical \|\| Critical problem(s) exist for the object.

Victor: /* Object Status */

2013-01-10T19:43:44Z

Object Status

← Older revision		Revision as of 19:43, 10 January 2013
Line 91:		Line 91:
	! Icon !! Text !! Description		! Icon !! Text !! Description
	\|-		\|-
	\| ~~Example~~ \|\| Normal \|\| Object is in normal state.		\| [[File:status_normal.png]] \|\| Normal \|\| Object is in normal state.
	\|-		\|-
	\| ~~Example~~ \|\| Warning \|\| Warning(s) exist for the object.		\| [[File:status_warning.png]] \|\| Warning \|\| Warning(s) exist for the object.
	\|-		\|-
	\| ~~Example~~ \|\| Minor \|\| Minor problem(s) exist for the object.		\| [[File:status_minor.png]] \|\| Minor \|\| Minor problem(s) exist for the object.
	\|-		\|-
	\| ~~Example~~ \|\| Major \|\| Major problem(s) exist for the object.		\| [[File:status_major.png]] \|\| Major \|\| Major problem(s) exist for the object.
	\|-		\|-
	\| ~~Example~~ \|\| Critical \|\| Critical problem(s) exist for the object.		\| [[File:status_critical.png]] \|\| Critical \|\| Critical problem(s) exist for the object.
	\|-		\|-
	\| ~~Example~~ \|\| Unknown \|\| Object's status is unknown to the mamngement server.		\| [[File:status_unknown.png]] \|\| Unknown \|\| Object's status is unknown to the mamngement server.
	\|-		\|-
	\| ~~Example~~ \|\| Unmanaged \|\| Object is set to "unmanaged" state.		\| [[File:status_unmanaged.png]] \|\| Unmanaged \|\| Object is set to "unmanaged" state.
	\|-		\|-
	\| ~~Example~~ \|\| Disabled \|\| Object is administratively disabled (only applicable to interface objects).		\| [[File:status_disabled.png]] \|\| Disabled \|\| Object is administratively disabled (only applicable to interface objects).
	\|-		\|-
	\| ~~Example~~ \|\| Testing \|\| Object is in testing state (only applicable to interface objects).		\| [[File:status_testing.png]] \|\| Testing \|\| Object is in testing state (only applicable to interface objects).
	\|}		\|}

Victor: /* Object Status */

2013-01-10T19:36:43Z

Object Status

← Older revision		Revision as of 19:36, 10 January 2013
Line 84:		Line 84:

	= Object Status =		= Object Status =

			Each object has a status. Object's status can be one of the following:

			{\| class="wikitable"
			\|-
			! Icon !! Text !! Description
			\|-
			\| Example \|\| Normal \|\| Object is in normal state.
			\|-
			\| Example \|\| Warning \|\| Warning(s) exist for the object.
			\|-
			\| Example \|\| Minor \|\| Minor problem(s) exist for the object.
			\|-
			\| Example \|\| Major \|\| Major problem(s) exist for the object.
			\|-
			\| Example \|\| Critical \|\| Critical problem(s) exist for the object.
			\|-
			\| Example \|\| Unknown \|\| Object's status is unknown to the mamngement server.
			\|-
			\| Example \|\| Unmanaged \|\| Object is set to "unmanaged" state.
			\|-
			\| Example \|\| Disabled \|\| Object is administratively disabled (only applicable to interface objects).
			\|-
			\| Example \|\| Testing \|\| Object is in testing state (only applicable to interface objects).
			\|}

			For some object classes, like Report or Template, status is irrelevant. Status of such objects is always "Normal".

	= Access Control =		= Access Control =

Victor at 19:29, 10 January 2013

2013-01-10T19:29:17Z

← Older revision		Revision as of 19:29, 10 January 2013
Line 4:		Line 4:
	{{Objects}}		{{Objects}}

	= Top Level Objects =		= Object Classes =

			== Top Level Objects ==

	NetXMS has eight top level objects – '''Entire Network''', '''Service Root''', '''Template Root''', '''Policy Root''', '''Network Map Root''', '''Dashboard Root''', '''Report Root''', and '''Business Service Root'''. These objects served as an abstract root for appropriate object tree. The following table represents possible child object classes for top level objects:		NetXMS has eight top level objects – '''Entire Network''', '''Service Root''', '''Template Root''', '''Policy Root''', '''Network Map Root''', '''Dashboard Root''', '''Report Root''', and '''Business Service Root'''. These objects served as an abstract root for appropriate object tree. The following table represents possible child object classes for top level objects:
Line 46:		Line 48:
	All top level objects has only one editable attribute – object's name.		All top level objects has only one editable attribute – object's name.

	= Subnet ~~Objects~~ =		== Subnet ==
	Subnet objects represent IP subnets. These objects created automatically by NetXMS server to represent known IP topology. Subnet objects can only contain node objects. The system places node objects inside an appropriate subnet object based on an interface configuration. Subnet objects have only one editable attribute – an object's name.		Subnet objects represent IP subnets. These objects created automatically by NetXMS server to represent known IP topology. Subnet objects can only contain node objects. The system places node objects inside an appropriate subnet object based on an interface configuration. Subnet objects have only one editable attribute – an object's name.

	= Container ~~Objects~~ =		== Container ==
	Container objects (or simply ''containers'') serve as building blocks for creating logical service hierarchy. Containers can have subnets, nodes, conditions, or other containers as child objects. Containers can be created in '''Infrastructure Services''' tree. Existing nodes and subnets can be added to containers by using '''Bind''' operation, and removed by using '''Unbind''' operation.		Container objects (or simply ''containers'') serve as building blocks for creating logical service hierarchy. Containers can have subnets, nodes, conditions, or other containers as child objects. Containers can be created in '''Infrastructure Services''' tree. Existing nodes and subnets can be added to containers by using '''Bind''' operation, and removed by using '''Unbind''' operation.

	= Condition ~~Objects~~ =		== Condition ==

	Conditions may represent more complicated status checks because each condition can have a script attached. Interval for evaluation of condition status is configured in [[Server Configuration Variables]] as ConditionPollingInterval with default value 60 seconds. Input values for the condition script can be added in the Data tab. Such values are accessible via $1, $2, ... variables inside the script. If the script returns 0, an activation event with the defined severity is created. If the script returns any other value, then a deactivation event is created.		Conditions may represent more complicated status checks because each condition can have a script attached. Interval for evaluation of condition status is configured in [[Server Configuration Variables]] as ConditionPollingInterval with default value 60 seconds. Input values for the condition script can be added in the Data tab. Such values are accessible via $1, $2, ... variables inside the script. If the script returns 0, an activation event with the defined severity is created. If the script returns any other value, then a deactivation event is created.

	= Node ~~Objects~~ =		== Node ==

	Node objects (or ''nodes'') represent computers and other network-enabled devices (such as routers and switches) in your network. They have a lot of attributes controlling all aspects of interaction between NetXMS server and managed node. For example, the attributes specify what data must be collected, how node status must be checked, which protocol versions to use etc. Node objects contain one or more interface objects. The system creates interface objects automatically during configuration polls.		Node objects (or ''nodes'') represent computers and other network-enabled devices (such as routers and switches) in your network. They have a lot of attributes controlling all aspects of interaction between NetXMS server and managed node. For example, the attributes specify what data must be collected, how node status must be checked, which protocol versions to use etc. Node objects contain one or more interface objects. The system creates interface objects automatically during configuration polls.

	= Interface ~~Objects~~ =		== Interface ==
	Interface objects represent network interfaces of managed computers and devices. Usually these objects created automatically by management server during configuration polls.		Interface objects represent network interfaces of managed computers and devices. Usually these objects created automatically by management server during configuration polls.

	= VPN Connector =		== VPN Connector ==

	VPN Connector objects are created manually. In case if there is a VPN connection linking two different networks open between two firewalls that are added to the system as objects, a user can create a VPN Connector object on each of the firewall objects and link one to another. The		VPN Connector objects are created manually. In case if there is a VPN connection linking two different networks open between two firewalls that are added to the system as objects, a user can create a VPN Connector object on each of the firewall objects and link one to another. The
	network topology will now show that those two networks are connected and the system will take this condition into account during problem analysis and event correlation.		network topology will now show that those two networks are connected and the system will take this condition into account during problem analysis and event correlation.

	= Network Service ~~Objects~~ =		== Network Service ==

	Network Service object is always created under a node and represents a network service (such as HTTP or SSH), which is accessible online (via TCP IP). Network Service objects are always created manually. When creating a new Network Service, a user has to set a protocol type for it.		Network Service object is always created under a node and represents a network service (such as HTTP or SSH), which is accessible online (via TCP IP). Network Service objects are always created manually. When creating a new Network Service, a user has to set a protocol type for it.
	Currently, the system works with the following protocols - HTTP, POP3, SMTP, Telnet, and SSH. In addition to that, it is also possible to define a Custom protocol type. For Custom protocol, a user should define the TCP port number and the system will be checking whether that port is available. For the predefined standard services the system will also check whether an appropriate response is returned. In case of SMTP, the system will send a test mail, in case of POP3 – try to log in with a certain user, in case of HTTP – check whether the contents of a desired web page correspond to a certain given template. As soon as the Network Service object is created, it will be automatically included into the status poll. Each time when the status poll for the particular node is carried out, all Network Service objects are polled for a reply. If an object's reply corresponds to a certain condition, its status is set as NORMAL. If an object is not responding, its status will be hanged to CRITICAL. For more information on object statuses and object status estimation, please refer to Object Status chapter.		Currently, the system works with the following protocols - HTTP, POP3, SMTP, Telnet, and SSH. In addition to that, it is also possible to define a Custom protocol type. For Custom protocol, a user should define the TCP port number and the system will be checking whether that port is available. For the predefined standard services the system will also check whether an appropriate response is returned. In case of SMTP, the system will send a test mail, in case of POP3 – try to log in with a certain user, in case of HTTP – check whether the contents of a desired web page correspond to a certain given template. As soon as the Network Service object is created, it will be automatically included into the status poll. Each time when the status poll for the particular node is carried out, all Network Service objects are polled for a reply. If an object's reply corresponds to a certain condition, its status is set as NORMAL. If an object is not responding, its status will be hanged to CRITICAL. For more information on object statuses and object status estimation, please refer to Object Status chapter.

	= Template ~~Objects~~ =		== Template ==

	Template object represents a template for data collection. For more information, please refer to [[UM:Data_Collection#Templates\|Templates]] chapter.		Template object represents a template for data collection. For more information, please refer to [[UM:Data_Collection#Templates\|Templates]] chapter.

	= Template Group =		== Template Group ==

	Grouping object, which can contain templates or other template groups, in a form of template tree.		Grouping object, which can contain templates or other template groups, in a form of template tree.

			= Object Status =

			= Access Control =

	= Custom Attributes =		= Custom Attributes =
	Every object can have custom attributes defined either by user or integrated application via NetXMS API. Custom attributes distinguished by names (an attribute name can contain up to 127 printable characters), and have string values of unlimited length. However, if you wish to access custom attributes in NXSL scripts as properties of node object, you should name them conforming to NXSL identifier naming constraints.		Every object can have custom attributes defined either by user or integrated application via NetXMS API. Custom attributes distinguished by names (an attribute name can contain up to 127 printable characters), and have string values of unlimited length. However, if you wish to access custom attributes in NXSL scripts as properties of node object, you should name them conforming to NXSL identifier naming constraints.
	To create or change value of custom attribute manually, right-click object in NetXMS console, select "Properties", then select "Custom Attributes" tab.		To create or change value of custom attribute manually, right-click object in NetXMS console, select "Properties", then select "Custom Attributes" tab.