Transactions can include:
- Different events from the same source and the same host.
- Different events from different sources from the same host.
- Similar events from different hosts and different sources.
For example, a customer purchase in an online store could generate a transaction that ties together events from several sources:
- A set of web access events share a session ID with....
- ....a corresponding event in the application server log, which also contains related account, product, and transaction IDs. The transaction ID in that application server event also appears in...
- ...a message queue event, which contains a message ID. This message ID is in turn shared by...
- ...a purchase fulfillment event logged by the fulfillment application, which also includes the shipping status of the item that the customer purchased.
All of the highlighted here, when grouped together, represent a single user transaction. If you were to define it as a transaction type you might call it an "item purchase" transaction. Other kinds of transactions include web access, application server downloads, emails, security violations, and system failures.
A transaction search enables you to identify transaction events that each stretch over multiple logged events. Use the
transaction command and its options to define a search that returns transactions (groups of events). See the documentation of the command in the Search Reference for a variety of examples that show you how you can:
- Find groups of events where the first and last events are separated by a span of time that does not exceed a certain amount (set with the
- Find groups of events where the span of time between included events does not exceed a specific value (set with the
- Find groups of related events where the total number of events does not exceed a specific number (set with the
- Design a transaction that finds event groups where the final event contains a specific text string (set with the
transaction command topic to get the full list of available options for the command.
You can also use the
transaction command to override transaction options that you have configured in
To learn more about searching with
transaction, read "Identify and group events into transactions" in the Search Manual.
Configure transaction types
After you create a transaction search that you find worthy of repeated reuse, you can make it persistable by adding it to
transactiontypes.conf as a transaction type.
To learn more about configuring transaction types, read "Configure transaction types," in this manual.
When to use stats instead of transactions
Transactions aren't the most efficient method to compute aggregate statistics on transactional data. If you want to compute aggregate statistics over transactions that are defined by data in a single field, use the
For example, if you wanted to compute the statistics of the duration of a transaction defined by the field
* | stats min(_time) AS earliest max(_time) AS latest by session_id | eval duration=latest-earliest | stats min(duration) max(duration) avg(duration) median(duration) perc95(duration)
Similarly, if you wanted to compute the number of hits per
clientip in an access log:
sourcetype=access_combined | stats count by clientip | sort -count
Also, if you wanted to compute the number of distinct session (parameterized by
clientip in an access log:
sourcetype=access_combined | stats dc(cookie) as sessions by clientip | sort -sessions
Read the stats command reference for more information about using the search command.
Configure event type templates
Search for transactions
This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.1.0, 8.0.7, 8.1.1