'); $("#tabs").tabs({ selected: 1 }); $("#ic-homepage__ic-tips").append( quickTipHTML() ); unhideOneProductTip(); $("#ic-homepage__product-tips").wrapInner('
'); $("#ic-homepage__feed-tips").wrapInner('
'); });
IBM Tivoli Monitoring > Version 6.3 > User's Guides > Agent Builder User's Guide > Create a basic agent > Create and defining the agent > Organizing the agent IBM Tivoli Monitoring, Version 6.3
Subnodes
Use subnodes to monitor multiple applications from a single agent instance.
You can build a single agent that accomplishes the following tasks by using subnodes:
- Monitors each instance of an application that is running on a system instead of having to use separate instances of the agent, one per application 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 entities from one agent instead of having to build and deploy several different agents.
- Displays an additional level in the Tivoli Enterprise Portal physical Navigation tree that allows further grouping and customization.
- Defines further Managed System Lists allowing another level of granularity with situations.
An agent developer defines subnode types in the Agent Builder. Each type must correspond to a different type of entity that an agent can monitor. Attribute groups and attributes are added to the subnode type that describes the entity that is being monitored. When the agent is deployed and configured, one or more instances of each subnode type can be created. Each instance of a subnode must correspond to an instance of an application, a remote system, or whatever entity 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 has data that comes from the particular entity that is being monitored.
The number of subnodes of each type is determined when the agent is configured. Some configuration data can apply to the agent as a whole, but other configuration data applies to only a single subnode. Configure each subnode differently from the other subnodes so that they do not monitor the exact same entity and display the exact same data.
A subnode is displayed within the agent in the physical Navigation tree in the Tivoli Enterprise Portal. Workspaces display the data that is defined by a subnode 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.
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. Use subnodes to define monitoring for a number of systems or application instances and you can significantly increase the potential scale of the Tivoli Monitoring environment. The alternative is to use multiple agent instances, which can limit the potential scale of the Tivoli Monitoring environment.
Add or removing a subnode requires reconfiguring the agent, which involves stopping and restarting it. For this reason, it can be good practice to define the agent as a multi-instance agent as well. By defining the agent as a multi-instance agent, you can manage portions of your environment separately.
Along with attribute groups in subnodes, an agent can define agent-level attribute groups 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 entities (Boarders, Common Areas, and Kennel Runs), and two subnode types (Common Area and Kennel Run). Two of these entities have subnode types that are defined for them (Common Area and Kennel Run). A subnode is not required for the third entity (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.
Figure 1. Subnodes in the Navigator tree
Parent topic:
Organizing the agent