i have two id's lets say ID1 and ID2
i want to use transaction command for both ID1 and ID2 in same query , please help me with this.l
i have more than two events those events contains some id's like
i want to combine all 3 events event1,event2 and event3 into single event by value 101.
Without much information, I would say you can create a common fields using eval like
| eval commonID=coalesce(ID1,ID2) and use it in transaction. Again, transactions are expensive and there might be alternatives, so if you add more information, we may be able to provide better suggestions.
You should be able to combine all three events using something like this
your base search | eval ID=split(coalesce(REQUEST_ID,"#")."#".TRANSACTION_ID,"#") | mvexpand ID | stats values(fieldthatyouwant1) as fieldthatyouwant1... by ID
You should avoid the use of
transaction whenever possible. You have not given us much information to go on but maybe this:
... | stats values(*) AS * BY ID
Are you combining the two transactions because you are linking the
TRANSACTION_ID from the first event to the
REQUEST_ID from the second?
If so, are you trying to also connect up a third transaction like this if it exists
What are the actual data fields involved that you will be working with?
I'm making an assumption here that the sourcetype is always distinct in all 3 of your event examples. For example that "event 2" is always of sourcetype "sourcetype2". And event1 is sourcetype1 etc. If that assumption isn't true but is true of some other field, you'll have to modify this example a bit.
<your search terms> | eval normalizedId=if(sourcetype="sourcetype2",REQUEST_ID,TRANSACTION_ID) | fields normalizedId, TRANSACTION_ID someField anotherField yetAnotherField | stats list(*) as * by normalizedId
what this will do, is roll up all the fields that you see in the fields line, by ID. And for the ID it will pick the REQUESTID field value within event2, but the TRANSACTIONID value for all other events.
some other quick best practice notes:
- Avoid doing list() as * without something before to limit the fields. Here i've used a fields clause, but anything that serves to limit the fields is fine. Sending unconstrained lists into list() as * can blow up memory usage if there are tons of fields (100, 200), often for no gain.
- If the conditional logic to normalize the id is more complex, you often have to switch to the case() function in eval instead of if() The full list of functions in eval is here - https://docs.splunk.com/Documentation/Splunk/6.5.2/SearchReference/CommonEvalFunctions it's worth at least skimming and bookmarking.
- transaction is probably not the way to go. For one thing it breaks map reduce (forcing all event rows to come back to the search head), for another it'll be slower, However if you really feel like you want to see the raw event text, note you can do
list(_raw) as _raw. You may want to sneak areverse
command in before the stats if so to reorder the lines earliest first. (The astute reader will notice thatlist(_raw) as _raw` effectively brings back all the rows to the search head too. )