Understanding Web Response Time transaction tracking and TCP tracking

The transaction tracking function of the Web Response Time monitoring agent was introduced in ITCAM for Transactions version 7.2.0.1. This function provides agent-based tracking that is correlated with other agent-based tracking data and displayed in the server, component, application, and transaction workspaces in the Transaction Reporter.

Using this function, you can see which HTTP and HTTPS applications and transactions are communicating with various other components in the monitored transaction flow. This tracking is based on individual transaction instances using Transaction Tracking API calls to the Transaction Tracking data collector. Using this instance-based data, you can examine tracking data and topologies for individual transaction instances.

The Web Response Time TCP tracking feature provided with ITCAM for Transactions V7.3 enables you to monitor the TCP interactions in your network environment. Using this function, you can quickly visualize the TCP-based application protocols and dependencies present in your IT infrastructure along with the performance characteristics of these interactions. Agentless transaction tracking provides more general tracking that is not based on individual transaction instances, but on aggregate data that is retrieved directly by the Transaction Reporter. This data is independent of the protocol over TCP which provides a broader range scope of interactions between computers. The data is not correlated directly to other agent-based data, but the agentless data can be displayed with (and linked to) other agent-based server data if the host and port information match.

This TCP tracking feature is not meant to replace the transaction tracking function, but to offer another method of tracking your transactions in the Web Response Time monitoring environment. If you are interested in application or transaction level tracking of your HTTP data, use the transaction tracking function. If you are looking for more generic TCP flow level tracking, use the TCP tracking feature.

How TCP tracking works

The collection of this TCP data occurs on the Web Response Time agent, and is disabled by default. After enabling the collection of TCP data on the Web Response Time agent, data is collected according to the filters and reporting properties of the Component definitions in the Application Management Configuration Editor. Collected data can be viewed in a set of TCP-centric Tivoli Enterprise Portal workspaces, accessed from the Network node of the monitoring Web Response Time agent. The Transaction Reporter also includes consolidated workspaces for examining this TCP data, including topology views for displaying these TCP interactions across the entire set of Web Response Time agents in your environment.

Web Response Time agent configuration settings

Several agent configuration options are provided for the Web Response Time agent to enable and customize the way TCP data is collected and monitored:
  • Enabling TCP Monitoring: To enable TCP monitoring on a Web Response Time agent, select the Monitor All TCP Traffic option in the agent configuration panel, as shown in the following example:
    Web Response Time monitoring Basic configuration, selecting Monitor All TCP Traffic option
  • Network Mask Exclusion: The Advanced Configuration portion of Web Response Time agent configuration includes an option for excluding TCP data from being monitored by the agent. Specify this exclusion with a list of IPv4 address mask entries for which TCP data is ignored. This exclusion occurs at the network traffic capture layer, so the exclusion list affects both TCP and HTTP data collection.
    There are two main reasons why you might want to use this network mask exclusion property:
    • There might be a large amount of extraneous traffic visible on the device for which monitoring is not necessary, for example, when receiving packets from a switch with port spanning enabled. Large amounts of extra traffic can cause performance degradation in the agent processing. Excluding this data at the network level through the use of the exclusion mask setting prevents this unnecessary data from entering the processing flow of the agent.
    • You might need more than one Web Response Time agent to monitor all of the required TCP traffic in your environment. In this situation, if the same network data is visible on two different Web Response Time agents that are monitoring TCP traffic, use the exclude field to ensure that the duplicate traffic is only monitored once. For example, if one Web Response Time agent is monitoring TCP traffic on subnet 9.48.152.*, and another agent is monitoring traffic on 9.48.142.*, any traffic going between the 9.48.152.* and 9.48.142.* subnets is visible on both Web Response Time agents. However, if the agent on subnet 9.48.142.* uses the exclude mask 9.48.152.*, the agent is prevented from monitoring the traffic between the two network segments, and monitoring of this traffic is the sole responsibility of the other Web Response Time agent.
    This configuration setting is shown in the following example:
    Web Response Time monitoring Advanced configuration, specifying a network mask for excluding TCP traffic.
  • Monitoring remote network traffic: The optionsMonitor Remote HTTP server and Monitor remote HTTPS server available in previous releases have been replaced by the more generic Monitor remote network traffic option, as shown in the previous example. This option specifies that all traffic on the NIC can be monitored, regardless of the source and destination IP addresses. If you do not select this configuration option, only the traffic with the IP address of the NIC as the source or destination is monitored. This option is implemented at the packet capture layer of the product and affects the collection of TCP, HTTP, and HTTPS data.
  • Specifying server masks: Specify an IP address or IP address mask in the Server masks for TCP data field to identify remote computers as servers. Those servers are then displayed as expected in the resulting TCP topology. If you do not identify servers, traffic associated with that server is bundled in a client group with other client traffic. Identify servers if two or more Web Response Time agents are being used to monitor and visualize a complete segment of a TCP topology. To recognize a computer in your monitored environment as an independent server, the Web Response Time agent must be able to see traffic coming into the server and recognize that traffic as belonging to the set for which monitoring has been enabled by the user. However, in an environment where there are two or more agents monitoring the traffic, one of the agents might be able to see only outbound traffic from a server on a different network segment. This configuration can result in multiple, disjoint TCP topologies being displayed in Tivoli Enterprise Portal workspaces, instead of one complete topology.
    Web Response Time monitoring Advanced configuration, specifying a server mask for TCP traffic.

For more information about configuring the Web Response Time agent, see Chapter 6 in the Installation and Configuration Guide.

Application Management Configuration Editor settings

In ITCAM for Transactions V7.3 and later, the term Component is used to represent a process within the IT environment that accepts requests on one or more TCP ports on its host computer. The Application Management Configuration Editor includes the Components dialog, which you can use to define and customize component definitions that specify the way that TCP data is monitored and reported in ITCAM for Transactions. Many default component monitoring configurations are provided for common components such as HTTP Servers and LDAP Servers. You can use these defaults without further changes, customize them to reflect the TCP traffic in your environment, or create new component definitions for other TCP services of interest within your network environment.

The Application Management Configuration Editor includes the following settings for monitoring TCP traffic:
  • Defining components: After selecting Components from the Application Management Configuration Editor navigation selection menu, you are presented with the current list of component definitions within the system. From here, you can create a new component definition or select an existing definition for modification. Because of complexities and possible overlap of the internal component configuration, the Create Another Component function is disabled within the Components dialog box. If you create a new component, you are directed to the Create Component definition panel, where you can name and the component (for example, IBM HTTP Server), and provide a text description.
  • Defining component protocols: After selecting or defining your component definition, you select the Protocols tab to specify the different protocols that are used by the monitoring component. This dialog box shows the list of protocols for the component, each consisting of a name, an IP address mask representing the computers using the protocol, and a list of TCP ports used by the protocol. Use this dialog box to create, delete, or modify existing protocols. When adding or editing a protocol, you are presented with a dialog box to enter or modify the properties for each defined protocol:
    Name
    The display name of the protocol used in the Web Response Time agent workspaces, and in the transaction tracking TCP topology. You can enter this name directly or select an existing name from a list. Selecting an existing name does not populate IP Address or Ports fields.
    IP Address
    An IP address or IP address mask that defines one or more computers that are hosting the protocol. Wildcard characters are accepted, including asterisk (*).
    Ports
    A comma-separated list that defines the TCP ports used by this protocol.
  • Defining reporting properties: As part of defining your component, you select the Reporting tab to modify the Application Management Configuration Editor reporting properties associated with the component. Use this dialog to edit the component name and server name that is displayed in the Web Response Time workspaces and the Transaction Tracking topology views. Similar to other Application Management Configuration Editor reporting properties, there are multiple TCP properties that you can use in these definitions (for example, the default server reporting name $ShortHost$, which resolves to the short DNS host name for the server that runs the component).

See Creating a component for more information about creating components, protocols, and reporting options for monitoring TCP traffic.

Web Response Time workspaces for TCP monitoring

The Web Response Time agent provides various workspaces for viewing collected TCP data. These workspaces provide many different contexts of monitored TCP data, from client and server level to network component and protocol level. By navigating these multiple levels of TCP traffic in the workspaces, you can identify TCP performance characteristics and possible bottlenecks in your network environment.

The following workspaces are included in ITCAM for Transactions to view TCP monitoring data:

These workspaces are described in the User's Guide.