The word transaction can have several different meanings in the software industry. This document explains how the term is used by New Relic and how transactions are reported.
What is a transaction?
At New Relic, a transaction is defined as one logical unit of work in a software application. Specifically, it refers to the function calls and method calls that make up that unit of work. For APM, it will often refer to a web transaction, which represents activity that happens from when the application receives a web request to when the response is sent.
When you install APM in a supported system, it begins automatically reporting web requests and other important functions and methods. To supplement the default level of monitoring, you can set up custom instrumentation to report additional transactions.
Some frameworks do not have a natural concept of a transaction. In other words, there are no predefined pathways that can easily be recognized or monitored as transactions. To define transactions in such frameworks, you can use custom instrumentation.
Types of transactions
Cumulative transaction data appears in APM on the Transactions page. The two main categories of transactions are web and non-web:
- Web: Transactions are initiated with an HTTP request. For most organizations, these represent customer-centric interactions and thus are the most important transactions to monitor.
- Non-web: Non-web transactions are not initiated with a web request. They can include non-web worker processes, background processes, scripts, message queue activity, and other tasks.
Transaction sub-types
Our agents have these transaction sub-types:
Transaction segments
The individual functions and calls that make up a transaction are called segments. For example external service calls and database calls are segments, and both have their own UI pages in APM.
The APM Transactions page displays aggregate transaction segment data.
- To add segments to a transaction, use custom instrumentation.
- To see the segments of a specific transaction, use transaction traces.
Transaction naming
For supported frameworks, transaction names can come from various sources, such as the name given to the transaction by the framework, function names detected during the transaction, or a web request's URL.
For transactions that produce many names with a similar format, we consolidate those into general transaction categories. For example, a transaction might be displayed as /user/*/control_panel, where the * represents different user names.
To rename transactions or adjust how names are consolidated, use custom instrumentation.
Monitoring transactions
Here are some other ways you can use APM to monitor transactions:
If you want to monitor... | Use this... |
|---|---|
Transactions important to your business | Create key transactions, which emphasizes them in the UI and lets you set a custom level of monitoring for them. |
Async activity | Follow the procedures to set up asynchronous activity for your specific APM language agent. |
Activity across applications | Linking transactions across applications gives you more detail about business-relevant application activity. For more information, see the documentation about distributed tracing and cross application traces. DicaTo get a high-level overview of all your applications and services, use our entity explorer. |
Query transactions
Transactions are available for querying with an in-depth set of default attributes attached. Using these attributes, you can run queries and create custom charts that APM does not provide by default.
For information on how to query your data using our UI or NRQL, see Query New Relic data.