|
explain the significance of the connected flag in transaction |
|
Here are two examples that explain how the connected flag affects transactions. Consider having these events in descending time order
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)
if connected=false the transaction would look like
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
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)
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 |
