Chapter 2: IBM Tivoli Monitoring for Transaction Performance in Brief

---

This chapter provides a high level overview of the functionality incorporated in IBM Tivoli Monitoring for Transaction Performance Version 5.2. We also introduce some of the reporting capabilities provided by TMTP.

2.1 Typical e-business transactions are complex

Figure 2-1 depicts a typical e-business application. Typically, it will involve multiple firewalls and an application that will have many components distributed across many different servers.

Figure 2-1: Typical e-business transactions are complex

As you can tell from Figure 2-1, there are also multiple machines doing the same piece of work (as is indicated by the duplication of the Web servers, application servers, and databases). This level of duplication is needed to ensure high availability and to handle a large number of concurrent users. The architecture that you see here is different in several ways from the past. In the past, all of these components were often on a single infrastructure (the mainframe). This all changed with the evolution of client server, and is now changing again with the trend towards Web Services.

2.1.1 The pain of e-business transactions

Generally, when monitoring an environment such as that described above, the response to a customer complaint about poor performance can be described as follows:

Step 1

Typically, a call comes in to the help desk indicating that the response time for your e-business application is unacceptable.

This is the first place where you need a transaction performance product (to find out if there is a problem, hopefully before the customer calls you to identify a problem).

Important: 

At step 1, if the customer has IBM Tivoli Monitoring, then they would see far few problems even show up, because they are being automatically cured by resource models. If the customer has TBSM, and it is a resource problem, then there is a good chance that the team is already working on solving the problem if it is in a critical place.

Step 2	The next step usually involves the operations center. The Network Operations Center (NOC) gets the message and starts by looking at the network to see if they can detect any problems at this level. Operations team in the NOC calls the SysAdmins (or Senior Technical Support Staff, that is, the more senior staff that are responsible for applications in production).
Step 3	Then a lot of people are paged! The number of pagers that go off is often dependent on the severity of the SLA or the customer involved. If it is a big problem, a "tiger team" will be assembled. This typically large group of people are assembled to try and resolve the problem.
Step 4	The SysAdmins check to see if anything has changed in the past day to understand what the cause may be. If possible, they roll back to a previous version of the application to see if that fixes the problem. The SysAdmins then typically have a check list of things they do or tools they use to troubleshoot the problem. Some of the tasks they may perform are: Look at any monitoring tools for hardware, OS, and applications. Look at the packet data: number of collisions, loss between connections, and so on. Crawl through the log files from the application, middleware, and so on. The DBAs will check databases from the command line to see what response time looks like from there. Call other parties that may be related (host based applications, application developers that maintain the application, and so on).
Step 5	Finger pointing. Unfortunately, it is still very difficult to solve the problem. These tiger teams often generate a lot of finger pointing and blaming. This is unpleasant and itself leads to longer problem resolution response times.

All of this is very painful and can be very expensive.

TMTP 5.2 solves this problem by pinpointing the exact cause of a transaction performance problem with your e-business application quickly and easily, and then facilitating resolution of that problem.

---