In order to instrument an application the following concepts are used within ARM.
Transactions are the main entity within the ARM architecture. Generally, they consist of a unique ID, a status of completion, a response time and the stop time when the transaction has finished. The status of completion signals whether the transaction executed successfully (good), was aborted during the call (abort) or failed entirely (failed).
In the ARM 3.0 and also in the ARM 4.0 version of the specification there are basically two different concepts how an ARM transaction is measured:
The first approach is compatible with older versions of ARM, the latter was first introduced in the version 3.0 of ARM allowing more control for the application developer over when and how timings are measured and/or reported to the ARM system.
Complex distributed applications can consist of many different single applications (processes). The concept of an ARM application is introduced within version 4.0 of the ARM standard to facilitate modeling of the relationships between all single applications. Each ARM transaction executes within exactly one ARM application.
The nature of distributed applications implies that they deploy not only on a single host but maybe on many (up to hundreds of) different hosts. To resolve this ambiguity the concept of an ARM system defines the executing host of an ARM application instance. The information used to identify a system is mainly the network address of a host on the network. Using this specification it is possible to track the execution flow of a compound transaction for physically distributed scenarios.
ARM correlators are used to express a correlation between two ARM transactions, that is, a "parent/child" relationship. A parent transaction triggers a child transaction and blocks until the child transaction has finished. Correlators are used to break down a complex transaction into several nested child transactions where each child transaction in turn can have child transactions of its own. Th result is a tree of transactions with the topmost parent transaction being the root of the tree.
Using ARM correlators, it is possible to split a transaction into different sub transactions allowing to isolate the part where a complex transaction failed, was aborted or has a bottleneck.
For distributed applications deployment it is often desirable to have a finer granularity for the view of the application progress. For this, ARM offers the following concepts.
Properties are sets of name/value pair strings which qualify an ARM transaction or an ARM application beyond the basic definition of these entities. There are two kinds of properties for both ARM application and ARM transaction:
ARM Metrics can be used to retrieve more information about the execution of a transaction. This information consists of a measured value such as a counter, a gauge or just a numeric value.
For example, the response time of a transmission of a web-page from the server to the client depends, among other parameters, on the size of the web-page. Thus, in order to get an impression of how a transmission performs the evident approach is to normalize the response time by the size of a web-page.