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!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...