3.1.1 ITSLM's monitoring methods and types of monitored targets

(1) Monitoring all Web accesses (All Web Access monitoring)

This method monitors all Web accesses to monitored services. When this method is used, All Web Access is displayed as the monitored target in the window.

The following figure shows the monitored target range when all Web accesses are monitored.

Figure 3‒1: Range of monitored target when all Web accesses are monitored

In this example, Web accesses 1 through 3 have occurred from the service user to monitored services. With this monitoring method, the averages or the totals of Web accesses 1 through 3 constitute the service performance of the monitoring items.

To Page Top

(2) Monitoring items for All Web Access

The following shows the relationship among the three monitoring items when monitoring of All Web Access is performed.

Figure 3‒2: Relationship among monitoring items (for All Web Access)

• Average response time (milliseconds)

  This is the average time required for 1 through 3 in the figure to be completed. Responses include error responses.^#

• Throughput (per second)

  This is a count of the number of times 1 through 3 in the figure occurred in one second. Responses include error responses.^# Note that requests resulting in a timeout during request collection by ITSLM - UR are not included. Each set of the events identified as 1 through 3 is counted as one when the set is completed.

• Error rate (%)

  This is the percentage of the event 1 items in the figure that end up as event 3 error responses^# or as timeouts during request collection by ITSLM - UR.

#

These are the responses whose HTTP status is error 400 to 599.

The HTTP packets for requests and responses are collected by ITSLM - UR when they pass the switch.

To Page Top

(3) Monitoring specific Web accesses (Web transaction monitoring)

Among all Web accesses to the monitored services, this method monitors only those Web accesses that constitute a series of processes that satisfy a specified condition. Such a series of processes that is subject to monitoring is called a Web transaction. Because this method enables you to determine the status of specific processes contained in a monitored service individually, you can promptly identify a process that might adversely affect service performance. You can set multiple Web transactions for a single monitored service. A condition for identifying the Web accesses to be treated as a Web transaction is called a Web access condition.

You can monitor Web transactions if your ITSLM - Manager and ITSLM - UR versions are 09-51 or later.

The following figure illustrates the range of a monitored target when specific Web accesses are monitored.

Figure 3‒3: Range of monitored target when specific Web accesses are monitored

In this example, Web accesses 1 through 5 have occurred from the service user to the monitored service. Whenever Web accesses 1 through 3 all satisfy a pre-registered Web access condition, that series of Web accesses is monitored as a Web transaction.

In the monitoring of a Web transaction, the average or the total of the results of monitoring the transmissions of the first request (1 in the figure) through the last response (3 in the figure) of the Web transaction constitutes the monitoring item's service performance.

ITSLM monitors only those Web accesses that occur in an order specified for the Web access condition. A Web access whose order of occurrence is undetermined cannot be included in a Web transaction.

Whether Web accesses are included in a target Web transaction is determined as follows:

1. Each time a Web access occurs, whether that Web access satisfies a Web access condition is checked in the order of the Web access conditions.

   When a Web access that satisfies the first Web access condition is detected, any subsequent Web access is checked to determine whether it satisfies the second Web access condition.

   Note that once a Web access satisfies one of the Web access conditions, it is no longer checked against any subsequent Web access conditions. For example, a Web access satisfying the first Web access condition is treated as satisfying only the first Web access condition even if it would also satisfy the second Web access condition.

2. When a Web access satisfying the last Web access condition is detected, the series of Web accesses is identified as a Web transaction.

If another Web access satisfying the first Web access condition is detected in the same Web transaction before a Web access satisfying the last Web access condition is detected, the current check processing is placed in the status in which a Web access satisfying only the first Web access condition has been detected.

Examples are shown below. For these examples, the Web access conditions for a Web transaction are set in the order of Web access condition 1 Web access condition 2 Web access condition 3.

Example of Web accesses that are treated as a Web transaction

• Web accesses that occurred in the order of Web access 1 Web access 2 Web access 3

• Web accesses that occurred in the order of Web access 1 Web access 2 Web access 4 Web access 3 (Web access 4 is not used in the calculation of the error rate monitoring item for the Web transaction)

• Web accesses that occurred in the order of Web access 1 Web access 2 Web access 2 Web access 3 (the second Web access 2 is not used in the calculation of the error rate monitoring item for the Web transaction)

Examples of Web accesses that are not treated as a Web transaction

• Web accesses that occurred in the order of Web access 1 Web access 2 Web access 1 Web access 3

  In this case, when the second Web access 1 was detected, the existing record for the order Web access 1 Web access 2 was discarded. The subsequent Web accesses are not treated as a Web transaction because they occurred in the order of Web access 1 Web access 3.

• Web accesses that occurred in the order of Web access 1 Web access 2 Web access 3 Web access 3

  The same Web access cannot be monitored more than once in the same Web transaction. Monitor this example as Web access 1 Web access 2 Web access 3. Note that the Web accesses that can be monitored are Web access 1 Web access 2 Web access 3 (first one). Web access 1 Web access 2 Web access 3 (second one) cannot be monitored.

To Page Top

(4) Components of a Web access condition for a Web transaction

A web access condition consists of the URI and cookie contained in the Web access. For a URI, only path and query information can be specified as Web access condition components.

The following examples illustrate the structure of a URI and cookie contained in a Web access.

URI

http://host:port/path?query

• Example 1: http://hitachi.XXX:1234/YYY/ZZZ.html

• Example 2: http://hitachi.XXX?division=1&section=2

Cookie

key=value

• Example 1: year=2011

• Example 2: month=08

A Web access satisfying the specified Web access condition becomes a Web transaction. If multiple Web access conditions are specified, the set of Web accesses that satisfy all the specified Web access conditions becomes a Web transaction.

If multiple Web accesses satisfy the same Web access condition, they are treated as being the same Web transaction.

Suppose Web transaction X is defined as follows:

Definition of Web transaction X

• Web accesses are to occur in the order of Web access 1 Web access 2 Web access 3.

• The Web access conditions are defined as follows:

  Web access condition	Path	Query condition	Cookie condition
  Web access condition 1	/top.html	a=1	Not specified.
  Web access condition 2	/middle.html	b=.*	Not specified.
  Web access condition 3	/bottom.html	c=3	Not specified.

Combinations of Web accesses monitored as Web transaction X

Both of the following combinations of Web accesses are monitored as Web transaction X:

• Web accesses occurring in the order of path:/top.html query:a=1, path:/middle.html query:b=2, and path:/bottom.html query:c=3

• Web accesses occurring in the order of path:/top.html query:a=1, path:/middle.html query:b=4, and path:/bottom.html query:c=3

To Page Top

(5) Monitoring items for Web transactions

The following figure shows the relationship among three monitoring items when Web transactions are monitored.

Figure 3‒4: Relationship among monitoring items (for Web transactions)

• Average response time (milliseconds)

  This is the average time required for the last Web access (2 in the figure) of the Web transaction to be sent as a response since the first Web access (1 in the figure) was sent as a request. Responses include error responses.^#

• Throughput (per second)

  This is the number of times 1 through 2 occurred in one second, beginning with transmission of the first Web access (1 in the figure) of the Web transaction as a request through the last Web access (2 in the figure) as a response. Responses include error responses.^# Note that requests resulting in a timeout during request collection by ITSLM - UR are not included. From the transmission of the first Web access (1 in the figure) of the Web transaction as a request through the transmission of the last Web access (2 in the figure) as a response is counted as one when the set is completed.

• Error rate (%)

  This is the percentage of the number of Web accesses (1 to 2 in the figure) in the Web transaction sent as requests that ended up as error responses^# or as timeouts during request collection by ITSLM - UR.

#

These are the responses whose HTTP status is error 400 to 599.

The HTTP packets for requests and responses are collected by ITSLM - UR when they pass the switch.

To Page Top

(6) Monitoring system performance (by linking with Performance Management)

If you link your ITSLM with Performance Management, you can monitor system performance.

System performance is monitored based on performance data collected for each Performance Management monitoring agent assigned to a monitored service. Each monitoring agent that collects data is displayed in the ITSLM window at a separate hierarchical level and the results are reported by hierarchical level.

To Page Top

(7) Monitoring items for system performance

There are two types of monitoring items for system performance:

• Default monitoring items provided by Performance Management

• Monitoring items defined by the user of Performance Management

ITSLM enables you to monitor both types of monitoring items together.

For details about the monitoring items for system performance, see the description of monitoring items in the Job Management Partner 1/Performance Management User's Guide.

System performance data is collected in units called records. There are two types of records depending on the monitoring item:

• Single-instance records

• Multi-instance records

Single-instance records

A single-instance record consists of one row of data that is collected at a single point of data collection.

The following shows an example of single-instance records:

Each row (record) contains performance data for a specific time. This record stores performance data, such as the CPU usage and memory usage at the monitored host.

Multi-instance record

A multi-instance record consists of multiple rows of data that are collected at a single point of data collection.

The following shows an example of multi-instance records:

This example collects performance data for drives C and D in separate rows at each collection time. Therefore, to search for specific performance data at a particular time, you must specify both the collection time and the drive.

For details about instance records, see the description of performance data in the Job Management Partner 1/Performance Management Planning and Configuration Guide.

To Page Top

(8) Supplementary information

• When a Web transaction is monitored, the Web accesses constituting the Web transaction must be within the monitoring range of the ITSLM - UR that monitors the target service for which the Web transaction is defined. If you want to monitor Web accesses outside the monitoring range, you must monitor them as Web accesses of a Web transaction of a monitored service whose Web accesses fall within the desired monitoring range.

• If you monitor a Web transaction and want to identify whether each Web access is from the same user, specify a session condition for the Web transaction. For a session condition, specify a query and a cookie key. Web accesses with the specified query and cookie key values are treated as Web accesses from the same user.

• The maximum length of an HTTP packet that ITSLM can monitor is 1,500 bytes including the IP and TCP headers. If a packet is longer than 1,500 bytes but contains the information to be monitored in the first 1,500 bytes, ITSLM can monitor it successfully. Any data following byte 1,500 is discarded.

To Page Top

(9) Related topics

• 3.1.2 Using out-of-range value detection for detection of unusual status in monitored services

• 3.1.3 Using trend monitoring for detection in advance of threshold overages

• 3.1.4 Using threshold value monitoring for detection of threshold overages

• 3.2.3 Setting up the Web transactions to be monitored

• 3.2.7 Setting up the monitoring items for service performance

To Page Top