Splunk Search

what does connected mean in transaction

Splunk Employee
Splunk Employee

explain the significance of the connected flag in transaction

Tags (1)
1 Solution

Splunk Employee
Splunk Employee

Here are two examples that explain how the connected flag affects transactions. Consider having these events in descending time order

event1 mid=1  
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc

.... | transaction mid, foo_id

when using connected=true the following trasaction will be created: (event2 is not added because at the time it is processed we don't have an established transitive relationship between mid and foo_id)

event1 mid=1
event3 mid=1, foo_id=abc
event4 foo_id=abc

if connected=false the transaction would look like

event1 mid=1
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc

connected=true means that before adding an event to a transaction the value of least one of the unifying fields must be present in at least one of the existing events in the transaction. connected=false means that an event can be added to a transaction eventhough a transitive relation is not established between the fields already seen in the transaction and the ones present in the event

Given that we see events in the reverse time order, there are some pretty good chances that we see the transitive relation established after (earlier in time) it can be useful to us. Consider the following stream of events

time=1 action=login, user=foo
time=2 action=assing_id, user=foo, id=123
time=3 action=sendemail, id=123
time=4 action=drink beer, user=foo

is processed in splunk as follows: (so you can see that in connected=true "time=3 action=sendemail, id=123" will not be part of the transaction because it occurs before the transitive relationship betwen user and id is formed)

time=4 action=drink beer, user=foo
time=3 action=sendemail, id=123
time=2 action=assing_id, user=foo, id=123
time=1 action=login, user=foo

In 4.1 we do the right thing even when the transitive relationship is seen later - in pre 4.1 connected=false is the poor's man solution

View solution in original post

Splunk Employee
Splunk Employee

Here are two examples that explain how the connected flag affects transactions. Consider having these events in descending time order

event1 mid=1  
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc

.... | transaction mid, foo_id

when using connected=true the following trasaction will be created: (event2 is not added because at the time it is processed we don't have an established transitive relationship between mid and foo_id)

event1 mid=1
event3 mid=1, foo_id=abc
event4 foo_id=abc

if connected=false the transaction would look like

event1 mid=1
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc

connected=true means that before adding an event to a transaction the value of least one of the unifying fields must be present in at least one of the existing events in the transaction. connected=false means that an event can be added to a transaction eventhough a transitive relation is not established between the fields already seen in the transaction and the ones present in the event

Given that we see events in the reverse time order, there are some pretty good chances that we see the transitive relation established after (earlier in time) it can be useful to us. Consider the following stream of events

time=1 action=login, user=foo
time=2 action=assing_id, user=foo, id=123
time=3 action=sendemail, id=123
time=4 action=drink beer, user=foo

is processed in splunk as follows: (so you can see that in connected=true "time=3 action=sendemail, id=123" will not be part of the transaction because it occurs before the transitive relationship betwen user and id is formed)

time=4 action=drink beer, user=foo
time=3 action=sendemail, id=123
time=2 action=assing_id, user=foo, id=123
time=1 action=login, user=foo

In 4.1 we do the right thing even when the transitive relationship is seen later - in pre 4.1 connected=false is the poor's man solution

View solution in original post