How do you disable/enable alerts via the REST API?

[tmontney]

Edit: Answer is as follows.

Method: POST
Endpoint: https://mysplksvr:8089/servicesNS/nobody/search/saved/searches/My%20Search/{value}
Value: enable|disable

The important point was to replace user_context with nobody. Originally, I tried my own e-mail (request was successful but didn't apply any changes). I noticed the correct context while viewing the alert in the GUI.

mysplksvr/en-US/app/search/alert?s=%2FservicesNS%2F*nobody*%2Fsearch%2Fsaved%2Fsearches%2FMy%2520Search

The recommended method of updating the GeoLite database is to stop realtime searches. This is best done via script, so I need to tell Splunk via API to stop realtime searches. That's easy, but I can't figure out how to restart those searches. It seems that if I delete the search, give it about a minute, the search restarts.

• Is there a way to start the search manually? (I've tried dispatching it like a normal search, but it's not the same. This causes double search; the correct search has rt_scheduler appended to its URL)
• Is there a way to mimic clicking Enable/Disable when editing an Alert under https://mysplksvr/en-US/app/search/alert? (this seems to start/stop the search)

Again, the goal is not to simply stop e-mails (or actions in general) from happening (what many of the examples from my searches suggest). I should be able to see real-time searches start/stop under Search Activity: Instance in the Monitoring Console.

[damien_chillet · Accepted solution]

You can enable/disable rule with the API:

Example with curl:

curl -k -u admin https://<host>:<mgmt_port>/servicesNS/<user_context>/<app_context>/saved/searches/<search>/disable -X POST

Replace disable with enable to enable.

[tmontney]

So I expected the GUI to update when I called: https://mysplksvr:8089/servicesNS/myemail%40domain.com/search/saved/searches/My%20Search/disable

Return data just lists info about the search. Doesn't seem to reflect the changes. user_context is the owner of the search/alert.

[brettw]

I know this is five years later... but people are bound to run across this post.

If the saved search is shared to the app, then the user context of your API call should be:

nobody

If you follow the instructions as written in the solution, sending a POST this way, even when an identically-named saved search exists in the App or Global context, because the POST is in the user's context, it POSTs to the user's private savedsearches.conf within the same app context, not the app's savedsearches.conf.

If you want to update a saved search which is shared into an app, you must change the user context to nobody when you POST. Keep in mind, you're still in servicesNS as this point. The only thing that changes is the user context.

[francesco_brizz]

Great! working fine.

[tmontney]

Oops, scratch that. If I replace user_context with "nobody", it works. Caught that by looking at the URL while viewing the alert in GUI (noticed it referenced nobody).