I am sure this is not an existing syntax 🙂 and yet - is it possible to encode such URL-s?
======================
So I will sort of repeat the question:
If I POST to e.g. https://10.41.1.136/splunk/alerts?disposition=3&auth=MyApp%20206eb5cb3c-5c70-4cb7-8844-5a0407a43ca7, then everything works fine.
But '10.41.1.136' and '206eb5cb3c-5c70-4cb7-8844-5a0407a43ca7' actually configurable for the app. Is it possible to save the search in a "formal" format, and have actual values replace the formal ones upon alert being triggered?
I did see how to reference a result field, but it's is not useful in this case.
Thanks
rama
It appears that it is not possible,
But there are alternatives.
It would involve creating a custom alert action, which is actually a one-alert-app.
Once installed correctly, it shows in the list of actions in 'add actions', have a user interface, and more.
Using it, one can have the user explicitly state the required input for the action to complete successfully.
Its all here http://docs.splunk.com/Documentation/Splunk/6.3.3/AdvancedDev/ModAlertsIntro
However, I could not follow the explanation until I read it from the perspective of it being a separate add-on.
I also tried to run a python script instead of a webhook. This option is smooth, but the script has to work out the required data by parsing the attached results, which can be quite challenging; with the webhook, the "fielded" result is attached in JSON
It appears that it is not possible,
But there are alternatives.
It would involve creating a custom alert action, which is actually a one-alert-app.
Once installed correctly, it shows in the list of actions in 'add actions', have a user interface, and more.
Using it, one can have the user explicitly state the required input for the action to complete successfully.
Its all here http://docs.splunk.com/Documentation/Splunk/6.3.3/AdvancedDev/ModAlertsIntro
However, I could not follow the explanation until I read it from the perspective of it being a separate add-on.
I also tried to run a python script instead of a webhook. This option is smooth, but the script has to work out the required data by parsing the attached results, which can be quite challenging; with the webhook, the "fielded" result is attached in JSON