Skip to main content
Sumo Logic

Transaction Operator Examples

The following examples can help you understand the way transaction works.

Syntax

  • transaction on [field1] with states [state1] as [alias1], [state2] as [alias2] results by transaction
  • transaction on [field1] with states [state1] as [alias1], [state2] as [alias2] results by states
  • transaction on [field1] with states [state1] as [alias1], [state2] as [alias2] results by flow

See Defining States for details.

States act as matching statements, searching your log for that specific state. These support wildcards * to match on any characters. For example, in the following log, if one of the states you needed to capture was when a session is started based on your parsed field sessionId,

2018-02-15 13:00:28,799 -0800 INFO  [hostId=nite-spark-app-1] [module=sumo-app] [localUserName=sumo-app] [logger=sumo.app.SumoAppSearchSessionProtocolHandler] [thread=DTP-soa.sumo-app-soa.SearchSessionProtocol-32] [auth=Customer:0000000000000111:0000000000000111:0000000000000111:false:DefaultSumoSystemUser:-1:UNKNOWN] [sessionId=B6C329D84D1E37C6] [customer=0000000000000111] [remotemodule=sumo-app] Starting session B6C329D84D1E37C6

you would specify the state as a matching statement on the sessionId like this:

| transaction on sessionid with "Starting session *" as init,

Limitations

For ordered data, there is a group limit of 10,000. The transaction operator uses a least-recently used scheme to phase out transactions. So when this limitation is reached, the transactions that are included in the results are not the first 10,000 transactions, but the 10,000 most-frequently used transactions. This is due to the fact that some earlier transactions have ended prematurely, as stated in the following error.

This message is displayed if you use more than 10,000 groups with the Transaction operator:

Group or memory limit exceeded, some transactions may have ended prematurely.

For unordered data, once group limit of 10,000 is reached, new transactions are ignored.

Running transaction on sessionID

When you use the transaction operator, it requires one or more transaction IDs to group related log messages together. For this ID, you can use session IDs, IPs, username, email, or any other unique IDs that are relevant to your query.

In this example, using the browser sessionID as the transaction ID, we could define states for countdown_start and countdown_done:

... | transaction on sessionid
with "Starting session *" as init,
with "Initiating countdown *" as countdown_start,
with "Countdown reached *" as countdown_done,
with "Launch *" as launch
results by transactions showing max(_messagetime),
sum("1") for init as initcount

Fields created by transaction

There are two fields created by the transaction operator,  _start_time and _end_time. These fields show up as Start Time and End Time on the Aggregates tab, but you must reference them in queries using the names with underscores or we won't recognize them.

The fields are assigned a timestamp in milliseconds.

For example in the query:

_source=Syslog (New session) OR (Session deleted) 
| transaction on sessionid with "*New session*" as started, with "*Session deleted*" as ended
| where started > 0 
| ((_end_time - _start_time)/1000)/60 as time_difference_minutes

You reference the _end_time and _start_time fields to calculate the duration of thesessionid.

fields created by transaction.png

Detecting a potential e-commerce failure

In this example, you could track the states of your e-commerce site to see if there is a disconnect or drop off between two states that would indicate a potential failure.

Running a query similar to:

_sourceCategory=[sourceCategoryName]
| parse regex "(?<ip>[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})" nodrop
| transaction on ip
with "*/cart*" as cart,
with "*/shippingInfo*" as shipping,
with "*/billingInfo*" as billing,
with "*Verifying credit card with external service*" as billingVerification,
with "*/confirmation*" as confirmation,
with "*Order shipped*" as ordershipped
results by flow
| count by fromstate, tostate

could produce a Flow Diagram with normal drop-off rates at the different states: cart, shipping, billing, billingVerification, confirmation, and order shipped.

ecommerce flowchart.png

Now, if you ran this query and saw results as shown below, where there is a big drop-off at the verification state, you could determine that there is likely a problem with the verification service and start an investigation.

ecommerce flowchart missing states.png