The Application Response Measurement API (ARM)

In today's distributed computing environments traditional approaches to response time monitoring no longer seem to be adequate. Host centric approaches face the problem of not taking into account the distributed nature of the application to monitor. Network based approaches in contrast often are unable to map the packets found on the network to transactions meaningful to the user. Moreover these solutions are frequently proprietary and do not allow integration of applications and management tools from different vendors.

The Application Response Measurement API (ARM) [2] has been developed in 1996 in a joint initiative of Tivoli Systems and Hewlett-Packard. Later that year HP, Tivoli and 13 more companies established the ARM Working Group of the Computer Measurement Group (CMG) to continue development and promotion of the ARM. It promises to allow transaction based monitoring of response times in a distributed and heterogeneous environment. Work on version 2.0 of the API was finished in November 1997. In January 1999 the ARM API version 2.0 was adopted by the Open Group as its technical standard for application performance instrumentation.

To achieve the goals mentioned above a simple API was defined that is supposed to be implemented by management tools. The applications to be monitored are instrumented to call the following API functions:

• arm_init
  Is called during initialization of the application to be monitored and names the application and the current user.
• arm_getid
  This call is used to define the various classes of transactions appearing throughout the application.
• arm_start
  A call to arm_start is inserted into the application's code just before a transaction to be measured begins. Data to describe the current status of the application can be included.
• arm_stop
  This signals the end of a transaction. As seen with arm_start, data can be included.
• arm_update
  To provide status information about a running transaction, arm_update is used. It can be called any number of times between an arm_start and an arm_stop. It can also be used as some kind of a ''heartbeat'' signal to show that a long running transaction is still alive.
• arm_end
  Cleans up the ARM environment. A call to arm_end should be made when the application is ended or if no further monitoring is required.

A library implementing the calls has to be linked against the instrumented applications. The ARM Service Development Kit (ARM SDK) provides two libraries. On the one hand there is the so called NULL library, which simply returns TRUE for all the API calls. It can be linked against an instrumented application when no monitoring is to be done and it effects system performance only to a minimal extent. On the other hand there exists a library which implements a logging agent, that means an agent that writes all the information received by the application to a file. The logging agent is considered to be used mainly for testing purposes.

Actual performance monitoring can be done by using management tools that provide a measurement agent that implements the API and that is also linked against the application to be monitored (see figure 5).

  

Figure 5: Using the ARM API

An important feature added with version 2 of the API is correlation of transactions. Often one transaction visible to the user consists of a number of subtransactions. When indicating the start of a new transaction using arm_start, a data structure called a correlator can be requested from the measurement agent. When indicating the start of a subtransaction (again using arm_start), this correlator can be used to inform the measurement agent about the existence and identity of a parent transaction.