Splunk Search

How to improve transactions performance?

grio
Engager

Hi,all

index=C (sourcetype=A earliest=-3d latest=-2d) OR earliest=-3d latest=now sourcetype=B |transaction keepevicted=true ID

   sourcetype=A                                   sourcetype=B

_time                  id  name           _time                id   mode

------------------------------           ----------------------------------
10-11-08 上午16:05:57  001  a            10-11-08 上午16:59:57  001  aaa
10-11-08 上午17:52:58  002  b            10-11-09 上午15:59:58  002  bbb
10-11-08 上午20:51:58  003  c            10-11-10 上午17:59:58  003  ccc
10-11-08 上午21:50:58  004  d            10-11-10 上午17:59:58  006  ddd
10-11-08 上午22:20:58  005  e

---------------------------------------------------------------------------
I want results...
_time                  id  name mode  sourcetype

10-11-08 上午16:05:57  001  a    aaa   A  B
10-11-08 上午17:52:58  002  b    bbb   A  B
10-11-08 上午20:51:58  003  c    ccc   A  B                       
10-11-08 上午21:50:58  004  d          A
10-11-08 上午22:20:58  005  e          A

Set sourceType=A and B can not change the time

Big slow because the data

How to improve performance and speed?

My English is not good, I try to descript my questions carefully. hope you can understand what I mean.

Thanks a lot..

Tags (1)
0 Karma
1 Solution

sideview
SplunkTrust
SplunkTrust

I do not think that you can set two different time ranges like that.

However as far as performance issues with transaction I dont think you need to use transaction and you can use stats instead. Performance should be a bit better.

index=C ( sourcetype=A OR sourcetype=B ) 
| eval is_too_recent_A=if(searchmatch("sourcetype=process_control"),if(_time>relative_time(now(), "@m"),1,0),0)
| search is_too_recent_A=0
| stats values(*) as * by ID

Note that I create a field called is_too_recent, and the value will be 1 only when both sourcetype=A and the _time value is within today. Then the search clause removes those events from the set. And then the stats clause essentially does what your transaction as doing. The main difference is that the raw event text will be gone and you'll have only fields.

And instead of stats values(*) as * by ID you may want to do something more specific like this:

stats sum(someNumericField) avg(someOtherNumericField) first(someTextField) as someTextField by ID

View solution in original post

sideview
SplunkTrust
SplunkTrust

I do not think that you can set two different time ranges like that.

However as far as performance issues with transaction I dont think you need to use transaction and you can use stats instead. Performance should be a bit better.

index=C ( sourcetype=A OR sourcetype=B ) 
| eval is_too_recent_A=if(searchmatch("sourcetype=process_control"),if(_time>relative_time(now(), "@m"),1,0),0)
| search is_too_recent_A=0
| stats values(*) as * by ID

Note that I create a field called is_too_recent, and the value will be 1 only when both sourcetype=A and the _time value is within today. Then the search clause removes those events from the set. And then the stats clause essentially does what your transaction as doing. The main difference is that the raw event text will be gone and you'll have only fields.

And instead of stats values(*) as * by ID you may want to do something more specific like this:

stats sum(someNumericField) avg(someOtherNumericField) first(someTextField) as someTextField by ID

grio
Engager

I updated the results,Look for your reference,Thanks a lot..

0 Karma
Get Updates on the Splunk Community!

Enter the Agentic Era with Splunk AI Assistant for SPL 1.4

  🚀 Your data just got a serious AI upgrade — are you ready? Say hello to the Agentic Era with the ...

Stronger Security with Federated Search for S3, GCP SQL & Australian Threat ...

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Accelerating Observability as Code with the Splunk AI Assistant

We’ve seen in previous posts what Observability as Code (OaC) is and how it’s now essential for managing ...