Transactions
This documentation does not apply to the most recent version of Splunk.
This documentation applies to the following versions of Splunk: 3.2 , 3.2.1 , 3.2.2 , 3.2.3 , 3.2.4 , 3.2.5 , 3.2.6 , 3.3 , 3.3.1 , 3.3.2 , 3.3.3 , 3.3.4 , 3.4 , 3.4.1 , 3.4.2 , 3.4.3 , 3.4.5 , 3.4.6 , 3.4.8 , 3.4.9 , 3.4.10 , 3.4.11 , 3.4.12 , 3.4.13
Contents
Transactions
Transactions enable you to search, and report on transactions in your data indexed in Splunk. A transaction is a grouping of events that contain related pieces of information. Transaction search is useful for a single observation of any physical event stretching over multiple logged events.
Here is an example of what can make up a transaction:
- An event in a Web access log
- An event in an application server log
- An event in an asynchronous fulfillment application that generates a message queue that subsequently identifies a business transaction
In this case, the Web access log might share a session ID with the event in the application server log; the application server log might contain the account ID, transaction ID, and product ID; the transaction ID may live in the message queue with a message ID, and the fulfillment application may log the message ID along with the shipping status. All of this data represents a single user transaction.
Example use cases
There are many cases where a transaction search may be useful. Here are some use cases for transaction search:
- Find quarantined mail messages where
- All events printed to a mail log for the different steps in processing a given message are considered to be a transaction.
- All events in the transaction share a message ID or a process ID with events that have both a process ID and message ID providing the transition.
- Queue entry events containing the sender's email address, and separate delivery events for each recipient of the message.
- To find a security issue
- A sequence of 3 specific error messages in a particular order within a time frame on a given host that may be consistent with a known failure or attack pattern.
- To combine any combination of specific event types
- Any transaction from a single data source that generates multiple log entries for a single event.
The transaction search command
Search for transactions using the transaction search command. transaction yields groupings of events which may then be used in reports. To use transaction, either call a pre-configured transaction type, or define (or override) transaction constraints during your search via transaction command options.
Example transaction searches
Run a search that groups together all of the pages a single user (or client IP address) looked at over a time range.
This search takes events from the access logs, and creates a transaction from events that share the same clientip value that occurred within 5 minutes of each other (within a 3 hour time span).
sourcetype=access_combined | transaction fields=clientip maxpause=5m maxspan=3h
Transactions and macro search
Transactions and macro search are a powerful combination that allow substitution into your transaction searches. Make a transaction search and then save it with $field$ to allow substitution.
When to not use 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 stats command.
For example, to compute the statistics of the duration of a transaction defined by the field trade_id:
* | stats min(_time) as earliest max(_time) as latest by trade_id | eval duration = latest-earliest | stats min(duration) max(duration) avg(duration) median(duration) perc95(duration)Similarly, if you want to compute the number of hits per clientip in an access log:
sourcetype=access_combined | stats count by clientip | sort -countAlso, compute the number of distinct sessions (parameterized by cookie) per clientip in an access log:
sourcetype=access_combined | stats dc(cookie) as sessions by clientip | sort -sessions