Using subnodes

You can use subnodes to monitor multiple application components from a single agent instance.

You can build a single agent that accomplishes the following tasks by using subnodes:

Monitors each instance of a software server that is running on a system instead of having to use separate instances of the agent, one per software server instance.
Monitors several different remote systems instead of having to use separate instances of the agent, one for each remote system.
Monitors several different types of resources from one agent instead of having to build and deploy several different agents.
In IBM® Tivoli® Monitoring, displays an additional level in the Tivoli Enterprise Portal physical Navigation tree that allows further grouping and customization. Moreover, you can define Managed System Groups for another level of granularity with situations.
In IBM Cloud Application Performance Management, provides several different resources, displaying different summary and detail dashboards. Subnode resources can be displayed as peers or subcomponents of the agent resource. You can include these resources in applications independently.

You can create subnode types in Agent Builder. Each type must correspond to a different type of resource that an agent can monitor. Add data sources and data sets to the subnode type for a particular monitored resource.

When you deploy the agent on a monitored host and configure it, you can create one or more instances of each subnode type. Each instance of a subnode must correspond to an instance of a server, a remote system, or whatever resource the subnode type was designed to monitor. All subnode instances of a single subnode type have attribute groups and workspaces that have an identical form. However, each subnode instance has data that comes from the particular resource that is being monitored.

When you configure the agent on the monitored host, you can determine the number of subnode instances. Some configuration data can apply to the agent as a whole, but other configuration data applies to a single subnode instance. Configure each subnode instance differently from the other subnode instances so that they do not monitor the exact same resource and display the exact same data.

In an IBM Tivoli Monitoring environment, a subnode instance is displayed within the agent in the Navigation Physical view in the Tivoli Enterprise Portal. Workspaces display the data that is produced by a subnode instance and situations can be distributed to one or more instances of a subnode. A managed system list is automatically created that contains all instances of the subnode, just like the Managed System List that is created for an agent.

In an IBM Cloud Application Performance Management environment, you can display both agent and subnode instances as monitored resources. Each subnode instance becomes a separate resource. For details, see Subnodes in IBM Cloud Application Performance Management.

Because agents built with Agent Builder create the subnode instances that are based on configuration values, these subnodes have the same life span as the agent. There is still just one heartbeat that is done for the agent, not a separate heartbeat for each subnode. Therefore, by using subnodes you can significantly increase the potential scale of the monitoring environment. The alternative is to use multiple agent instances, which can limit the potential scale of the IBM Tivoli Monitoring or IBM Cloud Application Performance Management environment.

Adding or removing a subnode requires reconfiguring the agent. To reconfigure the agent, you need to stop and restart it, involving all subnodes. You can define the agent as a multi-instance agent; in this case, you can start and stop a single instance, and leave the other instances running.

Along with data sets in subnodes, an agent can define agent-level data sets that are located outside of a subnode.

In the Tivoli Enterprise Portal Navigator tree, a subnode type is displayed under the agent name, and subnode instances are displayed under a subnode type. Subnodes are identified by a Managed System Name (MSN) just like agents, for example 94:Hill.cmn.

For example, in the Navigator tree in Figure 1, Watching Over Our Friends is an agent with three resources (Boarders, Common Areas, and Kennel Runs) and two subnode types (Common Area and Kennel Run). Two of these resources have subnode types that are defined for them (Common Area and Kennel Run). A subnode is not required for the third resource (Boarder), which is represented by a single row in a table at the base agent level. The Common Area subnode type has three subnode instances: 94:Hill:cmn, 94:Meadow:cmn, and 94:Tree:cmn representing three common areas in the kennel. The Kennel Run subnode type has four subnode instances: 94:system1:run, 94:system2:run, 94:system4:run, and 94:system5:run representing four kennel runs.

Navigator tree with Kennel Run subnode selected — Figure 1. Subnodes in the Navigator tree

There are two ways that a single agent can use subnodes:

The agent can have different subnodes of the same type.
The agent can have subnodes of different types.

Subnodes for the same data from different sources

You can use subnodes of the same type to represent multiple instances of a monitored resource type. Each subnode of the same type includes the same attribute groups and the correct values for the specific monitored resource instance. The number of subnodes varies based on agent configuration. The example in Figure 2 shows the monitoring of different systems.

Navigator tree with multiple subnodes monitoring each system within the Kennel Run group — Figure 2. Subnodes monitoring different systems

Subnodes for multiple types of data

When one agent monitors multiple types of monitored resources, you can create a subnode type for each of the resource types. Each subnode includes the information that is defined in that subnode type. The following example shows two subnode types. Each type is monitoring a different type of resource, with different types of data available for each resource:

Common Area
Kennel Run

The agent in Figure 3 runs one copy of each subnode type. A particular agent might create any subset of the defined agents. Subnodes can be used to mimic Tivoli Monitoring V5 profiles.

Navigator tree with multiple subnodes monitoring the system in the Common Area group — Figure 3. Subnode types in Navigator tree

Both ways of using subnodes can be used in the same agent, where each type can have more than one subnode instance.

Figure 3shows two types of subnodes that monitor two types of resources: Common Areas and Kennel Runs. In addition, there are several subnodes that are defined for each type. There are three subnodes of type Common Area; these subnodes have the following IDs: Meadow, Hill, and Tree. There are also four subnodes of type Kennel (each collecting data from a different system that is dedicated to a Kennel Run); these subnodes have the following IDs: system1, system2, system4, and system5.

Note: The first 24 characters of subnode IDs must be unique for all instances of the subnode type in the IBM Tivoli Monitoring installation.

Data Providers in subnodes

A subnode can contain any mixture of data from the different data provider types. Most current Agent Builder data providers can be used in a subnode, including the following data providers:

WMI
Perfmon
Windows Event Log
SNMP
SNMP Events
JMX
ICMP ping
Script
Log
CIM
JDBC
HTTP
SOAP
Socket
Java™ API

A subnode can also contain a joined attribute group that combines data from two other attribute groups from the same subnode or from agent-level attribute groups.

Status of subnodes

There are two ways to determine status for a subnode agent. The first way is to look at the data that is displayed in the Performance Object Status attribute group. This attribute group displays the status for each of the other attribute groups at the same level in the agent. The Performance Object Status attribute group at the agent level displays the collection status for the other attribute groups at the agent level. The Performance Object Status attribute group in each subnode displays the collection status for the attribute groups in that subnode.

Agent Builder also creates one attribute group for each subnode type, which displays one row for each configured subnode of that type. In the example in (Figure 4), four subnodes are running to collect data.

Data Collection window that displays the Navigator Tree and a report of activities of the selected subnode — Figure 4. Monitoring multiple subnode instances of the same subnode type

In the IBM Tivoli Monitoring environment, the Performance Object Status subnode contains data visible in the Navigator tree and can have situations that monitor the status of the other data collections.

In the IBM Cloud Application Performance Management environment, you can create thresholds to monitor Performance Object Status data.

The example in Figure 5 shows a case where the data collection failed (the script shell command was not found). Typically, any value other than NO_ERROR indicates that there is a problem. For each of the data collectors that are defined in the subnode, there is one row in the table.

Data Collection window with an OBJECT NOT FOUND error that is displayed in the Report section. — Figure 5. Example: data collection in a subnode

Subnodes in IBM Cloud Application Performance Management

In IBM Cloud Application Performance Management, you can define either the agent instance or a subnode instance or both as monitored resources, and each resource corresponds to a summary dashboard.

Subnode dashboards can not display agent-level data. To display agent-level data in this environment, define a summary dashboard for the agent.

Depending on the settings you select, agent and subnode resources can appear at the same level, with no hierarchical distinction, or subnode resources can be listed as children to agent resources.

For instuctions about configuring agent and subnode resources, see Preparing the agent for Cloud APM.