Hi All,
How we can modify the below search to get to see only the status enabled list of correlation searches which did not trigger a notable in past X days.
| rest /services/saved/searches
| search title="*Rule" action.notable=1
| fields title
| eval has_triggered_notables = "false"
| join type=outer title [
search index=notable search_name="*Rule" orig_action_name=notable
| stats count by search_name
| fields - count
| rename search_name as title
| eval has_triggered_notables = "true"
]
Thanks..
Could you explain what's wrong with the original search? What is expected and what is the actual results? Importantly, what is the logic in your original search to meet your expectation?
If I have to read your mind based on the code snippet, you are saying that
If I put down whether action.notable should be 1 or 0, i.e., assuming that has_triggered_notables = "false" is the correct label for the main search, it should have zero overlap with the subsearch which you labeled as has_triggered_notables = "true". This means an outer join should give you everything in the main search. Is this what you see? Why would you expect anything different? Again, nobody in the forum except yourself has that answer.
Maybe action.notable is not something to indicate whether a notable is produced? Maybe this field doesn't even exist? You used the phrase "status enabled" to describe your criteria. But saved searches has no "enabled" or "not enabled" statuses. Do you mean scheduled, as discernible from is_scheduled field, nothing to do with the nonexistent action.notable?
If you ask an unanswerable question, no one is able to give you an answer. And this one is full of hallmarks of unanswerable questions.
Before I give up, let me make a final wild guess: By "enabled" you mean is_scheduled=1, there is nothing about action.notable, and that the subsearch actually does something as I speculated above (2). In that case, this is a search you can try and tweak that doesn't involve an inefficient join.
| rest /services/saved/searches
| search title="*Rule" is_scheduled=1 NOT
[search index=notable search_name="*Rule" orig_action_name=notable
| stats values(search_name) as title]
| fields title
@yuanliu ,
My goal is to identify status enabled correlation searches that have triggered notables within the past 30 days.
My goal is to identify status enabled correlation searches that have triggered notables within the past 30 days.
This does not answer the questions: Could you explain what's wrong with the original search? What is expected and what is the actual results? (Illustrate with anonymized example/mockup. Explain the difference between expected results and actual results from your search.) Importantly, what is the logic in your original search to meet your expectation?
If you cannot illustrate your data input, expected results and actual results, and clearly explain the logic between illustrated data and expected results (without SPL), this is just a waste of volunteers' time. No one can read your mind.
Yeah, my mind-reading qualification lapsed during lock-down and I have not been able to find an authorised examiner in my area in order to re-sit the assessment. 😎