A transaction is a group of related events. They don’t necessarily occur at the same time. Transactions can be generated from multiple data sources and multiple separate log entries. Basically, a single event can be mapped out to multiple logged events.
Viewing the events associated with a transaction can help you to determine why it takes a long time.
Transactions are especially important because you can’t always just rely on a unique ID in cases where the ID might be reused.
Splunk Transaction Example
An example of a Splunk transaction might be someone making a purchase in an online store. Another example could be a known issue where out of memory events are correlated to database errors.
Transactions can be created using the transaction command. It basically aggregates events together.
Here is an example I took directly out of the official Splunk documentation:
sourcetype=access_logs* | transaction JSESSIONID clientip startswith="view" endswith="purchase" | where duration>0
Essentially, the transaction will be composed of all records with both the same session ID ( JSESSIONID ) and the same client IP (clientip) that fall beween a start and end value. The transaction will start with a record that includes the word “view” and end with a record that includes the word “purchase”. The duration field is added by the transaction command. We pipe to this so that we can make sure that the transaction isn’t too short and therefore invalid. Note that we aren’t doing any filtering in this example so it could take longer than it needs to to process.
Splunk Transaction vs Stats Command
Both of these are used to aggregate events. The stats command just takes statistics and discards the actual events. The Splunk transaction command doesn’t really compute any statistics but it does save all of the records in the transaction. It also has more complex options.
You may find that you learn better by watching videos instead of reading documents. You might want to check out this video about Splunk transactions: