Getting Data In

Transaction Command: Determine Outliers/Mismatches Only

bcarr12
Path Finder

I am using the transaction command in Splunk to group the events of an identical log file across two hosts. Essentially, the field=value pairs across both hosts should be identical at all times. From time to time, issues can issue that cause the two hosts to become out of sync. I'd like to have a search that only identifies transactions where the field=value pairs do not match exactly. What would be the best way to accomplish this?

For instance, using the search below groups the log files from multiple hosts into a single transaction by second.
"searchterm" source="mylog.log" | transaction field maxspan=1s

I want to only return events with the below pattern (mismatches)
2020-01-10 17:30:00,348 INFO field=true
2020-01-10 17:30:00,351 INFO field=false

But ignore events with this pattern (identical)
2020-01-10 17:30:00,348 INFO field=true
2020-01-10 17:30:00,351 INFO field=true

Or this pattern (identical)
2020-01-10 17:30:00,348 INFO field=false
2020-01-10 17:30:00,351 INFO field=false

0 Karma

to4kawa
Ultra Champion
"searchterm" source="mylog.log" 
| streamstats time_window=1s dc(field) as flag
| where flag >1

how about this?

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 ...