Home

 

Use IBM Rational Performance Tester: Resource monitoring Part 4, Monitoring with IBM Tivoli Monitoring

 

+

Search Tips   |   Advanced Search

 

Components of IBM Tivoli Monitoring

 

Monitoring agents

Today, there are over one hundred ITM monitoring agents available from IBM and third-party software vendors. Each agent is responsible for data collection from systems, subsystems, or applications. The collected data is passed from the monitoring agents to the portal server through the monitoring server. An agent interacts with a single system or application and, in most cases, resides on the same computer where the system or application is running. There are two types of monitoring agents:

IBM Tivoli Monitoring also provides a customized agent called the Universal Agent. The Universal Agent can monitor any data that is collectable in a given environment. For example, the Universal Agent can monitor the status of your company website to ensure that it is available.

Agents run on z/OS, UNIX, Windows XP Professional Edition, Windows 2000, Windows 2003 Server, HP-UX however, not all agents are supported on all platforms.

Each agent has special metadata that describes itself. This metadata is required when integrating data collection into a custom client, such as Rational Performance Tester. Today, Performance Tester is capable of data collection from the following ITM Monitoring Agents:

 

Data collection

Retrieving data from ITM is accomplished by making Simple Object Access Protocol (SOAP) requests to the embedded SOAP server contained within the Tivoli Enterprise Monitoring Server. It is important to note that in the IBM Tivoli Monitoring documentation, the SOAP server is often referred to as a Web service, even though there is no Web Service Definition Language (WSDL) publicly published.

Once data is retrieved using SOAP requests, the well formed XML responses are transformed into the Eclipse Test and Performance Tools Platform (TPTP) statistical model format. This model format is based on the Eclipse Modeling Framework (EMF) and is designed as a generic method of storing and representing statistical data, despite which system or data collector the data points are observed from. The generic model format allows Performance Tester and other Eclipse-based views to render reports based on this data.

As each event (a statistical data point) is observed, it is transformed into a TPTP Statistical model event on-the-fly. This event is then loaded into the TPTP Data Loader, which persists the event and triggers any registered user interfaces to update based on this new event.

The integration between Performance Tester and IBM Tivoli Monitoring...


There are two mechanisms by which statistical data can be collected from ITM:

A SOAP request to the monitoring server consists of:

Here is a sample HTTP POST request that can be used to query ITM for some data.
Sample HTTP POST request

       
POST http://localhost:1920///kdsmain/soap HTTP/1.0
Accept: */*
Accept-Language: en-us
Referer: http://localhost:1920///kdsmain/soap/kshhsoap.htm
interfacename: CT_SOAP
messagetype: Call
Content-Type: text/xml
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
 .NET CLR 1.1.4322;.NET CLR 1.0.3705)    
Host: localhost:1920
Content-Length: 96
Pragma: no-cache

    <CT_Get><userid>sysadmin</userid><password></password>
    <object>Web_Applications</object></CT_Get>

 

Types of queries

In this section we list three types of queries.

 

Query monitor agents

Querying for monitoring agents that are available to the indicated monitoring server and collecting data:
Example monitoring agent query

       
<CT_Get><userid>sysadmin</userid><password></password>
    <object>ManagedSystem</object>
</CT_Get>

Example response
       
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body><SOAP-CHK:Success xmlns:SOAP-CHK = "http://soaptest1/soaptest/"
  xmlns="urn:candle-soap:attributes">
<TABLE name="O4SRV.INODESTS">
    <OBJECT>ManagedSystem</OBJECT>
    <DATA>
        <ROW>
        <Timestamp>1050620105552004</Timestamp>
        <Name>RDANEK:UA</Name>
        <Managing_System>HUB_RDANEK</Managing_System>
        <ORIGINNODE>RDANEK:UA</ORIGINNODE>
        <Reason>FA</Reason>
        <Status>*OFFLINE</Status>
        <Product>UM</Product>
        <Version>04.10.00</Version>
        <Type>V</Type>
        <HLOCFLAG>L</HLOCFLAG>
        <HHOSTINFO>WinXP~5.1-SP1</HHOSTINFO>
        <HHOSTLOC></HHOSTLOC>
        <CT_Host_Address>ip:#169.254.198.66[38213]
        &lt;NM&gt;RDANEK&lt;/NM&gt;</CT_Host_Address>
        </ROW>
    </DATA>
</TABLE>
</SOAP-CHK:Success></SOAP-ENV:Body></SOAP-ENV:Envelope>

The response is returned in a well-formed XML document structure. Now let us dissect the response:

 

Query recent data

Querying for recent data allows clients to retrieve the most recently acquired statistical data point by the monitoring server for a monitoring agent. This query would be used in the live monitoring scenario where periodically the statistical model is updated with new data points: 

<CT_Get><userid>sysadmin</userid><password></password>
    <target>Primary:RDANEK:NT</target>
    <object>NT_Process</object>
    <attribute>Thread_Count</attribute>
    <afilter>ID_Process;EQ;988</afilter>
</CT_Get>

This example query returns the value of thread count for the process with an identifier of 988.
Example data query response

       
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body><SOAP-CHK:Success xmlns:SOAP-CHK = "http://soaptest1/soaptest/"
         xmlns="urn:candle-soap:attributes">
    <TABLE name="KNT.WTPROCESS">
    <OBJECT>NT_Process</OBJECT>
        <DATA>
        <ROW>
        <Thread_Count dt="number">24</Thread_Count>
        </ROW>
        </DATA>
    </TABLE>
</SOAP-CHK:Success></SOAP-ENV:Body></SOAP-ENV:Envelope>

The response is returned in a well-formed XML document structure. Now let us dissect the response:

 

Query historical data

Querying for historical data allows the retrieval of statistical observations collected in the past for a monitoring agent. In order for this type of data collection to be enabled, historical data collection must have been configured for the desired monitoring agent through the monitoring server. The queries are identical to the preceding section except that we specify an additional tag in the query: <history>Y</history>: 

       
<CT_Get><userid>sysadmin</userid><password></password>
    <target>Primary:RDANEK:NT</target>
    <object>NT_Process</object>
    <attribute>Timestamp</attribute>
    <attribute>Thread_Count</attribute>
    <history>Y</history>
    <afilter>Timestamp;GE;1050620132400000</afilter>
</CT_Get>

This query will return the thread count for all observations after June 20th, 2005 at 1:24 PM. A filter is used to specify a timestamp in order to only retrieve the historical data for the time period that is of interest. Querying for historical data without a timestamp filter will result in the SOAP server returning all historical data and this can overwhelm the system resources.

The timestamp is of the format CYYMMDDHHMMSSmmm:


Example historical data response
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    > <SOAP-ENV:Body><SOAP-CHK:Success xmlns:SOAP-CHK =
     "http://soaptest1/soaptest/"xmlns="urn:candle-soap:attributes">
<TABLE name="KNT.WTPROCESS">
    <OBJECT>NT_Process</OBJECT>
    <DATA>
        <ROW>
        <Timestamp>1050620132453887</Timestamp>
        <Thread_Count dt="number">1</Thread_Count>
        </ROW>
        <ROW>
        <Timestamp>1050620132453887</Timestamp>
        <Thread_Count dt="number">64</Thread_Count>
        </ROW>
        <ROW>
        <Timestamp>1050620132453887</Timestamp>
        <Thread_Count dt="number">3</Thread_Count>
        </ROW>
    </DATA>
</TABLE>
</SOAP-CHK:Success></SOAP-ENV:Body></SOAP-ENV:Envelope>

 

Configuring a performance schedule

For further information on configuring resource monitoring using IBM Tivoli Monitoring, see Resource monitoring using IBM Rational Performance Tester: Part 1, Scheduling and reporting.

To configure resource monitoring using IBM Tivoli Monitoring, create a new or add an existing location to a given performance schedule.

Enter a target host name, where the ITM Monitoring Agent resides, from which to collect data from and select the IBM Tivoli Monitoring item from the list of available data sources (see Figure 3 in Part 1, Scheduling and reporting).

On the Tivoli Enterprise Monitoring Server tab, specify the monitoring server that you want to use to capture resource monitoring data as shownin Figure 4:

After you have specified the monitoring server, you can select resources to capture. If the host is not managed by the monitoring server, we will see an error message.


On the Resource tab, select the type of data that you want to capture, as shown in Figure 5. The tree view shows the host and all of its available IBM Tivoli Monitoring agents, and their respective counter groups and counters.


Clearing Show only selected counters allows us to see all available counters (Figure 6). Be selective; monitoring all possible resource data requires substantial amounts of memory. Hover over a counter with your mouse to see details about what that counter measures.


On the Options tab, the time interval properties can be configured (Figure 7):


Once configuration is complete and saved, the resource monitoring location will be added to the performance schedule (Figure 8).


 

Profiling for real-time observation

Performance Tester has the ability to collect from ITM monitoring agents, in real-time, without having to configure a resource location through a performance schedule. This capability is valuable for large enterprise environments where different machines are used for performance testing and system monitoring. In addition, even though this resource data is collected outside of a performance schedule, you can overlay these counters using the Performance Test Runs view of an existing Performance Tester Report.

To initiate real-time data collection from an ITM monitoring agent, select Run > Profile or use the toolbar button to open the launch configuration dialog (Figure 9). This profile action will ask us to switch into the Profile and Logging perspective of the Performance Tester product. This perspective enables profiling tools and has a different layout of the views on the workbench.


Resource monitoring configuration using the performance schedule is similar to configuring real-time monitoring (Figure 10). One difference is that you can specify where the collected data should be stored using the Destination tab. Clicking Profile after the tab pages have been completed will initiate data collection.


As data is collected from the selected ITM Monitoring Agents, it is plotted on a graph display (Figure 11). As each new data point is observed and received by the client, the point will be plotted. The graph display is available by right-clicking on the agent in the Profiling Monitor view. Figure 11 illustrates the trend between the network traffic, disk activity, and processor activity.


 

Importing data from IBM Tivoli Monitoring

IBM Tivoli Monitoring is a managed solution that store all observed monitoring data in a data warehouse. This architecture allows us to query ITM for historical data from a particular agent, if needed.

In the workbench client, you can import the data using two methods:

  1. An import wizard that is accessible by selecting File > Import (Figure 12).
  2. An import wizard that is accessible by right-clicking on a performance report in the Performance Test Runs view (Figure 13) or on the resources report, which is the last tab in the view.



Once the wizard is loaded, specify a resource location configured using the ITM data source (Figure 14).


From the three data collectors offered in Performance Tester, only ITM is capable of collecting historical data. If you try to add a resource location configured for any other data source the collection for these locations will be ignored during import and the user will be alerted (Figure 15).


The next stage of the import wizard is to specify the time period from which to import data (Figure 16). This can be specified as either the start and end times or as the amount of time you specify, counted backward from the time that you click Finish. You might need to adjust the time interval to compensate for clock discrepancies between the workbench and the monitoring server.

Note: When specifying the time in a specific number of units, note that, for consistency, month is defined as 30 days and year is defined as 365 days. Days refers to 24-hour periods, not calendar days. The units of time selected are subtracted from the point in time when you click Finish to import the data to give the start time. For example, if you select 2 months, the time period will be the 60 days (24-hour time periods) immediately prior to the point in time that you click Finish.


To import data from ITM, the ITM monitoring agent itself must be configured for historical data collection. If the agent is not properly configured, an error message will be displayed to the user when attempting the import, as shown in Figure 17.


After the import process has completed, the data is displayed in one of two ways, depending on how the import wizard was invoked:

  1. If the user invoked the wizard from the File > Import menu, this action indicates that there is no association to a performance result and the data is displayed using the default statistical view in the Profile and Logging perspective (Figure 18).
  2. If the user invoked the wizard by right-clicking on a performance result, this action indicates the imported data is associated to the selected performance result. The data can be viewed using the Resource tab in the default report when the performance result is opened. Alternatively, if you manually switch to the Profile and Logging perspective, you can view and analyze the data using the default statistical view in the Profile and Logging perspective.


 

Resources

Learn

Get products and technologies

Discuss