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!

New This Month in Splunk Observability Cloud - Metrics Usage Analytics, Enhanced K8s ...

The latest enhancements across the Splunk Observability portfolio deliver greater flexibility, better data and ...

Alerting Best Practices: How to Create Good Detectors

At their best, detectors and the alerts they trigger notify teams when applications aren’t performing as ...

Discover Powerful New Features in Splunk Cloud Platform: Enhanced Analytics, ...

Hey Splunky people! We are excited to share the latest updates in Splunk Cloud Platform 9.3.2408. In this ...