Splunk Search

Help with the search for a reassigned alert?

AL3Z
Builder

Hi, Need a search for the below scenario,

If a previously assigned alert is reassigned to a different user on the portal, it will trigger a new alert because the updated time is considered in the cs. For example, with alert  was initially detected on the  portal  However, when I reassigned the alert to myself last week, a new alert was generated based on the updated time field.

Thanks

Labels (1)
0 Karma
1 Solution

Tom_Lundie
Contributor

There are three options that I can see here, you can either:
a) Make sure that the foundDate occured since the last CS-run so that the CS only ever fires for new events.

| eval founddate_ts = strptime(foundDate, "%Y-%m-%dT%H:%M:%S.%fZ")
| where founddate_ts > relative_time(now(), "-30min")

b) Maintain a lookup of fired alerts so that the same alert doesn't twice.

| eval id = _id
| search NOT [| inputlookup example_lookup | fields id | format]
| appendpipe [| fields id, _time | outputlookup append=t example_lookup]

 c) Throttle the alerts via the CS Configuration:
Throttle Duration: Five Years
Fields to Group By: _id


All three of these have pros / cons, so please experiment with these ideas to see what is right for you and your team.

View solution in original post

Tom_Lundie
Contributor

You can throttle the Correlation Search.

You can read more about throttling here. You could throttle by _id for a sufficient enough time to stop the alerts from re-firing.


0 Karma

AL3Z
Builder

Hi 

@Tom_Lundie 

Could you pls help me with the search with the founddate.

0 Karma

Tom_Lundie
Contributor

There are three options that I can see here, you can either:
a) Make sure that the foundDate occured since the last CS-run so that the CS only ever fires for new events.

| eval founddate_ts = strptime(foundDate, "%Y-%m-%dT%H:%M:%S.%fZ")
| where founddate_ts > relative_time(now(), "-30min")

b) Maintain a lookup of fired alerts so that the same alert doesn't twice.

| eval id = _id
| search NOT [| inputlookup example_lookup | fields id | format]
| appendpipe [| fields id, _time | outputlookup append=t example_lookup]

 c) Throttle the alerts via the CS Configuration:
Throttle Duration: Five Years
Fields to Group By: _id


All three of these have pros / cons, so please experiment with these ideas to see what is right for you and your team.

AL3Z
Builder

@Tom_Lundie  

Hi,

A)Why  we have taken "-30min" 

B) do we need to add the previous founddate values in the lookup table.

C) why the throttle duration is 5 years ?

 

Thanks..

0 Karma

Tom_Lundie
Contributor

A)Why  we have taken "-30min" 
This was just an example, ideally this value would match your CS scheduling window (factoring in event lag and search lag).

B) do we need to add the previous founddate values in the lookup table.
No, just the _id (as id in my example).

C) why the throttle duration is 5 years ?
This was an example that should be sufficiently long enough.

All just example ideas for you to experiment with to see which one works.

Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...

Introducing the 2024 SplunkTrust!

Hello, Splunk Community! We are beyond thrilled to announce our newest group of SplunkTrust members!  The ...