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!

Updated Team Landing Page in Splunk Observability

We’re making some changes to the team landing page in Splunk Observability, based on your feedback. The ...

New! Splunk Observability Search Enhancements for Splunk APM Services/Traces and ...

Regardless of where you are in Splunk Observability, you can search for relevant APM targets including service ...

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...