Difference between revisions of "UM:Objects"

Jump to navigation Jump to search
Line 106: Line 106:


= Container Objects =
= Container Objects =
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 '''All 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.


= Node Objects =
= Node Objects =
Line 113: Line 113:
= Interface Objects =
= Interface Objects =
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 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 Service Objects =
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.
= Template Objects =
Template object represents a template for data collection. For more information, please refer to [[UM:Data_Collection#Templates|Templates]] chapter.
= Template Group =
Grouping object, which can contain templates or other template groups, in a form of template tree.


= 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.