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
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.
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.
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.
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..
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.