Splunk Search

joining / subsearching / dual sourcetype for matching error attibutes

fox
Path Finder

I have two related sets of data: Errors and CalcRun. The relationship in SQl speak is Many Errors to a CalcRun. When listing an error or set of errors I need to establish the appropriate CalcRun based on the time stamp.


Example:

Errors table:

  • 10:12 error1
  • 10:23 error2
  • 10:34 error3
  • 10:45 error4
  • 10:56 error5

CalcRun table:

  • 09:30 CalcRunA
  • 10:01 CalcRunB
  • 10:40 CalcRunC
  • 10:50 CalcRunD
  • 11:10 CalcRunE

Required 1 table Splunk output results from these two data inputs:

  • TIME: ERROR: CALCRUN:
  • 10:12 error1 CalcRunB (error after 10:01 & before 10:40 hence B)
  • 10:23 error2 CalcRunB (error after 10:01 & before 10:40 hence B)
  • 10:34 error3 CalcRunB (error after 10:01 & before 10:40 hence B)
  • 10:45 error4 CalcRunC (error after 10:40 & before 10:50 hence C)
  • 10:56 error5 CalcRunD (error after10:50 & no more runs hence D)

This is easy to do in SQL with a cursor, any guidance on how to do this in splunk?

Tags (2)
0 Karma

Dan
Splunk Employee
Splunk Employee

I would start with lookups rather than transaction or subsearch. From the Error events, use the _time field to do a temporal lookup for the CalcRun value. This approach will perform well and can be wired to happen automatically. It's all documented here: http://www.splunk.com/base/Documentation/latest/Knowledge/Aboutlookupsandfieldactions

Get Updates on the Splunk Community!

Splunk Enterprise Security 8.x: The Essential Upgrade for Threat Detection, ...

 Prepare to elevate your security operations with the powerful upgrade to Splunk Enterprise Security 8.x! This ...

Get Early Access to AI Playbook Authoring: Apply for the Alpha Private Preview ...

Passionate about security automation? Apply now to our AI Playbook Authoring Alpha private preview ...

Reduce and Transform Your Firewall Data with Splunk Data Management

Managing high-volume firewall data has always been a challenge. Noisy events and verbose traffic logs often ...