Splunk Search

Compare Two Different Fields in a Multisearch

dsitek
Explorer

I am trying to obtain a list of ids for orders that were abandoned/forgotten and never received a submit. I have a multisearch that finds a list of all ids when they are created and another search that finds the ids when they are submitted. I would like to find all of the values that appear only in the first list. Is there a command to do this without comparing two lookups? Here is my search:
| multisearch
[ search create call" | extract id ]
[ search submit call | extract id ]
| table created_cart_id submitted_cart_id

0 Karma
1 Solution

dsitek
Explorer

I just posted this but the most obvious solution hit me in the face. After the table command, rename both fields to be the same, count them, and select only ones that appear once.
rename created_cart_id AS cart_id, submitted_cart_idea AS cart_id | stats count by cart_id | where count=1

View solution in original post

0 Karma

dsitek
Explorer

I just posted this but the most obvious solution hit me in the face. After the table command, rename both fields to be the same, count them, and select only ones that appear once.
rename created_cart_id AS cart_id, submitted_cart_idea AS cart_id | stats count by cart_id | where count=1

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Event Series: Telemetry Pipeline Management

Balancing Scale and Spend: Gaining Control Over High-Volume Metrics in Splunk Observability Cloud As ...

Kick the Tires Before You Commit: A Hands-On Tour of the Splunk Observability Cloud ...

Evaluating an enterprise observability platform usually goes like this: fill out a form, get a free trial with ...

Deep insights, no barriers: Splunk Observability Cloud Free Edition

As software delivery cycles continue to accelerate, observability shouldn’t be a luxury — it should be a ...