FTP Online
Search:
Locator+ Code:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

Build Business Service Metrics (Continued)

Consider possible reasons for a customer complaint about a long-running transaction:

  • The external network might delay the request even before it arrives at the enterprise.
  • The transaction might quickly complete, but congestion in the external network might stall confirmation delivery.
  • It might be delayed because of a hold-up in the request to an external service provider.
  • It might be delayed because of an internal resource bottleneck—but which one?
  • It might be delayed because it is an unusually complex transaction, requiring many resources. In other words, it might not be a "problem" at all, but rather something that falls outside the service-level agreement.

The problem worsens because of the need to monitor service-level agreements that specify transaction loads and response time guarantees against mixes of transaction types. Additionally, operations management must record the transaction stream and forecast future requirements for physical capacity, when it has no clear idea of the relationship between physical resources and business services.

The best that operations management groups can do to monitor service quality from the client's perspective is to use "active recording." In this approach, the test scripts mimic external clients and the response time they experience. The best datacenter management products supply tools to make this as easy as possible, but it is still a custom software development. And whereas this approach helps somewhat, it's limited because it attempts to study a dynamic system using static test scripts and provides no information on the mix of transactions that real clients submit right now.

The Way Forward
Development must address the fundamental problem by combining its logical view of the application with operations' physical view. The solution is for development to embed active monitoring in the deployed applications. The idea is: Record transaction metrics in business objects, upload these metrics by "piggybacking" metrics reports on new requests, and design a metrics reports database that gives operations the customer transaction view it needs to succeed.

Development can embed active metrics recording in its applications by extending its business objects. If development has the foresight to model client and server objects in a few base classes, some relatively minor changes in these base classes will suffice for most of the effort. You can embed active transaction metrics recording in a distributed application by following a few principles.

Follow a Few Principles
Principles of business transaction metrics recording include:

  • Every external or internal transaction client records transaction parameters and response times against its server objects.
  • You can extend application protocols so that requests can carry a transaction metrics payload and responses can carry a transaction identifier.
  • Server objects supply globally unique transaction identifiers for new customer transaction requests.
  • Client applications and internal client objects upload metrics on preceding transactions when subsequent requests are made to server objects.
  • Server objects strip off any metrics payloads received from clients and place them in a low-priority queue for logging.


Back to top



ADVERTISEMENT

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home