This documentation refers to the standalone (legacy) method of running APM Server. This method of running APM Server will be deprecated and removed in a future release. Please consider upgrading to the Elastic APM integration. If you’ve already upgraded, see Data Model.
Transactions are a special kind of span that have additional attributes associated with them. They describe an event captured by an Elastic APM agent instrumenting a service. You can think of transactions as the highest level of work you’re measuring within a service. As an example, a transaction might be a:
- Request to your server
- Batch job
- Background job
- Custom transaction type
Agents decide whether to sample transactions or not, and provide settings to control sampling behavior. If sampled, the spans of a transaction are sent and stored as separate documents. Within one transaction there can be 0, 1, or many spans captured.
A transaction contains:
- The timestamp of the event
- A unique id, type, and name
Data about the environment in which the event is recorded:
- Service - environment, framework, language, etc.
- Host - architecture, hostname, IP, etc.
- Process - args, PID, PPID, etc.
- URL - full, domain, port, query, etc.
- User - (if supplied) email, ID, username, etc.
Transactions are grouped by their
name in the APM UI’s
If you’re using a supported framework, APM agents will automatically handle the naming for you.
If you’re not, or if you wish to override the default,
all agents have API methods to manually set the
typeshould be a keyword of specific relevance in the service’s domain, e.g.
nameshould be a generic designation of a transaction in the scope of a single service, e.g.
Most agents limit keyword fields (e.g.
labels) to 1024 characters,
non-keyword fields (e.g.
span.db.statement) to 10,000 characters.
Transactions are stored in transaction indices.