I queried the /servicesNS/-/-/saved/searches GET API and got a number of responses which included saved searches listed under Reports and Alerts on the front end. I took the response for one of the alerts, extracted the relevant information (without changing any values) and did a POST to /servicesNS/{owner}/{app}/saved/searches/{name}. After I did the POST, the saved search is now showing up under Report on the UI.
I used this to determine if the saved search was a report or an alert:
| eval ss_type=if((NOT 'action'=="*" AND NOT alert_track=="*" AND NOT alert_condition=="*" AND 'alert_type'=="always"),"report","alert")
it may just be when 'alert_type'=="always" but I added the others to be safe. I needed to do this to create clickable links that would open the report or alert . So you might want to check if it has these values, which would cause it to be recognized as a report.
It's an old thread, but is alert_type=="always"
enough to determine that a saved search is an alert?
Apparently, it's the other way around - alert_type == "always"
, means that the saved search is a report, because it always fires and therefore to detect alerts we need to use alert_type != "always"
, in cases when alert_type == "number of events"
etc.
The thread is even older now, but I also found you need to specify `'alert.suppress': 0` when posting to `/servicesNS/{owner}/{app}/saved/searches/` to make sure it's an alert and not a report.
In total, I specified at least the below parameters to create an alert
{
'is_scheduled': 1,
'cron_schedule': '09-59/10 * * * *',
'alert_comparator': 'greater than',
'alert_threshold': 5,
'alert_type': 'number of events',
'alert.suppress': 0,
}